<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
     by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-li-semantic-routing-architecture-00"
     ipr="trust200902">
  <front>
    <title abbrev="SR Architecture">Semantic Routing Architecture for AI
    Agents Communication</title>

    <author fullname="Xueting Li" initials="X" surname="Li">
      <organization>China Telecom</organization>

      <address>
        <postal>
          <street>Beiqijia Town, Changping District</street>

          <city>Beijing</city>

          <region>Beijing</region>

          <code>102209</code>

          <country>China</country>
        </postal>

        <email>lixt2@foxmail.com</email>
      </address>
    </author>

    <author fullname="Aijun Wang" initials="A" surname="Wang">
      <organization>China Telecom</organization>

      <address>
        <postal>
          <street>Beiqijia Town, Changping District</street>

          <city>Beijing</city>

          <region>Beijing</region>

          <code>102209</code>

          <country>China</country>
        </postal>

        <email>wangaj3@chinatelecom.cn</email>
      </address>
    </author>

    <date day="4" month="November" year="2025"/>

    <area>IETF Area</area>

    <workgroup>Working Group</workgroup>

    <keyword>Content Semantic, Service Mesh, Distributed Architecture, AI
    Agents</keyword>

    <abstract>
      <t>This document introduces an Semantic Routing (SR) Architecture for
      enabling intelligent, semantic-driven communication among AI Agents.
      Unlike traditional IP-based routing or service mesh approaches, SRA
      leverages application-layer semantics &mdash; including service
      identity, intent vectors, and trust scores &mdash; to guide routing
      decisions dynamically. The architecture supports intent-driven task
      collaboration, trust-aware policy enforcement, and adaptive routing for
      multi-agent environments. SRA enables the network to evolve from a
      passive transport layer to an intelligent collaboration substrate
      supporting multi-agent coordination and cognitive networking.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>The emergence of AI-driven ecosystems has transformed communication
      paradigms across computing and networking infrastructures. Traditional
      routing systems, designed for host-to-host communication, focus on
      connectivity, reachability, and link-state optimization. However, in
      environments where AI agents <xref target="AIAgent"/>&mdash;autonomous
      entities with reasoning and goal-oriented behavior&mdash;interact
      dynamically, such topological routing no longer meets the operational
      needs. Each agent represents not only a computational endpoint but also
      a semantic actor that generates intents, expresses capabilities, and
      negotiates tasks. The network must therefore evolve from a static
      forwarding fabric into a semantic coordination plane capable of
      interpreting meaning, context, and trust.</t>

      <t>Existing frameworks such as Service Mesh <xref target="ServiceMesh"/>
      (e.g., Istio <xref target="Istio"/>, Linkerd) and Software-Defined
      Networking (SDN) have improved visibility and control but remain largely
      syntactic. They route requests based on service names, APIs, or labels,
      not on why the communication occurs or what semantic goal it represents.
      For example, in an AI multi-agent system performing distributed
      reasoning, the decision of which node to contact depends on task
      semantics&mdash;such as &ldquo;model adaptation,&rdquo; &ldquo;policy
      refinement,&rdquo; or &ldquo;data summarization&rdquo;&mdash;and on
      dynamic factors like capability, latency, and trustworthiness. None of
      these can be expressed using IP addresses or conventional service
      identifiers.</t>

      <t>The Semantic Routing (SR) architecture introduced in this draft aims
      to bridge this semantic gap. It extends routing intelligence from the
      network layer to the application layer, enabling communication decisions
      based on intent vectors, policy interpretation, and trust evaluation.
      Through a semantic control plane, SRA aligns network behavior with
      business and computational objectives, providing adaptive, secure, and
      efficient routing among AI agents. This enables networks to support
      intent-aware task collaboration and to act as intelligent participants
      in distributed cognition processes.</t>

      <t>SRA also addresses emerging challenges of large-scale agent
      communication, including semantic interoperability, cross-domain trust,
      and self-optimization. Modern AI ecosystems consist of heterogeneous
      nodes&mdash;cloud agents, edge assistants, embedded inference
      units&mdash;that collaborate under uncertain conditions. Routing must
      thus adapt to fluctuating workloads, mobility, and trust contexts.
      Static or location-based approaches cannot efficiently manage such
      dynamism. By integrating semantic interpretation with continuous
      telemetry feedback, SRA allows networks to self-optimize: routes are
      recalculated not only based on network states (e.g., congestion or
      delay) but also on semantic relevance and agent reliability.</t>

      <t>The design of SRA is guided by several fundamental objectives: <list
          style="symbols">
          <t>Semantic Awareness &ndash; Networks should understand and act
          upon high-level intents derived from AI tasks.</t>

          <t>Trust Integration &ndash; Routing should consider the reliability
          and historical behavior of agents.</t>

          <t>Dynamic Adaptation &ndash; Telemetry-driven feedback loops must
          continuously refine routing decisions.</t>

          <t>Backward Compatibility &ndash; SAR should coexist with IP, BGP,
          and service-mesh infrastructures.</t>

          <t>Distributed Autonomy &ndash; Each semantic router should make
          local decisions while aligning with global intent policies.</t>
        </list>By embedding intelligence into the control and forwarding
      planes, SRA transforms the Internet from a data transport medium into a
      collaborative semantic ecosystem that supports intelligent communication
      for the next generation of distributed AI systems.</t>
    </section>

    <section title="Conventions used in this document">
      <t>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 <xref target="RFC2119">
      </xref> .</t>
    </section>

    <section title="Terminology">
      <t>The following terms are defined in this draft:<list style="symbols">
          <t>SRA (Semantic Routing Architecture): The routing framework
          defined in this document integrating semantic awareness, trust, and
          policy control.</t>

          <t>AI Agent: An autonomous software entity capable of making
          context-based decisions, performing actions, and communicating with
          other agents.</t>

          <t>Intent Vector: A structured representation of the communication
          goal, expressed semantically (e.g., task type, priority, resource
          needs).</t>

          <t>Semantic Router (SR): Entity interpreting intent metadata and
          enforcing semantic forwarding policies.</t>

          <t>Semantic Forwarding Table (SFT): Forwarding table mapping intent
          categories to next hops and constraints.</t>
        </list></t>
    </section>

    <section title="Architecture Overview">
      <t>The Semantic Router (SR) architecture introduces a layered design
      that bridges application semantics and network operation. It defines a
      semantic control framework capable of understanding agent-generated
      intents, evaluating contextual trust, and translating these into
      actionable routing policies. At its core, SRA consists of four
      interacting planes&mdash;Application, Control, Data, and
      Feedback&mdash;each responsible for distinct yet interdependent
      functions.</t>

      <t>The Application Plane hosts AI agents that issue Intent Vectors (IVs)
      representing goals such as &ldquo;request model inference&rdquo; or
      &ldquo;synchronize state.&rdquo; The Semantic Control Plane collects
      these intents, authenticates identities, and maps them to routing
      policies via the Policy Engine (PE). These policies are then propagated
      to Semantic Routers (SRs) in the Data Plane, which execute the
      forwarding logic using Semantic Forwarding Tables (SFTs) that link
      intent types to paths and constraints. Finally, the Feedback Plane,
      driven by Telemetry Agents (TAs), monitors latency, trust, and service
      quality, feeding the results back into the control plane for continuous
      optimization.</t>

      <t>This closed-loop system ensures that SAR continuously aligns network
      operation with evolving task goals. The architecture is designed to
      integrate seamlessly with existing IP and SDN environments, relying on
      overlays or extended routing attributes (e.g., BGP communities or SRv6
      tags) to express semantic metadata.</t>

      <t><figure align="center">
          <artwork><![CDATA[
           +-------------------------------------------+
           |          Application Plane                |
           |-------------------------------------------|
           |     +-----------+     +-----------+       |
           |     |  Agent A  |<--->|  Agent B  |       |
           |     +-----------+     +-----------+       |
           |         ^                   ^             |
           |         | Intent Vector     |Intent Vector|
           +---------|-------------------|-------------+
                     |                   |
                     v                   v
           +-------------------------------------------+
           |           Control Plane                   |
           |-------------------------------------------|
           |  +--------------+   +------------------+  |
           |  | Intent Ctrl  |<->|   Policy Engine  |  |
           |  +--------------+   +------------------+  |
           |         ^                  ^              |
           |         |                  |              |
           |         v                  v              |
           |    +-----------+     +-----------+        |
           |    | Trust Mgr |<--->|Telemetry A.|       |
           |    +-----------+     +-----------+        |
           +----------------|--------------------------+
                            |
                            v
           +-------------------------------------------+
           |             Data Plane                    |
           |-------------------------------------------|
           |  +------------+   +------------+          |
           |  | Sem.Router |<->| Sem.Router |          |
           |  +------------+   +------------+          |
           |      ^   |             ^   |              |
           |      |   | Telemetry   |   |              |
           |      +---|-------------+---+              |
           +-------------------------------------------+
            Figure 1 The overall architecture for SAR 
]]></artwork>
        </figure></t>
    </section>

    <section title="Functional Layers and Design Principles">
      <t>SAR&rsquo;s design is organized into five functional layers, each
      aligned with a core principle that ensures scalability, intelligence,
      and interoperability.<list style="symbols">
          <t>Intent Layer: Generates and encodes Intent Vectors. Agents
          describe their goals in structured form, including task types,
          urgency, and context. The network uses these to infer optimal paths
          and collaborators.</t>

          <t>Identity and Trust Layer: Manages authentication, authorization,
          and reputation. Each agent is bound to a unique identity
          certificate, and trust scores are computed from telemetry.</t>

          <t>Policy Layer: The Policy Engine maps intents and trust data into
          enforceable rules, determining which paths, nodes, or bandwidth
          allocations are permitted.</t>

          <t>Semantic Routing Layer: Semantic Routers interpret policy rules
          and update SFT entries dynamically based on trust or performance
          metrics.</t>

          <t>Feedback Layer: Collects telemetry (e.g., latency, success rate,
          anomaly detection) and continuously refines both trust and
          policies.</t>
        </list></t>

      <t>SAR adheres to the following design principles: <list style="symbols">
          <t>Semantic Composability: Each intent can be decomposed and
          recombined, enabling fine-grained routing for multi-step agent
          workflows.</t>

          <t>Trust Anchoring: Decisions are always contextualized by dynamic
          trust values, preventing compromised agents from influencing routing
          unfairly.</t>

          <t>Closed-Loop Adaptation: Every policy or path update is verified
          through telemetry feedback, ensuring stable yet flexible routing
          evolution.</t>

          <t>Interoperability: SAR MAY extend BGP, IS-IS, or gRPC metadata to
          distribute semantic and trust information while maintaining backward
          compatibility.</t>
        </list></t>

      <t/>
    </section>

    <section title="Control and Forwarding Procedures">
      <t>SAR operates through coordinated procedures that integrate semantic
      interpretation, trust evaluation, and routing execution. These processes
      are logically divided between the control plane and forwarding plane,
      yet are interconnected via telemetry and feedback. <list style="numbers">
          <t>Agent Registration: When an agent joins the network, it
          authenticates with the Intent Controller (IC) and registers its
          capabilities (e.g., compute type, model domain). The IC issues
          credentials and a unique semantic prefix for the agent.</t>

          <t>Intent Submission: The agent generates an Intent Vector and
          submits it to the IC. The Policy Engine (PE) parses the intent,
          referencing domain policies to determine allowed routing
          strategies.</t>

          <t>Policy Translation: Based on the agent&rsquo;s trust score and
          system objectives, the PE compiles an executable rule set for the
          Semantic Router (SR). These rules specify target domains, quality
          preferences, and security constraints.</t>

          <t>Routing Execution: SR uses its Semantic Forwarding Table (SFT) to
          determine next hops. Forwarding is influenced by trust, latency, and
          semantic relevance rather than just IP reachability.</t>

          <t>Telemetry Feedback: The Telemetry Agent (TA) reports performance
          data back to the Trust Manager (TM). Trust scores are recalculated
          periodically, triggering policy adjustments when thresholds are
          exceeded.</t>
        </list></t>

      <t><figure>
          <artwork><![CDATA[  +-----------+        +------------------+       +------------------+
  |   Agent   |        |  Intent Controller|      |   Policy Engine  |
  +-----------+        +------------------+       +------------------+
        |                         |                          |
        | 1. Register/Authenticate|                          |
        +------------------------>|                          |
        |                         |                          |
        | 2. Submit Intent Vector |                          |
        +------------------------>|                          |
        |                        | 3. Validate & Parse Intent|
        |                        +-------------------------->|
        |                        |                           |
        |                        | 4. Generate Routing Policy|
        |                        |<--------------------------+
        |                        |                           |
        |                        | 5. Install to Router      |
        |                        +-------------------------->|
        |                        |                           |
        |                        | 6. Ack/Confirm            |
        |<------------------------+                          |
        |                        |                           |
        | 7. Data Forwarding via Semantic Routers            |
        |--------------------------------------------------->|
        |                        |                           |
        | 8. Telemetry Feedback  |<--------------------------+
        |<---------------------------------------------------|
        |                        |                           |
        | 9. Trust Update & Policy Adjustment                |
        +----------------------------------------------------+
              Figure 2 The Workflow Overview for SAR 
]]></artwork>
        </figure></t>
    </section>

    <section title="Conclusion">
      <t>The SRA (Semantic Routing architecture) redefines how intelligent
      systems communicate by integrating semantic intent, trust evaluation,
      and adaptive policy control directly into the routing process. It
      extends the traditional Internet model beyond topology and content
      toward a truly intent-driven communication fabric that aligns network
      behavior with the goals of autonomous AI agents. Through its layered
      design&mdash;including intent processing, trust management, semantic
      routing, and telemetry-driven feedback&mdash;SAR provides a coherent
      framework capable of supporting large-scale, cross-domain AI ecosystems
      with dynamic, secure, and efficient coordination.</t>

      <t>Looking forward, several research and standardization opportunities
      remain. First, common intent representation languages must be defined to
      ensure interoperability among heterogeneous agents and vendors. Second,
      mechanisms for distributed trust computation require standard metrics
      and synchronization protocols across administrative domains. Third,
      integration of SAR with existing Internet routing protocols such as BGP,
      IS-IS, or SRv6 will need careful consideration to balance scalability
      with semantic expressiveness. Finally, future work should investigate
      AI-assisted optimization within the SAR control plane, enabling
      predictive policy adjustments based on contextual learning.</t>

      <t>In conclusion, SAR offers a foundational step toward an autonomous,
      cognition-aware Internet, where the network itself participates in
      decision-making, ensuring that communication among AI agents becomes
      purposeful, trustworthy, and adaptive.</t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>TBD</t>
    </section>

    <section title="Acknowledgement">
      <t>TBD</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <reference anchor="AIAgent">
        <front>
          <title>Framework for AI Agent Networks
          draft-zyyhl-agent-networks-framework-01</title>

          <author fullname="Dragoni N" initials="D" surname="N">
            <organization/>
          </author>

          <date year="2017"/>
        </front>
      </reference>

      <reference anchor="Istio">
        <front>
          <title>Impact of etcd deployment on kubernetes, istio, and
          application performance</title>

          <author fullname="Larsson L" initials="Larsson" surname="L">
            <organization/>
          </author>

          <date year="2020"/>
        </front>
      </reference>

      <reference anchor="ServiceMesh">
        <front>
          <title>Service mesh: Challenges, state of the art, and future
          research opportunities</title>

          <author fullname="Li W" initials="W" surname="Li">
            <organization/>
          </author>

          <date year="2019"/>
        </front>
      </reference>
    </references>
  </back>
</rfc>
