AI-Assisted Routing Intelligence

Telemetry-Driven Path Intelligence Using a Dedicated AI Intelligence/Control Network

Companion Technology Paper

Author: Christopher Soans
Date: August 2026

Download PDF

Figure 1. AI-Assisted Routing Intelligence

Executive Summary

This paper proposes an AI-Assisted Routing Intelligence architecture in which AI-aware routers export operational forwarding telemetry across a dedicated AI Intelligence/Control network. AI controllers and on-device intelligence correlate this telemetry with the deterministic routing topology to determine not only whether a path is reachable, but how well that path is actually forwarding traffic.

The architecture is designed as a companion to AI-Accelerated Link-State Routing Infrastructure. The earlier architecture accelerates local OSPF/IS-IS Link-State Database processing while preserving the routing protocol as authoritative. This companion architecture addresses a different problem: conventional routing metrics do not necessarily reflect transient or persistent forwarding degradation caused by queue congestion, QoS behavior, latency, packet loss, CPU punts, process/slow-path forwarding, buffer pressure, or other operational conditions.

A central compatibility rule governs the design: telemetry-derived intelligence may influence a routing decision only across a path whose participating forwarding devices support the required AI-aware capability. Legacy routers remain fully interoperable and continue to use conventional standards-based routing behavior. AI telemetry must never be assumed to describe or control an opaque legacy segment.

1. Motivation

Traditional link-state routing protocols provide an authoritative view of topology and reachability. A link may remain operational and retain its configured OSPF or IS-IS metric even when its forwarding quality has deteriorated. Consequently, the shortest protocol path is not always the path providing the best current service.

• A hardware queue may be persistently overrun while the physical link remains up.
• A QoS policy may introduce significant delay for a particular traffic class even when total interface utilization is moderate.
• Packets may be punted from ASIC/NPU forwarding to a CPU or slow path, increasing latency and processor load.
• Microbursts, buffer pressure, packet drops, jitter, ECMP imbalance, or interface errors may impair forwarding without causing an adjacency failure.
• A router may therefore advertise normal reachability while delivering degraded operational performance.

The proposed AI Intelligence/Control network provides an independent mechanism for distributing this richer operational state without requiring high-frequency telemetry to be flooded through OSPF or IS-IS.

2. Architectural Principle: Two Views of the Network

The design deliberately maintains two complementary views of network state.

Network View	Purpose	Authority
Routing Topology	Reachability, adjacency and deterministic protocol state	OSPF/IS-IS and conventional routing processes
Operational Forwarding Topology	Latency, queue health, loss, QoS, utilization, forwarding mode and other telemetry	AI intelligence used only within defined safety and compatibility constraints

The routing topology answers: 'Where can packets be forwarded?' The operational forwarding topology answers: 'How well are those reachable paths forwarding traffic right now?' AI intelligence correlates the two rather than replacing the first with the second.

3. AI-Aware Router Operating System

An AI-aware network operating system is required to provide trusted, structured access to forwarding and control-plane state. The OS acts as the integration and enforcement layer between conventional routing processes, forwarding hardware, telemetry collection, the local AI processor, and the external AI Intelligence/Control network.

• Expose interface and queue occupancy, drops, buffer pressure and utilization.
• Expose QoS class/queue state and class-specific delay where measurable.
• Expose ASIC/NPU versus CPU/punt/slow-path forwarding statistics.
• Expose latency, jitter, loss, BFD and adjacency health information.
• Expose RIB/FIB programming state and hardware resource pressure.
• Time-stamp and identify telemetry so controllers can reason about freshness and provenance.
• Enforce read/write boundaries so AI cannot bypass routing policy or directly fabricate authoritative protocol state.
• Provide deterministic fallback when AI services are disabled, unavailable, incompatible, or untrusted.

4. Dedicated AI Intelligence/Control Network

Telemetry should be transported over the dedicated AI Intelligence/Control network rather than relying exclusively on the production forwarding path. This separates rapidly changing operational data from routing-protocol flooding and preserves management visibility during production congestion or impairment.

Each AI-aware router can publish normalized forwarding-health information to regional or centralized AI controllers while also consuming approved intelligence relevant to its own routing and forwarding decisions.

Telemetry Domain	Representative Measurements
Interface Health	Utilization, errors, discards, optical/electrical state
Queue/Buffer Health	Occupancy, persistent congestion, drops, microburst indicators
QoS Health	Per-class queue pressure, delay, shaping/policing effects
Forwarding Health	ASIC/NPU forwarding ratio, CPU punts, process/slow-path events
Path Performance	Latency, jitter, packet loss, reachability probes
System Health	CPU, memory, forwarding resources, control-plane pressure
Historical Context	Normal baselines, trends, anomaly persistence and recurring conditions

5. Network Forwarding Health State

Rather than treating a single instantaneous measurement as a new routing metric, the AI system should construct a Network Forwarding Health State (NFHS) for each AI-observable link, node, path, and relevant traffic class. The state can combine current measurements, historical baselines, persistence, confidence, and predicted consequences.

