<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"  docName="draft-cacciapuoti-qirg-quantum-native-architecture-01" category="info" submissionType="IRTF" consensus="true" obsoletes="" updates="" xml:lang="en" symRefs="true" sortRefs="false" tocInclude="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.31.0 -->
  <!-- Generated by id2xml 1.5.2 on 2025-11-13T14:06:18Z -->
	<front>
    <title abbrev="Quantum-Native Architectural Tenets and ">Quantum-Native Architectural Tenets and Philosophy for the Quantum Internet</title>
    <seriesInfo name="Internet-Draft" value="draft-cacciapuoti-qirg-quantum-native-architecture-01"/>
    <author initials="A. S." surname="Cacciapuoti" fullname="A. S. Cacciapuoti">
      <organization>University of Naples Federico II</organization>
      <address>
        <email>angelasara.cacciapuoti@unina.it</email>
      </address>
    </author>

    <author initials="M." surname="Caleffi" fullname="M. Caleffi">
      <organization>University of Naples Federico II</organization>
      <address>
        <email>marcello.caleffi@unina.it</email>
      </address>
    </author>

    <author initials="J." surname="Illiano" fullname="J. Illiano">
      <organization>University of Naples Federico II</organization>
      <address>
        <email>jessica.illiano@unina.it</email>
      </address>
    </author>

    <author initials="C." surname="De Risi" fullname="C. De Risi">
      <organization>University of Naples Federico II</organization>
      <address>
        <email>caterina.derisi@unina.it</email> 
      </address>
    </author>

    <author initials="A." surname="Abane" fullname="A. Abane">
      <organization>National Institute of Standards and Technology</organization>
      <address>
        <email>amar.abane@nist.gov</email>
      </address>
    </author>

    <author initials="J." surname="Chung" fullname="J. Chung">
      <organization>Argonne National Laboratory -- Data Science and Learning Division</organization>
      <address>
        <email>chungmiranda@anl.gov</email> 
      </address>
    </author>

   


    <date year="2026" month="April" day="20"/>
    <workgroup>Quantum Internet Research Group</workgroup>
    <abstract>
     <t>This document extends RFC 9340 by outlining a set of quantum-native architectural tenets for the design and evolution of the Quantum Internet.  These principles should not be interpreted as dogmas, but as pragmatic guidelines and criteria for harnessing the unique properties of quantum entanglement within networked systems. Such design perspectives, while departing from the classical Internet, remain aligned with a foundational insight: the principle of constant change, articulated in RFC 1958.</t>
     <t>The document specifies quantum-native extensions to the Quantum Internet framework, defining an entanglement packet switching paradigm and an explicit separation between the Quantum Data Plane and Quantum Control Plane. It introduces Quantum Internet Addressing to extend quantum semantics into control and coordination, and generalizes the classical forwarding concept to quantum packets.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="sect-1" numbered="true" toc="default">
      <name>Introduction</name>
      <t>The Quantum Internet will interconnect quantum devices to enable distributed quantum functionalities built upon shared entanglement. RFC 9340 <xref target="RFC9340"/> laid the initial foundation for such an Internet, defining its motivation and goals. At that time, the role of a distinct Quantum Control Plane (QCP) was explicitly declared out of scope. Subsequent work on multiplane quantum network architectures has further highlighted the need for control functions <xref target="QI-MULTIPLANE"/>. This document revisits that open question left by RFC 9340, by arguing that explicit control is necessary. However, this alone is not sufficient: control must also evolve beyond classical coordination toward quantum-native orchestration. To this end, the document presents an architectural framework that makes this distinction explicit.</t>
      <t>Recent theoretical progress <xref target="CalCac25"/>, <xref target="CacCal26"/> has underscored the critical importance of revisiting the open question of how should we design the control plane of the Quantum Internet? Quantum entanglement is a non-local and volatile resource, and it is therefore inherently stateful <xref target="IllCal22"/> from a networking perspective. Indeed, in a quantum network, local operations at one node can instantaneously affect correlated states at remote nodes, by dynamically reconfiguring entanglement relations among nodes and thereby modifying the connectivity graph induced by entanglement. As entanglement relations evolve across nodes and over time, continuous monitoring, timely state dissemination, and latency-aware control become necessary for the effective exploitation of entanglement. Accordingly, the network has to track and expose explicitly resource descriptors, including, at a minimum, fidelity, residual coherence time, and ownership (i.e., the nodes participating in a given entanglement relation). If left uncoordinated, these entanglement features can trigger the amplification principle <xref target="CalCac25"/>, whereby uncontrolled entanglement resources cause routing ambiguities, resource inefficiencies and, ultimately, network instability. It is evident that under these entanglement features an explicit control is necessary. However, a purely classical control cannot maintain a consistent global view as quantum networks scale, becoming the limiting factor for performance and scalability. In summary, scalable quantum network architectures require not only explicit tracking and management of entanglement resources, but also control mechanisms that evolve beyond classical coordination.</t>
      <t>Building on the above considerations, this document updates and extends the architectural principles defined in RFC 9340 <xref target="RFC9340"/>, by introducing a set of quantum-native architectural tenets for the design of the Quantum Internet. These tenets should not be intended as dogmas, but as pragmatic guidelines to harness the unique physical properties of quantum entanglement within networked systems. In this sense, the proposed approach echoes the enduring ``principle of constant change'' articulated in RFC 1958 <xref target="RFC1958"/>, reaffirming that adaptability remains the cornerstone of Internet evolution.</t>
      <t>Specifically, this document introduces a quantum-native control and forwarding architecture composed of the following interlocking components:</t>
     <ul>
      <li>Quantum Data Plane (QDP): the operational plane that carries and manipulates entangled qubits (ebits) for applications such as teleportation. It generalizes the classical notion of forwarding to the quantum domain through Generalized Quantum Forwarding (GQF).</li>
      <li>Quantum Control Plane (QCP): the entanglement-orchestrator plane that manages entanglement resources throughout their entire life-cycle by relying on the Entanglement-Defined Controller (EDC), a distributed control entity analogous to a Software-Defined Networking (SDN) controller, but operating on entanglement resources to maintain global coherence.</li>
      </ul>
      <t>Accordingly, this document defines three core mechanisms -- Quantum Internet Addressing (QA), Generalized Quantum Forwarding (GQF), and Entanglement-Defined Controller (EDC) -- that together form the basis for scalable, entanglement-driven coordination across heterogeneous quantum domains.</t>
    </section>
    <section anchor="sect-2" numbered="true" toc="default">
      <name>Scope</name>
      <t>This document is Informational. It proposes architectural tenets and guidance for researchers and implementers. It is not a protocol specification. Terminology and notation adhere to monospaced ASCII presentation for clarity in IRTF review contexts.</t>
    </section>
    <section anchor="sect-3" numbered="true" toc="default">
      <name>Terminology</name>
      <t>This section defines key terms used throughout this document. Some definitions extend those introduced in RFC 9340 <xref target="RFC9340"/>, reflecting the evolution from classical coordination to quantum-native orchestration.</t>
      <ul>
      <li>Quantum Data Plane (QDP): The QDP is the operational plane of the Quantum Internet that generalizes entanglement forwarding to the quantum domain through GQF. It is responsible for the generation of elementary link-level entanglement and for the execution of quantum operations, including entanglement swapping and purification.</li>
      <li>Quantum Control Plane (QCP): The QCP is the logical plane of the Quantum Internet responsible for orchestrating entanglement resources by exploiting quantum-addressing abstractions and relying on the Entanglement-Defined Controllers (EDCs)</li>
      <li>Entanglement Service Provider (ESP): The ESP is a network entity of the QDP that provides entanglement connectivity to both end-nodes and peer ESPs. ESPs collectively form the ``entangled-backbone''.</li>
      <li>Entanglement-Defined Controller (EDC): The Entanglement-Defined Controller is the logical entity of the QCP responsible for orchestrating  entanglement resources across ESPs through reconfiguration, monitoring and policy enforcement. It maintains a view of the network’s entanglement state, to enable scalable and adaptive control.</li>
      <li>Quantum Internet Addressing (QA): An addressing scheme in which node identifiers are represented as quantum states. It serves as addressing abstraction of the QCP.</li>
      <li>Generalized Quantum Forwarding (GQF): A forwarding abstraction that generalizes the classical prefix-matching forwarding to the quantum domain.</li>
      </ul>
      <t>The above terminology forms the conceptual foundation of this document. The QDP and QCP represent the two key planes of the architecture. Within these planes, ESPs (network entities) implement entanglement forwarding and maintenance, while EDCs (logical entities) orchestrate the entanglement resources. QA and GQF provide quantum-native abstractions for addressing and stateful forwarding.</t>
    </section>
    <section anchor="sect-4" numbered="true" toc="default">
      <name>Architectural Overview</name>
      <t>This section extends Section 5 of <xref target="RFC9340"/>.</t>
      <t>The Quantum Internet is an entanglement-packet switching network, where entangled qubits (ebits) replace classical packets as the basic network units, carrying quantum correlations across network nodes. This paradigm is not merely an optimization or a refinement of the classical packet-switching paradigm, but a fundamental departure imposed by the unique constraints of quantum mechanics. Indeed, while the goal of the classical packet-switching paradigm is to determine the best next-hops toward a set of nodes (routing) and to forward packets along those hops from source to destination, entanglement-packet switching aims to distribute and manipulate entanglement among quantum nodes, ultimately entangling the source and destination(s) regardless of their physical location.</t>
      <t>By inheriting statefulness and non-locality, this switching model departs from the end-to-end principle <xref target="RFC1958"/>, <xref target="RFC3439"/>, a key tenet of the classical Internet design. Indeed, it requires in-network operations and persistent state awareness across all phases of the entanglement life-cycle -- from generation and distribution to storage and final utilization. A broader discussion of the notion of statefulness adopted in this document is provided in <xref target="IllCal22"/>. Combined with the sophisticated and resource-intensive nature of state-of-the-art quantum hardware, this paradigm advocates concentrating the complexity inside the network, while keeping the edges simple. As a consequence, it mandates a clear decoupling between the QDP, which handles qubit operations, and the QCP, which orchestrates entanglement.</t>

      <artwork xml:space="preserve"><![CDATA[
+--------------+-----------------------------------+-----------------------+
| Network      |Classical Internet                 |Quantum Internet       |
| Feature      |                                   |                       |
+--------------+-----------------------------------+-----------------------+
|Resource      |Communication links change slowly  |Entanglement is        |
|Persistence   |relative to packet forward         |ephemeral and depleted |
|              |dynamics                           |upon use               |
+--------------+-----------------------------------+-----------------------+
|Control plane |It is grounded in classical        |It is grounded in      | 
|              |topological-driven abstractions    |quantum-native         |
|              |such as IP-style addressing        |abstractions, such as  |
|              |                                   |quantum addressing     | 
+--------------+-----------------------------------+-----------------------+
|Data plane    |Packet forwarding                  |Generalized quantum    |
|              |                                   |forwarding             |
+--------------+-----------------------------------+-----------------------+
      ]]></artwork>
     

      <section anchor="sect-4.1" numbered="true" toc="default">
        <name>Quantum Data Plane (QDP)</name>
        <t>The QDP constitutes the operational plane of the Quantum Internet. It provides the substrate on which entanglement-based connectivity -- also referred to as quantum connectivity -- is established and maintained among remote nodes. Within the QDP, network entities exchange and manipulate ebits to establish, extend, and refresh quantum correlations across the network.</t>
        <t>The QDP supports a set of primitives, such as the generation of elementary link-level entanglement and the execution of quantum operations including entanglement swapping and purification <xref target="AbaCub25"/>.</t>
        <t>Unlike its classical counterpart, the QDP does not act on user information directly (data in the traditional sense), but it operates on entanglement that applications later exploit (e.g., quantum teleportation and distributed quantum processing). Each entanglement-link represents a consumable network resource that must be created, maintained, and periodically refreshed as coherence decays.</t>
        <t>The QDP interfaces closely with the QCP to expose real-time KPIs and metrics such as fidelity, coherence time, and link availability. These metrics support adaptive entanglement management and allow the QCP to optimize resource allocation, path selection, and recovery procedures. The logical interface between the QCP and QDP may be realized through classical or quantum signaling channels, functioning analogously to the control-to-data interface in software-defined networks <xref target="KreRam14"/>. Detailed protocol specifications are out of scope for this document.</t>


    <figure>
  <name>Mapping between plane abstractions and architectural entities, showing: (1) the QCP as the entanglement-orchestration plane, (2) the QDP as the operational plane, (3) the EDC as the QCP logical entity, and (4) the ESPs as QDP network entities.</name>

  <artwork type="ascii-art" xml:space="preserve"><![CDATA[
    ┌─────────────────────────────┐ ┌────────────────────────────┐
    │                             │ │                            │
    │       Plane Abstraction     │ │        Network and         │
    │                             │ │       Logical Entities     │
    │                             │ │                            │
    │┌───────────────────────────┐│ │┌──────────────────────────┐│
    ││ (1) (QCP)                 ││ ││ (3) (EDC)                ││
    ││ Quantum Control Plane:    ││ ││ Entanglement-Defined     ││
    ││ Entanglement-Orchestrator ││ ││ Controller:              ││
    ││                           ││ ││ QCP's Logical Entity     ││
    ││                           ││ ││                          ││
    │└─────────────^─────────────┘│ │└─────────────^────────────┘│
    │              │              │ │              │             │
    │    Controller Functions:    │ │     Controller Functions:  │
    │    - Reconfiguration        │ │     - Reconfiguration      │
    │    - Monitoring             │ │     - Monitoring           │
    │    - Policy Enforcement     │ │     - Policy Enforcement   │
    │              │              │ │              │             │
    │┌─────────────v─────────────┐│ │┌─────────────v────────────┐│
    ││ (2) (QDP)                 ││ ││ (4) (ESP)                ││
    ││ Quantum Data Plane :      ││ ││ Entanglement Service     ││
    ││                           ││ ││       Provider:          ││
    ││ Operational Plane         ││ ││ QDP's Network Entity     ││
    ││                           ││ ││                          ││
    │└───────────────────────────┘│ │└──────────────────────────┘│
    └─────────────────────────────┘ └────────────────────────────┘
  ]]></artwork>

