Framework for Normalizing Multi-Vendor Network Inputs for LLM-Assisted Network Management

Introduction LLM-assisted network management uses Large Language Models to interpret network data, suggest actions, translate operator intent into device commands, and assist with root cause analysis and reporting. The effectiveness of such systems depends on the quality and consistency of the inputs presented to the LLM. In practice, those inputs are highly heterogeneous: show-command output and configuration dumps vary by vendor and device type; telemetry and alarms use different formats and naming; and management APIs differ across vendors. Without normalization, the same logical concept (e.g., "interface status" or "BGP neighbor state") appears in many forms, which degrades LLM performance and complicates prompt design and maintenance. This document describes an architectural framework for standardizing multi-vendor inputs before they are used as prompts (or prompt context) for a central LLM in network management. The flow is as follows. (1) Multi-vendor network data is received by the Input Classifier, which classifies each message as performance-related, configuration-related, or response-related so that the appropriate Structurer receives the right type of input. The Input Classifier uses a hybrid approach: a fast, deterministic rule-based stage first; when pattern matching fails, multiple category conflicts arise, or structural certainty is insufficient, an SLM-based classification stage within the Input Classifier is invoked. (2) Based on that classification, the message is passed to exactly one of the Performance Structurer, Configuration Structurer, or Response Structurer, each of which interprets vendor-variable text and emits a structured record. (3) The structured output is fed to the Prompt Schema Generator, which creates or selects a vendor-agnostic schema and produces schema-aligned prompts. (4) Those prompts are supplied to the central LLM that performs network management (e.g., troubleshooting, intent translation, or automation). The framework is complementary to broader work on AI-assisted and agent-based network management. While such work may address agent interaction, orchestration, tool access, or operational workflows, this document focuses specifically on normalizing heterogeneous network management inputs before they are consumed by an LLM. The normalization function may therefore serve as an input-processing building block within broader AI-assisted network management architectures. The key components are the Input Classifier, the three Structurers, the Prompt Schema Generator, and the central LLM. Together, they enable multi-vendor inputs to be categorized, structured, normalized, aligned with a vendor-agnostic schema, and presented to the central LLM in a consistent form.

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

LLM (Large Language Model): A machine learning model used for natural language understanding and generation. In this document, the LLM is the consumer of standardized network management inputs for tasks such as troubleshooting, intent translation, and automation.
Prompt: Input (or input context) supplied to an LLM for processing. In LLM-assisted network management, a prompt typically includes network-derived data such as CLI output, configuration snippets, telemetry, or alarms, often after normalization and alignment with a vendor-agnostic schema.
Schema: A formal, vendor-agnostic description of the structure, types, and semantics of a class of network management inputs. A schema provides a common shape to which normalized multi-vendor data can be aligned before being presented to the LLM.
Input Classifier: A component that determines the nature of incoming messages from multi-vendor network elements and assigns each input to one of three categories: performance, configuration, or response, so that the corresponding Structurer can process it. It uses a hybrid rule-based stage followed by SLM-based classification when the rule-based stage is inconclusive.
Structurer: A component that receives input already labeled by the Input Classifier with one category and produces a structured, normalized representation for the Prompt Schema Generator. This document defines three structurers: Performance Structurer, Configuration Structurer, and Response Structurer.
Small Language Model (SLM): A compact language model used inside the Input Classifier (for semantic classification when rules fail) and inside each Structurer (for extraction, normalization, and confidence). SLMs MAY be fine-tuned on curated multi-vendor network messages, telemetry, configuration text, and operational responses.
Confidence level: An optional indicator (e.g., high, medium, low) associated with structuring or classification. Low-confidence cases MAY attach raw input for human-in-the-loop review and later feedback into training of the Input Classifier and Structurers.

Architecture Overview The framework is a logical system positioned between heterogeneous multi-vendor network management data sources and a central LLM used for AI-assisted network management. Raw inputs (e.g., CLI output, configuration, telemetry, alarms, or API responses) enter the Input Classifier. The classifier routes each message to the Performance Structurer, Configuration Structurer, or Response Structurer. The active Structurer's output is fed to the Prompt Schema Generator, which produces schema-aligned prompts or prompt context for the central LLM. The architectural placement of these functions and the logical interfaces between them are described in .