A health model may consider latency, utilization, queue pressure, packet drops, jitter, CPU/slow-path behavior, interface errors, and other attributes. The model should produce an explainable operational classification such as Healthy, Elevated, Degraded, or Critical, accompanied by the underlying measurements and confidence.

This prevents a short microburst or momentary queue spike from immediately causing a routing change. Persistence thresholds, hysteresis, dampening, minimum hold times, and deterministic policy constraints should be applied before telemetry can affect forwarding.

6. AI-Aware Path Eligibility

Backward compatibility requires a strict path-eligibility rule. Telemetry-derived intelligence should influence a routing or traffic-engineering decision only when the devices whose behavior must be understood or controlled along the selected path are AI-aware and participate in the required telemetry framework.

This avoids a dangerous assumption: an AI controller cannot infer complete forwarding health for a path containing legacy routers that do not expose equivalent state. A legacy segment may remain fully usable, but it is treated according to conventional routing information rather than being assigned an unsupported AI-derived health assessment.

Path Type	Telemetry-Based Influence
All required forwarding devices AI-aware	Eligible, subject to policy, confidence and deterministic validation
Mixed AI-aware and legacy path	Conventional routing remains authoritative; no end-to-end telemetry-driven route preference based on unknown legacy state
Legacy-only path	Normal standards-based routing behavior
AI capability unavailable or stale	Automatic fallback to conventional routing behavior

7. Capability Discovery and Backward Compatibility

AI-aware routers must continue to interoperate with existing routers using normal standards-based OSPF, IS-IS, BGP, BFD, IPv4, IPv6 and forwarding behavior. The initial implementation can therefore provide useful telemetry and local intelligence without modifying protocol exchanges with legacy equipment.

For cooperative routing intelligence, devices need a trustworthy way to determine whether the relevant path is AI-aware. Capability information could be learned through the dedicated AI control system and, if later standardized, through optional protocol capability advertisements. Such extensions must be additive and must never make ordinary protocol interoperability dependent on AI support.

• Legacy Mode - conventional routing with no dependence on AI telemetry.
• AI Observability Mode - the router exports telemetry but routing remains conventional.
• AI-Assisted Path Mode - telemetry may influence approved decisions when path eligibility and deterministic checks are satisfied.
• AI-Cooperative Mode - multiple AI-aware devices and controllers coordinate optional advanced functions while retaining fallback behavior.

8. How Telemetry Should Influence Routing

The architecture should avoid continuously rewriting OSPF or IS-IS metrics in response to raw telemetry. Doing so could create oscillation: traffic leaves a congested path, the alternate becomes congested, and routing repeatedly moves traffic between them.

Instead, telemetry can feed a controlled decision pipeline:

1. Collect and normalize telemetry.
2. Determine whether degradation is real, persistent and statistically meaningful.
3. Confirm that candidate paths satisfy AI-aware path eligibility.
4. Model the effect of moving traffic, including the possibility of creating congestion elsewhere.
5. Validate reachability, capacity, policy, security, QoS and loop-free behavior.
6. Apply dampening, hysteresis and change-rate limits.
7. Use an approved deterministic mechanism to influence forwarding.
8. Observe the result and automatically revert if validation or health criteria fail.

9. Deterministic Mechanisms for Applying Intelligence

AI should determine when a condition merits consideration and which validated alternatives appear preferable; established deterministic networking mechanisms should perform the actual forwarding change. Depending on platform and deployment, these may include Segment Routing or traffic-engineering policies, constrained path selection, ECMP weighting, policy-based steering, controller-installed paths, or carefully governed metric changes.

This separation preserves an essential principle: AI supplies intelligence, while deterministic mechanisms execute policy-constrained forwarding.

10. Traffic-Class-Aware Intelligence

QoS makes a single link-health score insufficient. A physical interface can be lightly utilized while one queue is saturated. The operational topology should therefore be capable of representing class-specific forwarding health.

For example, a latency-sensitive application may be steered away from a path whose priority or application queue is persistently congested, while bulk traffic continues to use that path. This allows the system to optimize service quality without unnecessarily moving all traffic or globally changing the underlying IGP topology.

11. Detecting Hidden Forwarding Degradation

One of the strongest uses of AI telemetry is detecting conditions that conventional routing may not classify as failures. A router can correlate increasing CPU utilization, rising punt rates, latency growth, queue pressure, and stable physical-link state to identify forwarding-path degradation before an adjacency is lost.

The controller can distinguish a topology failure from a forwarding-quality failure and select an appropriate response. This improves operational awareness while avoiding the need to make every transient hardware condition an OSPF/IS-IS event.

12. Safety, Trust and Control Boundaries

• OSPF, IS-IS and other routing protocols remain authoritative for protocol topology and reachability.
• Raw telemetry never directly modifies the authoritative LSDB.
• AI-derived health state must carry freshness, source and confidence information.
• Stale, incomplete or contradictory telemetry must cause conservative behavior or fallback.
• Only eligible AI-aware paths may receive telemetry-derived preference.
• Policy must define which traffic classes and destinations may be dynamically influenced.
• Routing changes must be rate-limited and reversible.
• Operators must be able to disable AI influence globally, per protocol, per topology, per interface, or per traffic class.
• Every AI-assisted change should be auditable, including the telemetry and deterministic constraints that justified it.
• Failure of the AI Intelligence/Control network must not cause loss of ordinary routing.