</figure>

    </section>


      <section anchor="sect-4.2" numbered="true" toc="default">
        <name>Quantum Control Plane (QCP)</name>
        <t>The QCP is the entanglement-orchestration plane of the Quantum Internet, maintaining a consistent view of entanglement resources across the network.</t>
        <t>In this document, the term control plane is adopted from classical networking terminology, where it denotes the network-wide logic that controls packet forwarding among a network, as well as the configuration and management of these devices and their services <xref target="yang2004rfc3746"/>, <xref target="KurRos10"/>. By analogy, the QCP orchestrates the entanglement life-cycle -- from generation to distribution and exploitation. Unlike its classical counterpart, the QCP must account for the stateful and non-local nature of entanglement, while coherence-time constraints demand time-aware coordination across the network.</t>
        <t>As indicated in Section 1, effective tracking and management of entanglement resources are essential for scalable quantum network architectures. However, if such tracking relies solely on classical control and signaling, the resulting coordination overhead and latency prevent the system from maintaining a consistent global view, ultimately hindering scalability. Even in classical networks, where entanglement is absent, it has been shown that the number of control messages required per topology change (namely, the updating communication overhead) cannot scale better than linearly on Internet-like topologies <xref target="KriCla07"/>. In the quantum setting, this challenge becomes even more pronounced due to the intrinsic statefulness and fragility of entanglement, and it is further exacerbated when multipartite entanglement is considered <xref target="IllCal22"/>.</t>
        <t>The QCP coexists with the classical control plane, complementing rather than replacing it. While the QCP introduces quantum-native mechanisms for entanglement orchestration, both the QCP and the QDP rely on an underlying classical communication substrate. Indeed, classical signaling remains necessary for the functioning of a quantum network, including, for example, the transmission of measurement outcomes required to trigger conditional operations at remote nodes, as also discussed in <xref target="RFC9340"/>. Accordingly, the architecture described in this document can be interpreted as augmenting classical control mechanisms rather than replacing them. A detailed characterization of the interaction between the classical control plane and the QCP/QDP architecture is outside the scope of this document and remains an open research question.</t>
        <t>Architecturally, the QCP defines a distinct yet tightly coupled control logic above the QDP. The QCP interfaces directly with ESPs, which expose local entanglement capabilities, while ensuring consistent entanglement resource policies through EDCs.</t>
      </section>
      <section anchor="sect-4.3" numbered="true" toc="default">
        <name>Hierarchy &amp; EDC </name>
        
       
          <artwork xml:space="preserve"><![CDATA[
+--------------------------------+-----------------------------------+
|         Classical Tenets       |     Quantum-Native Tenets         |
+--------------------------------+-----------------------------------+
| Complexity located at the      | Complexity concentrated in the    |
| network edges                  | core network                      |
+--------------------------------+-----------------------------------+
| Stateless core network         | Stateful core network             |
+--------------------------------+-----------------------------------+
| End-to-end protocol design     | Network-mediated protocol design  |
+--------------------------------+-----------------------------------+
    ]]></artwork>
      
        <t>Building on the above considerations, the network architecture is organized into  a two-tier structure, that distinguishes between ESPs and quantum-edge nodes:</t>
        
        <ul>
          <li>Bottom Tier (tier-1): Edge quantum nodes (e.g., quantum processors, sensors, and cryptographic devices) consume entanglement resources to support quantum applications. These edge nodes primarily connect to nearby ESPs via short-range quantum links.</li>
          <li>Top Tier (tier-2): ESPs form the entanglement-core network. They provide end-to-end entanglement-based connectivity to the lowest tier by proactively maintaining entangled resources among each other. The ESPs can be interconnected via long-range quantum links, such as optical fibers, and they are equipped with the sophisticated and resource-intensive infrastructure required for entanglement generation and distribution.</li>
        </ul>
        <t>Overall orchestration is achieved through EDCs: distributed logical entities that maintain coherent global or partial topological views. EDCs act as the quantum-native counterpart of SDN controllers, linking control logic directly to quantum states and enabling state-aware, entanglement-driven routing.</t>
        <t>EDCs perform primarily three control-plane functions:</t>
        <ul>
          <li>Reconfiguration: Dynamic management and reallocation of entanglement resources among ESPs.</li>
          <li>Monitoring: Assessment of fidelity, coherence time, and availability of entanglement resources across ESPs.</li>
          <li>Policy enforcement: Application of global policies for routing, resource allocation, and entanglement-loss recovery.</li>
        </ul>
        <t>Although an EDC reflects a centralized control logic, the architecture supports multiple, potentially federated controllers. These EDCs coordinate to share partial topological knowledge and enforce consistent entanglement resource policies, while preserving local autonomy and scalability.</t>

      <figure>
  <name>Entanglement-Defined Network Architecture showing: (1) ESPs forming a virtual mesh via proactive entanglement sharing (dashed lines), (2) the EDC responsible of the QCP functionalities.</name>
  <artwork type="ascii-art" xml:space="preserve"><![CDATA[
                  +---------------------------------------+
                  | (2)                                   |
                  | Entanglement Defined Controller (EDC) |
                  +---------^-----^-----^-----------------+
                            |     |     |
                            |Reconfiguration
                            |     |     |        Quantum Control Plane (QCP)
                            |     |Monitoring
                            |     |     |
                            |     |     |Policy Enforcement
----------------------------+-----+-----+-----------------------------
                            |     |     |
Entanglement-defined        |     |     |        Quantum Data Plane (QDP)
Networking                  |     |     |
                            |     |     |
      +---------------------v-----v-----v--------------------------+
      | Top Tier      (1)                                          |
      | Tier 2                                                     |
      |     +-------+          +-------+               +--------+  |
      |     |       |          |       |               |        |  |
      |     | ESP_1 +----------+ ESP_2 +-----...-------+ ESP_n  |  |
      |     |       |          |       |               |        |  |
      |     +-------+          +-------+               +--------+  |
      +------------------------------------------------------------+  
      ]]></artwork>