Reference architecture

Architectural Placement and Interfaces The framework is logically positioned within, or adjacent to, a Network Management System (NMS), controller, or orchestrator, between network data acquisition functions and the central LLM. Existing mechanisms may continue to collect CLI output, telemetry, configuration, alarms, or vendor API responses; the framework does not require changes to the network elements or the mechanisms used to acquire such data. The interfaces between the framework components are logical. Raw network input is provided to the Input Classifier, which assigns an input category and forwards the input to the corresponding Structurer. The selected Structurer produces a normalized structured representation for the Prompt Schema Generator, together with metadata such as the assigned category and confidence information; the original input may also be retained for traceability in low-confidence cases. The Prompt Schema Generator uses the normalized representation to produce schema-aligned prompt content for the central LLM. These interfaces do not require a specific transport protocol or serialization format. Implementations may use JSON, YANG-derived structures, or other structured encodings for the normalized representation, while the LLM-facing output may be provided as prompt text or structured prompt context. This document does not define a wire protocol for these interfaces. While this document focuses on normalizing multi-vendor network management inputs for consumption by a central LLM, the normalization function could also be applicable to interactions between an AI agent and an NMS, or between management agents using heterogeneous representations. Such uses are outside the primary scope of this document but may be considered in future work on agent-based network management.

Input Classifier The Input Classifier is responsible for determining the nature of incoming messages from multi-vendor network elements. It assesses each input and classifies it into exactly one of three categories: performance, configuration, or response, so that the corresponding Structurer receives the appropriate type of input for further processing. The Input Classifier uses a hybrid approach: rule-based classification is attempted first, followed by SLM-based classification when the rule-based stage cannot produce a reliable single category. The hybrid design balances speed, efficiency, and accuracy: rule-based logic is fast and lightweight for common patterns; when inputs are complex, ambiguous, or unmatched by rules, an SLM performs deeper contextual analysis.

Rule-based classification In the first stage, the Input Classifier applies a deterministic, rule-based mechanism to categorize incoming network element messages. This layer is intended for high-frequency, well-structured, and common message formats without invoking computationally intensive semantic analysis. The rule-based engine MAY use a combination of:

Keyword dictionaries.
Structured field detection.
Regular expression matching.
Protocol-aware parsing.
Message header inspection.

Each message is evaluated against category-specific rule sets for performance, configuration, and response classification.

Performance message detection Performance-related messages typically describe operational metrics, telemetry readings, utilization values, or statistical measurements. Example keyword families include: utilization, throughput, latency, jitter, packet loss, bandwidth, CPU usage, memory usage, temperature, receive/transmit rates, error rate, and queue depth (exact vocabularies are implementation defined). Pattern-based heuristics MAY include: numeric values with percentage signs; metric names adjacent to numeric measurements; telemetry-style field-value formats. As an illustrative example, a regular expression such as: can match lines such as "CPU utilization: 78%", "Traffic load = 45%", and "Network usage 62%". Similar patterns MAY be defined for other performance metrics (e.g., latency, throughput).

Configuration message detection Configuration-related messages indicate intent to modify, retrieve, delete, or update network state. Example keywords include: set, configure, apply, update, modify, delete, add, remove, commit, rollback, enable, and disable. As an illustrative example, a regular expression such as: can match phrases such as "Set interface Gi0/1 bandwidth 100Mbps", "Update VLAN 10 configuration", and "Modify route table entry".

Response message detection Response messages typically represent outcomes of prior operations. Example keywords include: success, completed, applied, acknowledged, error, failed, failure, invalid, timeout, rejected, and warning. As an illustrative example, a regular expression such as: can match phrases such as "Configuration applied successfully", "Operation completed", and "Request acknowledged". When pattern matching fails, multiple categories conflict, or structural certainty is insufficient, implementations SHOULD escalate to SLM-based classification within the Input Classifier.