13. Relationship to AI-Accelerated LSDB Processing

This architecture is complementary to, but separate from, AI-Accelerated Link-State Routing Infrastructure. Local LSDB acceleration improves how quickly a router processes verified link-state information. AI-Assisted Routing Intelligence adds operational forwarding telemetry that is intentionally kept outside the authoritative LSDB.

Companion Architecture	Primary Function
AI-Accelerated Link-State Routing Infrastructure	Accelerate local LSDB synchronization, indexing, dependency analysis and SPF preparation
AI-Assisted Routing Intelligence	Correlate forwarding telemetry with topology and safely influence eligible AI-aware paths

Keeping the functions separate makes troubleshooting and standards compatibility clearer. A router may implement either capability independently or combine both within a broader AI-aware network operating system.

14. Example Operational Scenario

Assume two valid paths exist between a source and destination. OSPF considers Path A preferable by configured cost. All routers on both candidate paths are AI-aware. The AI control network observes that one router on Path A has persistent application-queue occupancy above its learned baseline, increasing packet drops, elevated latency, and an abnormal CPU-punt rate.

The controller does not declare the link down or rewrite the LSDB. Instead, it confirms the condition persists, verifies that Path B has sufficient capacity and acceptable class-specific health, validates policy and loop-free forwarding, and recommends an approved steering action for the affected traffic class. The deterministic routing/traffic-engineering mechanism applies the change. If the telemetry later normalizes and stability timers are satisfied, traffic can be returned according to policy.

If Path B contained a required legacy router whose forwarding health could not be established, the system would not treat Path B as an end-to-end AI-validated alternative. Conventional routing behavior would remain the safe baseline.

15. Deployment Strategy

• Phase 1 - Upgrade the router OS to expose normalized telemetry and AI interfaces while leaving routing decisions unchanged.
• Phase 2 - Deploy the AI Intelligence/Control network and collect forwarding-health telemetry for visibility and baselining.
• Phase 3 - Introduce AI capability discovery and path-eligibility mapping.
• Phase 4 - Run recommendations in advisory/shadow mode and compare them with actual network outcomes.
• Phase 5 - Permit limited deterministic steering for selected AI-aware paths and traffic classes under strict policy.
• Phase 6 - Expand automation only after stability, interoperability, security and measurable performance benefits are demonstrated.

16. Potential Benefits

• Routing decisions can consider actual forwarding quality in addition to static or topology-oriented metrics.
• Persistent queue congestion and QoS degradation can be recognized without declaring links failed.
• CPU punts and slow-path forwarding can become network-wide operational signals.
• Traffic-class-specific path intelligence can improve latency-sensitive application performance.
• A dedicated control network preserves telemetry visibility during production-network congestion.
• Backward-compatible deployment allows AI-aware equipment to coexist with legacy routers.
• Deterministic routing protocols remain stable while richer intelligence is introduced above them.
• The same telemetry foundation can support future diagnostics, capacity planning and predictive network operations.

17. Engineering and Standards Considerations

• Define normalized telemetry schemas and measurement semantics across vendors.
• Define secure identity, authentication and authorization for AI-aware routers and controllers.
• Determine how AI-aware path capability is discovered and how partial visibility is represented.
• Establish freshness, confidence, dampening and hysteresis requirements.
• Benchmark control-loop speed against the risk of oscillation.
• Protect the AI control network from spoofed telemetry and compromised devices.
• Ensure operator explainability and deterministic rollback.
• Prefer existing standards-based forwarding and traffic-engineering mechanisms where practical before introducing new protocol behavior.

18. Scope Boundary

This paper does not propose replacing OSPF or IS-IS, inserting AI-generated predictions into the authoritative LSDB, or permitting raw telemetry to autonomously rewrite routing metrics. It also does not require legacy routers to participate in the AI framework.

The present proposal is deliberately narrower: build an AI-aware operational view of forwarding health over a dedicated intelligence/control network and allow that information to influence routing only when the relevant path is sufficiently AI-aware, observable, policy-approved, and deterministically validated.

19. Conclusion

AI-Assisted Routing Intelligence can address a gap between protocol reachability and actual forwarding quality. By combining an AI-aware router OS, dedicated forwarding telemetry, an independent AI Intelligence/Control network, path capability awareness, and deterministic routing safeguards, the network can make better-informed forwarding decisions without sacrificing interoperability with conventional routers.

The key architectural principle is selective intelligence rather than universal assumption. AI telemetry is trusted only where the network can establish that the required forwarding path is AI-aware and observable. Everywhere else, proven standards-based routing remains the authoritative fallback. This allows AI capabilities to be introduced incrementally and safely while creating a foundation for a more operationally aware network.

© 2026 Christopher Soans. All rights reserved.

This work is licensed under a Creative Commons Attribution 4.0 International License (CC BY 4.0).

Related Posts

Loading related posts...