</figure>

         </section>


    </section>
      <section anchor="sect-5" numbered="true" toc="default">
        <name>Quantum Internet Addressing (QA)</name>
        <t>The architectural decoupling of the QCP and QDP is a necessary condition for scalability, but it is not sufficient. To manage in-network operations and maintain persistent state awareness required by entanglement, the control plane itself must be designed to embrace quantum principles and phenomena for effectively controlling entanglement dynamics. This requirement follows once again from the non-local nature of quantum entanglement: entanglement proximity cannot be confined to physical distance or restricted to fixed topological neighborhoods. As a result, control mechanisms based on locality and topological-driven addressing, such as IP, are inherently unable to efficiently track, respond to, or propagate entanglement state evolution across the network. Although alternative approaches have been proposed in classical networking, they have not seen widespread adoption in current networking architectures. Regardless, such approaches remain fundamentally grounded in classical abstractions and are not designed to natively capture or manipulate the quantum-state semantics of entanglement resources. A fundamental rethinking of network addressing and control mechanisms is therefore needed to embed quantum behavior directly into the node identifiers, thereby elevating the control plane to a quantum-native level.</t>
        <t>Quantum addressing (QA) provides the logical foundation for this quantum-native control model. QA does not replace classical addressing; rather, QA complements it by enabling control and forwarding functions to be expressed directly on quantum states. Accordingly, each network node is associated with two types of identifiers: i) a classical address, such as an IP address, required for classical communications and signaling; and ii) a quantum address, represented by a quantum state <tt>|A&gt;</tt> of an N-qubit system.</t>
        <t>Since qubit states can exist in superposition, a sequence of N-qubits can encode a single node identity, i.e., a single quantum network address, or a superposition of node identities, each corresponding to a distinct network address. In this way, a single quantum address can represent a set of quantum nodes, independently of their physical or topological location, inherently supporting compactness of routing tables.</t>
        <section anchor="sect-5.1" numbered="true" toc="default">
          <name>Quantum Packet </name>
          <t>In the entanglement-packet switching paradigm, packet forwarding relies on the manipulation of shared entanglement resources across network nodes. Therefore the QA model requires a corresponding quantum packet structure that supports quantum-native forwarding and routing operations.</t>
          <section anchor="sect-5.1.1" numbered="true" toc="default">
            <name>Quantum Packet Structure</name>
            <t>A quantum packet consists of a quantum header and a quantum payload.</t>
            <ul>
              <li>Quantum Header: carries quantum addresses that enable network nodes to interpret and forward (in the generalized sense) quantum packets according to the quantum-routing logic. The header may also carry additional control information <xref target="CacCal26"/>.</li>
              <li>Quantum Payload: carries the entanglement qubits <tt>|e_i&gt;</tt> constituting the network resource manipulated by packet-processing operations. Depending on the underlying logic, such resources may be consumed, transformed, stored, or left unchanged. The payload is not required to be strictly tied to the immediate communication objective identified by the header, and may also include entanglement resources maintained to support subsequent operations or network-level optimization <xref target="CacCal26"/>.</li>
            </ul>
            <t>The following ASCII diagram illustrates the conceptual structure of a quantum packet for documentation only. The model is not limited to bipartite entanglement.</t>
            
              <artwork xml:space="preserve"><![CDATA[
+---------------------------------+----------------------------------+
|       Quantum Header            |     Quantum Payload              |
+---------------------------------+----------------------------------+
|   - Quantum Address |A>         |  - Entangled qubits |e_i>        |
|   - Optional metadata           |   (bipartite or multipartite)    |
+---------------------------------+----------------------------------+
              ]]></artwork>
            
            </section>
        </section>
    </section>
    <section anchor="sect-6" numbered="true" toc="default">
      <name>Generalized Quantum Forwarding (GQF)</name>
      <t>End-to-end entanglement distribution can be logically divided into two distinct phases: routing and forwarding <xref target="AbaCub25"/>. Routing determines the entanglement path (or, more generally, an entanglement graph), according to the selected routing metric, while forwarding performs the quantum operations on the entangled resources required to sustain quantum connectivity.</t>
      <t>In classical networks, the forwarding logic follows a match-and-forward paradigm, where the destination address is extracted from the packet header and matched against the routing table. In the Quantum Internet, this logic is generalized toward entanglement manipulation, enabling forwarding decisions that act directly on quantum states in accordance with quantum-native principles.</t>
      
      <section anchor="sect-6.1" numbered="true" toc="default">
        <name>Role within the Architecture</name>
        <t>Within the architecture, forwarding operations arise from the interaction between the QDP and the QCP, through the EDCs and ESPs:</t>
        <ul>
        <li>QCP provides control support for forwarding, by maintaining awareness of network connectivity, tracking entanglement resources, and by enforcing policies across ESPs.</li>
        <li>ESP performs the quantum operations required for forwarding based on locally available entanglement resources, packet-carried control information, and, when available, policies provided by the QCP. </li>
        </ul>
        <t>Forwarding decisions require the capability to operate directly on quantum identifiers. This is enabled by the quantum header in the packet, which carries the quantum equivalent of the source address and destination address.</t>
      </section>
    </section>
    <section anchor="sect-7" numbered="true" toc="default">
      <name>Quantum-Native Principles</name>
      <t>This section extends the architectural principles provided in <xref target="RFC9340"/> by introducing a set of quantum-native principles that guide the design and operation of a scalable Quantum Internet. These principles reflect the physical properties of entanglement and the architectural requirements arising from entanglement-driven networking.</t>
       <ul>
        <li>
          Entanglement Packet Switching.<br/>
          The architecture adopts an entanglement-packet switching paradigm, in which entangled bits (ebits) serve as the fundamental network units. These ``quantum packets'' carry quantum correlations across network nodes. 
        </li>

        <li>
          Explicit Plane Decoupling.<br/>
          The architecture explicitly separates the QDP from the QCP. This decoupling is necessary for scalability, since the stateful and non-local nature of entanglement resources requires in-network operations and persistent state awareness.
        </li>

        <li>
          Quantum Addressing.<br/>
          The network logic adheres to a quantum-native control model grounded in the quantum addressing (QA), which serves as its logical abstraction.
        </li>

        <li>
          Stateful Core Network, Lightweight Edges.<br/>
          The network core -- formed by ESPs -- is inherently stateful. Conversely, edge nodes remain lightweight.
        </li>

        <li>
          Entanglement-Aware Metrics.<br/>
          Routing and orchestration decisions rely on entanglement-aware metrics, including fidelity, residual coherence time in quantum memories, entanglement purification overhead, and entanglement availability.
        </li>

        <li>
          Hybrid Control Coexistence.<br/>
          The architecture must support the coexistence of classical and quantum control planes. 
        </li>
      </ul>
    </section>

    <section anchor="sect-8" numbered="true" toc="default">
        <name>Routing Models and Repeater Realizations Support</name>
        <t>The architectural framework defined in this document is agnostic to both the specific routing model and quantum repeater generation adopted in an implementation. The abstractions introduced by the QDP, the QCP, and QA are designed to remain valid across different operational regimes of entanglement generation and across different physical realizations of quantum repeaters.</t>
    

        <section anchor="sect-8.1" numbered="true" toc="default">
          <name>Routing-Model Agnosticism</name>
          <t>The QCP orchestrates entanglement resources while the QDP executes the underlying quantum operations. This separation naturally accommodates different routing models, including regimes in which entanglement generation occurs proactively (i.e., independently of a specific request) as well as regimes in which it is triggered reactively in response to explicit service requests.</t>
          <t>In quantum routing, control decisions may precede the actual availability of entanglement. This stems from the ephemeral nature of entanglement resources, which may be consumed by operations such as entanglement swapping or may decohere over time. Accordingly, the architecture supports two complementary routing views:</t>
        <ul>
          <li>a physical-proximity view, driving hop-by-hop entanglement generation and distribution; and</li>
        <li>an entanglement-proximity view, reflecting the currently available entanglement connectivity and enabling routing and forwarding decisions.</li>
        </ul>
          <t>When a service requires entanglement connectivity, the QCP -- through the EDCs -- may either exploit already-established entanglement links or trigger additional link-level generation based on the physical-proximity view. The resulting entanglement resources are then reflected in the entanglement-proximity view maintained by the control plane. This mechanism applies independently of whether entanglement generation is proactive or reactive.</t>
          <t>QA plays a key role in enabling this flexibility. QA is not envisioned as a routing-only mechanism and does not require preexisting entanglement. Rather, QA provides a quantum-native control abstraction that enables the QCP to represent and operate on sets of candidate nodes, paths, or domains in a compact manner. In particular, QA enables reasoning over potential connectivity before entanglement resources are instantiated, supporting scalable orchestration decisions such as which links to activate, which paths to provision, or which domains to involve in distributed coordination.</t>
          <t>GQF operates on the basis of the quantum identifiers encoded in the quantum packet header, allowing forwarding decisions to adapt naturally to different routing regimes. For example, forwarding may exploit already available entanglement resources as indicated by the entanglement-proximity view, or trigger additional entanglement-generation procedures guided by the physical-proximity view when such resources are unavailable. In both cases, the quantum header and QA abstractions provide the necessary information for GQF to apply the appropriate sequence of operations on the available entanglement resources.</t>
        </section>
       
        <section anchor="sect-8.2" numbered="true" toc="default"> 
          <name>Repeater-Generation Agnosticism</name>
        <t>Within this architecture, a repeater is treated primarily as a network function rather than as a fixed network entity. Accordingly, the architectural tenets remain invariant across repeater generations, while the physical mechanisms implemented in the QDP may evolve with technological progress.</t>
        <t>In first- and second-generation repeater networks, where bipartite entanglement generation, purification, and swapping are the dominant primitives, QA naturally indexes and operates on entanglement resources and entanglement-based connectivity. The entanglement-proximity view maintained by the QCP reflects the dynamic overlay formed by these resources, while GQF implements the corresponding sequence of swapping and forwarding operations.</t>
        <t>In third-generation repeater networks, where quantum error correction and logical qubit transmission may become prevalent, the operational primitives evolve, and shared elementary link-level entanglement may no longer be the dominant abstraction. In this regime, QA continues to provide a scalable control abstraction, but the entities it represents evolve from individual entanglement resources toward logical entanglement resources. Nevertheless, the architectural separation between QDP and QCP, the role of EDCs in orchestration, and the forwarding logic expressed through GQF remain unchanged.</t>
        </section>
    </section>

     <section anchor="sect-9" numbered="true" toc="default">
      <name>Multi-Domain Routing and Forwarding</name>
      <t>While the future deployment structure of the Quantum Internet remains uncertain, it is reasonable to consider the possibility that, as the network scales, it may evolve toward a multi-domain environment composed of independently operated infrastructures, similarly to the classical Internet. If such an evolution occurs, inter-domain routing and coordination would naturally arise. The architectural tenets described in this document are sufficiently flexible to accommodate such a scenario.</t>
      <t>The following section therefore illustrates, as an example of the flexibility of the architectural abstractions, how the separation between QDP, QCP, and QA can support intra-domain and inter-domain routing and forwarding in a multi-domain deployment. This discussion is intended to be illustrative rather than prescriptive.</t>
    

        <section anchor="sect-9.1" numbered="true" toc="default">
          <name>Intra- and Inter-Domain Routing</name>
          <t>In a large-scale deployment composed of multiple administrative domains, routing functionality naturally separates into intra-domain and inter-domain components, similarly to the distinction between Interior Gateway Protocols (IGPs) and Exterior Gateway Protocols (EGPs) in the classical Internet.</t>
          <t>Within each administrative domain, the QCP maintains the information required to populate ESP routing tables. This intra-domain routing function maintains a consistent view of local ESP connectivity and distributes the corresponding forwarding policies across the domain.</t>
          <t>Across domains, routing information is exchanged between boundary ESPs belonging to different administrative domains. Because inter-domain routing spans independently operated networks, it cannot rely on a single centralized controller <xref target="CalCac25"/>. Instead, routing information propagates through distributed coordination between domain-level controllers and gateway ESPs.</t>
          <t>Mechanisms inspired by classical inter-domain routing, such as BGP, may be envisioned to exchange reachability information and candidate paths across domains while preserving routing autonomy <xref target="Liu2024QBGP"/>. However, in the quantum networking context, routing decisions must also account for the probabilistic nature of entanglement generation and the temporal fluctuations in the availability of entanglement resources. This aligns naturally with the abstractions introduced in this document, where routing information may reference sets of candidate forwarding targets rather than a single deterministic next hop, allowing the control plane to reason about multiple potential nodes, paths and domains simultaneously.</t>
          <t>The QCP therefore combines two complementary roles:</t>
          <ul>
          <li>maintaining intra-domain and inter-domain entanglement-connectivity graph and populating ESP routing tables, and</li>
          <li>coordinating with peer controllers and/or gateway ESPs to exchange physical and entanglement reachability information across domains.</li>
          </ul>
        </section>

        <section anchor="sect-9.2" numbered="true" toc="default">
          <name>Quantum Addressing</name>
          <t>As discussed in the previous section, rather than associating forwarding entries strictly with individual nodes, QA enables routing information to reference sets of nodes or candidate forwarding targets through quantum-state representations. </t>
          <t>This capability is particularly useful when the control plane must decide which resources should be maintained or generated, and how forwarding logic should be configured, even if end-to-end entanglement has not yet been established. In this sense, QA provides a quantum-native abstraction to reason about entanglement connectivity and control actions independently of when entanglement generation occurs.</t>
          <t>In the context of inter-domain routing, QA can represent reachable nodes, domains, or established entanglement in a compact and expressive form and support coordination among federated or distributed EDC instances when disseminating reachability information or provisioning candidate paths.</t>
        </section>

        <section anchor="sect-9.3" numbered="true" toc="default">
          <name>Quantum Forwarding</name>
          <t>Once routing information has been installed at ESPs, forwarding decisions are executed locally through GQF in the QDP. Instead of matching classical address prefixes, ESPs evaluate forwarding rules defined over the quantum identifiers contained in the quantum packet header. These rules determine how the ESP should manipulate locally available entanglement resources to progress the forwarding operation. Upon receiving a forwarding request, an ESP consults its routing table and selects the appropriate next hop according to the installed policies. The ESP then performs the quantum operations required to extend entanglement toward that next hop using locally available resources. These operations may include generating elementary link-level entanglement with the next ESP or performing entanglement swapping using stored entangled qubits.</t>
        </section>
      </section>

    <section anchor="sect-10" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>As an Informational document, this draft does not propose any specific mechanisms to ensure security. The security considerations provided in RFC9340 apply for this document as well.</t>
    </section>

    <section anchor="sect-11" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This memo includes no requests to IANA.</t>
    </section>


     <section anchor="sect-12" numbered="true" toc="default">
     <name>Acknowledgments</name>
      <t>This document is based on work funded by the European Union under Horizon Europe ERC-CoG grant QNattyNet, n.101169850. Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union or the European Research Council Executive Agency. Neither the European Union nor the granting authority can be held responsible for them.</t>
    </section>

    

  </middle>
  
 <back>
    <references>
      <name>Informative References</name>


      <reference anchor="RFC9340" target="https://www.rfc-editor.org/rfc/rfc9340">
        <front>
          <title>Architectural Principles for a Quantum Internet</title>
          <author fullname="W. Kozlowski" initials="W." surname="Kozlowski"/>
          <author fullname="S. Wehner" initials="S." surname="Wehner"/>
          <author fullname="R. Van Meter" initials="R." surname="Van Meter"/>
          <author fullname="B. Rijsman" initials="B." surname="Rijsman"/>
          <author fullname="A. S. Cacciapuoti" initials="A. S." surname="Cacciapuoti"/>
          <author fullname="M. Caleffi" initials="M." surname="Caleffi"/>
          <author fullname="S. Nagayama" initials="S." surname="Nagayama"/>
          <date month="March" year="2023"/>
        </front>
        <seriesInfo name="RFC" value="9340"/>
        <seriesInfo name="DOI" value="10.17487/RFC9340"/>
      </reference>

  <reference anchor="QI-MULTIPLANE" target="https://datatracker.ietf.org/doc/draft-irtf-qirg-qi-multiplane-arch/01/">
    <front>
      <title>A Multiplane Architecture Proposal for the Quantum Internet</title>
      <author initials="D." surname="Lopez"/>
      <author initials="V." surname="Martin"/>
      <author initials="B." surname="Lopez"/>
      <author initials="L. M." surname="Contreras"/>
      <date year="2026" month="February"/>
    </front>
    <seriesInfo name="Internet-Draft" value="draft-irtf-qirg-qi-multiplane-arch-01"/>
  </reference>
  

 



  <reference anchor="CalCac25" target="http://dx.doi.org/10.1109/TCOMM.2025.3650397">
        <front>
          <title>Quantum Internet Architecture: unlocking Quantum-Native Routing via Quantum Addressing</title>
          <author initials="M." surname="Caleffi" fullname="Marcello Caleffi"/>
          <author initials="A. S." surname="Cacciapuoti" fullname="Angela Sara Cacciapuoti"/>
          <date year="2026"/>
        </front>
        <seriesInfo name="IEEE Transactions on Communications" value="74"/>
        <seriesInfo name="DOI" value="10.1109/tcomm.2025.3650397"/>
        <annotation>Invited Paper.</annotation>
  </reference>

  <reference anchor="CacCal26">
    <front>
      <title>A Quantum Internet Protocol Suite: Beyond Layering</title>
      <author initials="A. S." surname="Cacciapuoti"/>
      <author initials="M." surname="Caleffi"/>
      <date year="2026"/>
    </front>
    <seriesInfo name="IEEE Transactions on Network Science and Engineering" value="2026"/>
    <seriesInfo name="DOI" value="10.1109/TNSE.2026.3679795"/>
    <annotation>Invited Paper.</annotation>
   
  </reference>

   <reference anchor="IllCal22" target="https://www.sciencedirect.com/science/article/abs/pii/S1389128622002250">
        <front>
          <title>Quantum Internet Protocol Stack: a Comprehensive Survey</title>
          <author initials="J." surname="Illiano" fullname="Jessica Illiano"/>
          <author initials="M." surname="Caleffi" fullname="Marcello Caleffi"/>
          <author initials="A." surname="Manzalini" fullname="Antonio Manzalini"/>
          <author initials="A. S." surname="Cacciapuoti" fullname="Angela Sara Cacciapuoti"/>
          <date year="2022" month="August"/>
        </front>
   </reference>

      <reference anchor="RFC1958" target="https://www.rfc-editor.org/rfc/rfc1958">
       <front>
          <title>Architectural Principles of the Internet</title>
          <author initials="B." surname="Carpenter"/>
          <date year="1996"/>
          </front>
          <seriesInfo name="RFC" value="1958"/>
      </reference>

      <reference anchor="RFC3439" target="https://www.rfc-editor.org/rfc/rfc3439">
        <front>
          <title>Some Internet Architectural Guidelines and Philosophy</title>
          <author initials="R." surname="Bush"/>
          <author initials="D." surname="Meyer"/>
          <date year="2002"/>
        </front>
        <seriesInfo name="RFC" value="3439"/>
      </reference>


      <reference anchor="AbaCub25" target="10.1109/TQE.2025.3541123">
        <front>
          <title>Entanglement routing in quantum networks: A comprehensive survey</title>
          <author initials="A." surname="Abane"/>
          <author initials="M." surname="Cubeddu"/>
          <author initials="V. S." surname="Mai"/>
          <author initials="A." surname="Battou"/>
          <date year="2025"/>
          </front>
          <seriesInfo name="IEEE Transactions on Quantum Engineering" value="2025"/>
      </reference>

      <reference anchor="KreRam14" target="10.1109/JPROC.2014.2371999">
        <front>
          <title>Software-defined networking: A comprehensive survey</title>
          <author initials="D." surname="Kreutz"/>
          <author initials="F. M. V." surname="Ramos"/>
          <author initials="P. E." surname="Verissimo"/>
          <author initials="C. E." surname="Rothenberg"/>
          <author initials="S." surname="Azodolmolky"/>
          <author initials="S." surname="Uhlig"/>
          <date year="2014"/>
          </front>
          <seriesInfo name="Proceedings of the IEEE" value="2014"/>
      </reference>

  <reference anchor="yang2004rfc3746">
    <front>
      <title>Forwarding and Control Element Separation (ForCES) Framework</title>
      <author initials="L." surname="Yang"/>
      <author initials="R." surname="Dantu"/>
      <author initials="T." surname="Anderson"/>
      <author initials="R." surname="Gopal"/>
      <date year="2004"/>
    </front>
   </reference>
   

      <reference anchor="KurRos10" >
        <front>
          <title>Computer Networks: A Top-Down Approach</title>
          <author initials="J." surname="Kurose"/>
          <author initials="K." surname="Ross"/>
          <date year="2010"/>
        </front>
      </reference> 

      <reference anchor="KriCla07" target="https://doi.org/10.1145/1273445.1273450">
        <front>
          <title>On compact routing for the Internet</title>
          <author initials="D." surname="Krioukov"/>
          <author initials="K. C." surname="Claffy"/>
          <author initials="K." surname="Fall"/>
          <author initials="A." surname="Brady"/>
          <date year="2007"/>
        </front>
        <seriesInfo name="SIGCOMM Computer Communication Review" value="37"/>
      </reference>
 

  <reference anchor="Liu2024QBGP">
    <front>
      <title>Quantum BGP with Online Path Selection via Network Benchmarking</title>
      <author initials="M." surname="Liu"/>
      <author initials="Z." surname="Li"/>
      <author initials="K." surname="Cai"/>
      <author initials="J." surname="Allcock"/>
      <author initials="S." surname="Zhang"/>
      <author initials="J. C. S." surname="Lui"/>
      <date year="2024"/>
    </front>
    <seriesInfo name="IEEE INFOCOM" value="2024"/>
    <seriesInfo name="DOI" value="10.1109/INFOCOM52122.2024.10621359"/>
  </reference>


    </references>
  </back>
</rfc>