SLM-based classification When the rule-based stage cannot categorize a message (for example, due to absence of rule matches, conflicting rule matches, or ambiguous structure), the message is processed by an SLM-based semantic classification stage inside the Input Classifier. The SLM interprets context, semantics, and structure to assign the message to performance, configuration, or response. The model MAY be trained or fine-tuned on a curated corpus that includes historical multi-vendor network messages, telemetry logs, configuration commands, and operational responses, so that nuanced and vendor-specific formats can be handled using contextual cues (e.g., attention over token relationships and embeddings).

Structurers After classification, the message is delivered to exactly one of three Structurers. Each Structurer interprets inputs that the Input Classifier has already labeled with the matching category. Because vendors represent performance, configuration, and response text in widely varying forms, each Structurer typically employs an SLM for adaptability, extraction, normalization, and confidence assignment. Structured records are then passed to the Prompt Schema Generator.

Semantic Normalization A Structurer may need to reconcile vendor-specific terms, field names, and representations that refer to the same network management concept. For example, different vendors may represent the same receive-error metric as "rx_errors", "input errors", or "receive_errors". The Structurer maps such representations to a common representation before passing the structured record to the Prompt Schema Generator. Implementations may perform this mapping using explicit mapping rules or tables, controlled vocabularies or glossaries, semantic models or ontologies, knowledge graphs, SLM-assisted semantic matching, or a combination of these techniques. The choice of mechanism is implementation specific. SLM-assisted mappings may additionally use confidence information and human review, as described elsewhere in this document, when the mapping is uncertain. Determining which normalization techniques, or combinations of techniques, are most suitable for heterogeneous network management inputs is an area for further research. Relevant considerations include mapping accuracy, semantic preservation, coverage of previously unseen representations, explainability, extensibility, and operational cost.

Performance Structurer The Performance Structurer processes inputs categorized as performance by the Input Classifier. Typical processing steps include:

Input reception: The structurer receives performance-labeled input (e.g., a line such as "Traffic load = 75%").
Value extraction: The SLM extracts numeric and unit information (e.g., isolating "75" and "%"). Heterogeneous forms (e.g., ratios such as "8/10") MAY be converted to a comparable representation (e.g., 80%).
Normalization: Values and units are normalized to a consistent representation appropriate to the metric. For example, equivalent ratios and percentages may be converted to a common scale, while throughput or latency values may be converted to consistent units.
Confidence scoring: The SLM MAY assign high (well-recognized pattern), medium (ambiguous; flag for review), or low (unrecognized pattern). For low confidence, implementations MAY attach the raw network element input when sending output to the Prompt Schema Generator for human-in-the-loop review; feedback from that review MAY later be used to retrain or refine the Input Classifier and Structurers.
Performance structuring: The structurer emits a structured representation to the Prompt Schema Generator in an implementation-defined format consistent with the chosen schema.

Configuration Structurer The Configuration Structurer processes inputs categorized as configuration by the Input Classifier. Typical processing steps include:

Input reception: Configuration-labeled input is received (e.g., "Set interface bandwidth to 100 Mbps").
Operation identification: The SLM detects the configuration operation (e.g., set, update, delete, enable, disable).
Target identification: The structurer identifies the configuration target (e.g., interface bandwidth, firewall rule, routing policy).
Value extraction: When present, parameter values are extracted (e.g., "100 Mbps"); some operations (e.g., "enable logging") MAY have no separate value beyond the operation and target.
Normalization of targets: Vendor-specific phrases for the same concept (e.g., "interface bandwidth" vs. "link speed") are mapped to a standard target representation.
Configuration structuring: A structured record is emitted to the Prompt Schema Generator in an implementation-defined format consistent with the chosen schema.

Response Structurer The Response Structurer processes inputs categorized as response by the Input Classifier, using an SLM to cope with variability in how vendors phrase operational outcomes. Typical processing steps include:

Input reception: Response-labeled input is received (e.g., "Configuration applied successfully on interface Gi0/1").
Response intent interpretation: The SLM determines the outcome category, such as success, failure, partial success, warning, timeout, or rejection; whether the message relates to a prior configuration action; and whether an explicit error condition is present.
Error and context extraction: For failure or warning outcomes, the SLM MAY extract error reason, error code (if present), parameters involved, and affected object (e.g., interface, route, policy).
Confidence assignment: High confidence MAY correspond to clear success/failure wording; medium to ambiguity; low to non-standard or unclear outcomes; raw input MAY be attached for the Prompt Schema Generator when confidence is low.
Response structuring: A standardized structured representation is produced for the Prompt Schema Generator in an implementation-defined format consistent with the chosen schema.

The three structurers are distinct logical components; for a given message, only the structurer matching the Input Classifier's category is used. Implementations MAY pipeline batches such that multiple structured records are produced over time and assembled by the Prompt Schema Generator according to policy.

Prompt Schema Generator The Prompt Schema Generator receives structured output from the active Structurer (performance, configuration, or response), optionally including raw input attachments and confidence metadata from low-confidence paths. It creates or selects a structured, vendor-agnostic schema appropriate to that category and message shape, and produces schema-aligned prompts for the central LLM. Functions of the Prompt Schema Generator in this context include:

Creating or selecting schemas that define structure, fields, types, and semantics of network management inputs in a form suitable for the central LLM, with schema choice driven by the classification and structurer output.
Aligning normalized structured representations with a selected vendor-agnostic schema so the central LLM receives consistent input regardless of source.
Feeding the schema and resulting prompts (or prompt context) to the central LLM for tasks such as troubleshooting, intent translation, and automation.

Implementations may use static schema definitions (e.g., based on common network management information models) or dynamically updated schemas. The Prompt Schema Generator aligns the normalized structured records produced by the Structurers with the selected schema and constructs schema-conformant prompts or prompt context for LLM invocation.

Output and Downstream Use The output of the framework is schema-aligned prompts (or prompt context) from the Prompt Schema Generator, derived from classified and structured multi-vendor input. Each prompt is associated with the performance, configuration, or response category assigned by the Input Classifier, with the schema used to create it. These prompts are supplied to the central LLM that performs network management (e.g., troubleshooting, intent translation, compliance analysis, or automation). Downstream components (e.g., prompt assembly, LLM invocation, or result parsing) use the category, structurer output, and schema alignment to choose models, templates, and response handling. The exact format and semantics of data passed from the Prompt Schema Generator to the central LLM are implementation defined.

Security Considerations The structure of this section is informed by the guidelines in . Implementations of this framework in LLM-assisted network management should consider the following:

Network management inputs often contain sensitive data: credentials, topology, IP addressing, and configuration details. Data flows through the Input Classifier, the active Structurer, the Prompt Schema Generator, and the central LLM; each stage may expose this information. Implementations SHOULD apply data minimization (e.g., redacting or tokenizing secrets during classification, structuring, and schema generation), secure transport and storage for intermediate data, and policies that limit what is sent to external or cloud-hosted LLMs. Compliance with organizational and regulatory requirements for network and personal data SHOULD be ensured.
Schema definitions and mapping rules determine what structure and fields are sent to the LLM. Schema generation or selection that relies on untrusted input can introduce injection or policy bypass risks. Implementations SHOULD validate and constrain schema content and SHOULD restrict who can create or modify schema definitions and vendor mappings.
Incorrect classification or structuring can change which prompts and schemas are used and can affect prioritization and access control. Crafted inputs that are misclassified or misstructured could lead to incorrect LLM behavior, privilege escalation, or denial of service. Implementations SHOULD treat classifier and structurer output as advisory where security is critical and SHOULD apply additional checks before acting on LLM outputs that affect network configuration or access.
Consolidating multi-vendor inputs increases attack surface: parsers, regex engines, SLM inference, schema mappings, and paths to the central LLM. Implementations SHOULD harden the Input Classifier, each Structurer, the Prompt Schema Generator, and any normalizers against malformed or malicious input and SHOULD monitor for abuse or unexpected classification patterns.

IANA Considerations This document has no IANA actions.