| Internet-Draft | Quantum-Native Architectural Tenets and | October 2026 |
| Cacciapuoti, et al. | Expires 20 April 2027 | [Page] |
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 aspects of classical Internet design, remain aligned with one of its foundational insights: the principle of constant change, articulated in RFC 1958.¶
The document presents a quantum-native architectural framework that adopts an entanglement-packet-switching model and defines the architectural role and logical structure of quantum packets, with an explicit functional separation between the Quantum Data Plane and Quantum Control Plane. It introduces Quantum Internet Addressing as a complementary abstraction for quantum-native control and coordination, and Generalized Quantum Forwarding to encompass quantum-packet processing and the manipulation of entanglement resources.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 20 April 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
The Quantum Internet will interconnect quantum devices to enable distributed quantum functionalities built upon shared entanglement. RFC 9340 [RFC9340] laid the initial foundation for such an Internet, defining its motivation and goals. The role of a distinct Quantum Control Plane (QCP) was explicitly left outside its scope. Subsequent work on multiplane quantum network architectures has further highlighted the need for control functions [QI-MULTIPLANE]. In such a context, this document revisits the control-plane design question left open by RFC 9340 by considering not only the organization of control functions, but also the abstractions through which they access and act on quantum resources. It asks whether correctness should depend exclusively on separately maintained classical representations that must remain timely and causally aligned with evolving, non-local entanglement states. It also addresses the need to preserve quantum properties whenever these participate directly in the intended network functionality, beyond what a classical description alone can provide. Classical control mechanisms and signalling remain indispensable, but the document proposes an architectural framework in which they are complemented by quantum-native abstractions for quantum resource orchestration.¶
The first motivation for revisiting control-plane design arises from the orchestration of entanglement as an evolving distributed resource. Quantum entanglement is non-local, susceptible to decoherence, consumable, and dynamically evolving. It is therefore inherently a stateful resource [IllCal22] from a networking perspective. Specifically, local operations can transform the joint quantum state and its correlations, thereby reconfiguring the entanglement relations among network nodes that are available for subsequent network operations. Correctness consequently depends on resource awareness: the network functions involved must have access to information that remains operationally relevant as the resource evolves across nodes and over time. This requires monitoring relevant resource properties, timely dissemination of the associated information, and coordination within the applicable coherence and latency constraints. Although the information required depends on the intended functionality, the network has to track and expose explicitly resource descriptors, including fidelity or another task-relevant quality measure, residual coherence time, participating nodes, and resource allocation or ownership. Insufficient resource awareness and coordination can allow local changes to cause routing ambiguities, resource inefficiencies and, ultimately, network instability, illustrating the amplification principle discussed in [CalCac25].¶
The architectural concern extends beyond the richness of the descriptors to their association with the resources they describe. Whenever an entanglement resource is generated, transformed, consumed, lost, or replaced, the relevant control representation must remain correctly associated with it and sufficiently current for subsequent decisions. In this context, scalability concerns the ability to maintain correct resource orchestration as the number of participating nodes, distributed entanglement resources, and concurrent operations increases. Classical signalling may maintain the required alignment in controlled environments, but the scope and timeliness of the reconciliation on which subsequent decisions depend may become a scalability concern. The architectural question is therefore how to keep control information correctly associated and causally aligned with the evolving quantum resources it describes, while keeping the resulting reconciliation requirements manageable as the network scales.¶
The second motivation concerns the properties that a control abstraction must preserve for the intended network functionality. A classical representation can describe quantum resources and their properties, including the existence of coherent alternatives. However, that description does not itself preserve those alternatives as a quantum state on which coherent operations can act. This distinction matters whenever quantum properties participate directly in the network function, as in coherently controlled network tasks and operations [RamPirDur-21], [ChaShiRam-26], [CalCac25], [CacCal26]. Even a timely and causally consistent classical representation does not, by itself, provide the quantum control variables required by such functions.¶
Together, these considerations motivate complementary classical and quantum-native control abstractions. Classical mechanisms remain indispensable in a quantum network. Quantum-native abstractions extend this control framework by allowing quantum states and operations to participate directly in resource orchestration, while preserving the quantum properties on which the supported functions depend.¶
Building on the above considerations, this document complements the architectural framework established in RFC 9340 [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 [RFC1958], reaffirming that adaptability remains the cornerstone of Internet evolution.¶
The quantum-native architectural tenets defined in this document should be distinguished from specific realization mechanisms. In particular, the architecture is agnostic to the adopted routing algorithm, protocol-suite organization, physical realization of the quantum packet, and quantum repeater generation. These choices instantiate, rather than define, the architecture and should be evaluated separately according to their technological assumptions and resource requirements.¶
Specifically, this document introduces a quantum-native control and forwarding architecture composed of the following interlocking components:¶
Accordingly, this document defines three core abstractions -- Quantum Internet Addressing (QA), Generalized Quantum Forwarding (GQF), and Entanglement-Defined Controller (EDC) -- that together form an architectural framework intended to support scalable, entanglement-driven networks.¶
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.¶
This section defines key terms used throughout this document. Some definitions refine concepts discussed in RFC 9340; others introduce abstractions specific to the proposed architecture. The definitions reflect the complementary roles of classical mechanisms and quantum-native abstractions.¶
The above terminology forms the conceptual foundation of this document. The QDP and QCP represent the two functional planes of the architecture. ESPs execute GQF and the associated resource operations, while EDCs orchestrate entanglement resources, within their respective control scopes. QA provides a quantum-native addressing abstraction available to control and forwarding functions; GQF defines the operations through which the requested connectivity is realized.¶
The architecture proposed in this document adopts an entanglement-packet-switching paradigm in which the quantum packet constitutes the logical unit on which GQF operates within the QDP. A quantum packet comprises a quantum header, carrying quantum addresses and additional control or processing information where required by the adopted realization, and a quantum payload, carrying entanglement resources. This paradigm is not a mere refinement of classical packet switching: it is a design choice motivated by the non-local, volatile, consumable, and stateful nature of entanglement, which changes what a packet-like unit operates on. Indeed, classical packet forwarding transfers information-carrying packets through the network. In the entanglement-packet-switching model adopted here, GQF processes quantum packets and manipulates distributed entanglement resources to realize the connectivity required by a network service. Progress may involve local transformations, consumption or reconfiguration of shared resources, and physical transfer of quantum systems where required. It does not require an unchanged packet to traverse every physical link.¶
The proposed switching model revisits end-to-end simplicity: the architectural philosophy of a relatively simple network providing best-effort packet delivery, with functionality concentrated at the endpoints [RFC1958], [RFC3439]. As discussed in [BroMarBal-24], the deployment of middleboxes and edge networking services has already moved substantial functionality into the classical Internet infrastructure.¶
In the entanglement-based service model adopted here, the need for in-network operations and resource-state awareness arises from the stateful nature of entanglement itself, being a non-local, volatile, and consumable communication resource. These requirements apply throughout the entanglement lifecycle, from generation and distribution to storage and final utilization. A broader discussion of the notion of statefulness adopted in this document is provided in [IllCal22]. Combined with the sophisticated and resource-intensive nature of quantum hardware, these requirements motivate assigning entanglement-processing and resource-management functions to network entities, allowing edge nodes to delegate these functions where appropriate and remain comparatively lightweight in their networking role. The proposed architecture adopts an explicit functional separation between the QDP, which processes quantum packets and manipulates entanglement resources through GQF, and the QCP, which orchestrates those resources by complementing classical control and signalling with quantum-native abstractions.¶
| Network feature | Classical Internet | Quantum-native Architecture |
|---|---|---|
| Resource behavior | Communication links are comparatively persistent relative to packet-forwarding dynamics | Entanglement resources are non-local, volatile, consumable, and overall stateful from a networking perspective |
| Control plane | Primarily grounded in topology-driven abstractions such as IP-style addressing | Classical control is augmented by quantum-native abstractions, including QA |
| Data plane | Packet forwarding | GQF over quantum packets and entanglement resources |
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 generate, store, transfer, and manipulate entanglement resources to establish, extend, maintain, transform, or consume quantum correlations across the network. The role of the QDP therefore extends beyond transporting user information. The resulting connectivity supports applications, including (but not limited to) quantum information transfer via quantum teleportation and distributed quantum processing.¶
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 [AbaCub25]. Their execution depends on the availability and operational condition of the relevant resources. Consumption or degradation may require resource replenishment, while resources that no longer meet the requirements of the intended functionality may need to be discarded. These primitives are illustrative and do not prescribe a particular physical realization or quantum repeater generation.¶
The QDP interfaces closely with the QCP to expose resource information relevant to the intended network functionality, such as resource identifiers, participating nodes, availability and reservation status, estimates of fidelity or another relevant quality measure, and remaining coherence budget. These descriptors provide an operational view of the resources. Their validity clearly depends on the adopted monitoring and estimation mechanisms. They support resource allocation, path selection, maintenance, and recovery within the relevant control scope. Classical signalling remains necessary for functions such as heralding, measurement outcomes, acknowledgments, and conditional operations. Hence, the QCP--QDP interaction augments these classical mechanisms with quantum-native control abstractions, where supported by the adopted realization. Detailed protocol specifications are out of scope for this document.¶
+-------------------------------+ +-------------------------------+ | Plane Abstraction | | Network and | | | | Logical Entities | | +---------------------------+ | | | | | (1) (QCP) | | | +---------------------------+ | | | Quantum Control Plane: | | | | (3) (EDC) | | | | Entanglement-Orchestrator | | | | Entanglement-Defined | | | +---------------------------+ | | | Controller: | | | ^ | | | QCP's Logical Entity | | | | | | +---------------------------+ | | Controller Functions: | | ^ | | - Reconfiguration | | | | | - Monitoring | | Controller Functions: | | - Policy Enforcement | | - Reconfiguration | | | | | - Monitoring | | v | | - Policy Enforcement | | +---------------------------+ | | | | | | (2) (QDP) | | | v | | | Quantum Data Plane: | | | +---------------------------+ | | | Operational Plane | | | | (4) (ESP) | | | +---------------------------+ | | | Entanglement Service | | | | | | Provider: | | | | | | QDP's Network Entity | | | | | +---------------------------+ | +-------------------------------+ +-------------------------------+
The QCP is the entanglement-orchestration plane of the Quantum Internet. It coordinates resource awareness, management, and policy enforcement across the network at the scope required by the adopted deployment and administrative model.¶
In this document, the term control plane is adopted from classical networking terminology, where it denotes the network-wide logic that determines and coordinates data-plane operation, including routing, forwarding behaviour, as well as the configuration and management of network entities and their services [yang2004rfc3746], [KurRos10]. In this document, these responsibilities extend to the orchestration of distributed entanglement resources, as defined in Section 3. The QCP coordinates their provisioning, maintenance, reconfiguration, and recovery according to service requirements and network policies, while the corresponding quantum-packet processing and entanglement-resource operations are executed within the QDP. The stateful nature of entanglement makes this orchestration sensitive to resource evolution and coherence-time constraints.¶
As discussed in Section 1, effective resource orchestration is essential for scalable quantum network architectures. It requires control information to remain correctly associated and causally aligned with the resources on which network decisions depend. When a classical control representation is maintained separately from the quantum resource it describes, generation, transformation, consumption, loss, or replacement of that resource may require the representation to be reconciled across the affected nodes and functions. These distributed dependencies become particularly explicit with multipartite entanglement [IllCal22]. Classical signalling can maintain the required alignment, but the scope and timeliness of reconciliation may become a scalability concern as the number of participating nodes, distributed resources, and concurrent operations increases. The architectural issue therefore extends beyond the richness of resource descriptors: even detailed control information must remain associated with the relevant resource and sufficiently current for the decisions that depend on it. Scalability, in this context, concerns the ability to maintain correct resource orchestration as these distributed dependencies grow.¶
A complementary requirement arises when quantum properties participate directly in a network functionality. Examples include the exploitation of quantum coherence in network tasks [RamPirDur-21] and the use of quantum control variables to coherently control propagation over alternative paths [ChaShiRam-26], [CalCac25], [CacCal26]. These functionalities require access to corresponding quantum-control states and preservation of the coherence on which their operation depends. A classical description does not itself provide the quantum variables on which coherent operations act. The QCP therefore complements classical control with quantum-native abstractions, including Quantum Internet Addressing (QA), that allow quantum variables to participate directly in control and coordination. The corresponding quantum operations are performed by quantum-capable nodes. This does not require every control function or every EDC to manipulate quantum states. This capability requirement is distinct from maintaining a causally consistent representation of resource status.¶
Classical control mechanisms and signalling remain integral to the architecture. Both the QCP and QDP rely on classical communication for their respective functions, including heralding, acknowledgments, and the transmission of measurement outcomes needed for conditional operations [RFC9340]. Detailed mechanisms for the interaction between classical and quantum-native control functions are outside the scope of this document.¶
Architecturally, the QCP defines functionally distinct yet tightly coupled control logic with respect to the QDP. ESPs, as network entities of the QDP, expose local entanglement capabilities and resource information relevant to the intended network functionality, while EDCs, as logical entities of the QCP, coordinate resource management and policy enforcement within their respective control scopes.¶
This separation distinguishes resource-orchestration responsibilities from the execution of packet-processing and resource operations without prescribing a particular protocol-suite organization or precluding local procedural control during packet processing. For example, in the realization described in [CacCal26], nodes construct local execution plans from packet-carried information and their current local state. EDCs may supply optional hints to assist planning and policy enforcement, but the local service-fulfillment procedure in [CacCal26] does not require such hints. Thus, the functional separation between QCP and QDP does not imply that an EDC must prescribe each step of service execution.¶
| Classical Tenets | Quantum-Native Tenets |
|---|---|
| Complexity primarily located at the network edges | Complexity concentrated in the core network |
| Stateless core network | Stateful core network |
| Applications at end nodes supported by packet-delivery services | Applications at end nodes supported by network-provided entanglement |
Building on the above considerations, the network architecture is functionally organized into a two-tier structure that distinguishes between ESPs and edge quantum nodes. This functional organization does not prescribe a particular physical deployment, routing model, or administrative structure.¶
Overall orchestration is achieved through EDCs: distributed logical entities that maintain global or partial network views, within their respective control scopes, of the physical-network graph, the entanglement graph, and the associated entanglement-resource state. EDCs act as the quantum-native counterpart of SDN controllers, augmenting classical control logic with quantum-native abstractions.¶
EDCs perform primarily three control-plane functions:¶
Accordingly, within this architecture, EDCs orchestrate entanglement-resource provisioning, maintenance, reconfiguration, and policy within their control scopes. This network-level responsibility does not require an EDC to construct or authorize every local packet-processing plan. In the protocol organization of [CacCal26], nodes can construct local Plans of Action and advance service fulfillment without EDC hints.¶
The EDC abstraction defines a logical control entity without prescribing a particular deployment model. The architecture supports multiple EDCs and allows their implementation to be centralized, distributed, or federated. Where their control responsibilities interact, EDCs coordinate the resource information and policies needed for the affected operations. The scope and consistency requirements of this interaction depend on the adopted realization.¶
+---------------------------------------+
| (2) |
| Entanglement Defined Controller (EDC) |
+---------^-----^-----^-----------------+
| | |
| | +-- Policy Enforcement
| +-------- Monitoring
+-------------- Reconfiguration
| | |
Quantum Control Plane (QCP)
------------------------------------------------------------------
Quantum Data Plane (QDP) Entanglement-defined Networking
| | |
+---------v-----v-----v-----------------+
| Top Tier (1) |
| Tier 2 |
| +-------+ +-------+ +--------+ |
| | ESP_1 +---+ ESP_2 +-...-+ ESP_n | |
| +-------+ +-------+ +--------+ |
+---------------------------------------+
The functional separation between the QCP and the QDP does not, by itself, determine how network identities are represented in quantum-network functions. Classical addresses remain necessary for classical communication and signalling. However, a classical address, grounded in topological information such as an IP address, does not by itself describe every relation on which an entanglement-based network function may operate: nodes sharing entanglement may be operationally connected without being physical neighbors, while the availability and condition of their shared entanglement may change over time.¶
Quantum Internet Addressing (QA) provides a complementary abstraction in which node identities, including coherent alternatives where required, are represented as quantum states on which suitable network functions can operate. QA complements, rather than replaces, classical addressing. In the architecture presented in this document, each network node is associated with two types of identifiers: i) a classical address, such as an IP address, required for classical communication and signalling; and ii) a quantum address, represented by a quantum state |A> of an N-qubit register.¶
The register can encode an individual node identity in a distinguishable state or a coherent superposition of states encoding alternative node identities. A superposed address can thus represent alternative nodes regardless of their physical or topological location. A superposition of identifiers is not an independently readable classical list, and its operational meaning depends on the function and the operation applied to it. The relevant operation determines whether and how the represented identities are queried, selected, or otherwise used. The identities may be associated with candidate paths or domains.¶
QA can be used by QCP functions and QDP operations. For example, the routing construction in [CalCac25] uses quantum addresses to operate over entanglement-defined connectivity. In the protocol organization of [CacCal26], quantum addresses identify participants within a broader packet-carried service intent. These are distinct uses of the addressing abstraction; neither realization, nor the routing properties established for the former, is required by this document.¶
The architecture adopts a quantum packet as the logical unit processed in its entanglement-packet-switching model. The packet need not correspond to a fixed block of qubits transported unchanged across every link. At a node, header information, together with locally available resource information and applicable control decisions, may guide the packet-processing and entanglement-resource operations to be performed. The locally accessible constituents of the associated entanglement resources may be transformed, consumed, or left unchanged; where required, quantum systems may be physically transferred to another node. The packet thus progresses logically through operations on distributed resources, which may include local transformations and inter-node transfers, without requiring the same physical carriers to traverse every link.¶
A quantum packet consists of a quantum header and a quantum payload. This is a logical decomposition and does not prescribe how either component is physically encoded.¶
|e_i> constituting the network resource on which GQF operates. The header provides the procedural information used to determine how the payload is processed. Depending on the operation, the payload may be transferred, transformed, stored, consumed, 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 [CacCal26].¶
The following table illustrates the conceptual structure of a quantum packet. It does not prescribe a physical encoding, and the model is not limited to bipartite entanglement.¶
| Quantum Header | Quantum Payload |
|---|---|
- Quantum address field(s) |A>- Additional metadata |
- Entangled qubits |e_i>(bipartite or multipartite resources) |
In this document, |A> denotes the generic addressing abstraction. A realization may specialize it into distinct fields, such as source and destination identifiers or coherent superpositions of node identifiers.¶
The establishment and use of quantum connectivity involve distinct routing and forwarding functions [AbaCub25]. Routing determines a candidate entanglement path (or, more generally, an entanglement graph), according to the selected routing metric and the available resource-state information. GQF processes quantum packets and performs the operations needed to establish, extend, maintain, transform, or consume that quantum connectivity. These operations may include elementary link-level entanglement generation, swapping, and purification, as well as the physical transfer of quantum systems where required. This functional distinction does not require routing and GQF to be implemented as strictly sequential phases.¶
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 a forwarding table. Here, this logic is generalized toward a broader meaning: GQF uses the applicable packet information and locally available resources to determine and execute operations on quantum packets and entanglement resources. Therefore, in this document, forwarding does not necessarily denote the hop-by-hop transmission of an unchanged packet.¶
Within the architecture, GQF is supported by the interaction between the QDP and the QCP, through the EDCs and ESPs:¶
QA provides quantum-encoded identifiers that can be operated on by QCP functions and during GQF in the QDP. The packet carries quantum addresses and any additional control or processing information specified by the adopted realization. The architecture does not require it to carry a complete forwarding table or network-resource inventory.¶
GQF defines a forwarding abstraction, not a particular action sequence, lookup mechanism, physical packet encoding, or routing algorithm. Its realization may combine quantum operations, classical processing, and the classical signalling needed to execute and coordinate those operations.¶
The following principles summarize the design choices of the architecture presented in this document. They do not prescribe a routing protocol, a protocol-suite organization, or a physical realization.¶
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, QCP, QA, and GQF are intended to remain applicable across different regimes of entanglement generation and different physical realizations of quantum repeaters.¶
The QCP orchestrates entanglement resources while the QDP executes the underlying quantum operations. This functional distinction 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, and hybrid regimes combining both approaches.¶
In quantum routing, routing decisions may precede the actual availability of entanglement. This stems from the volatile and consumable nature of entanglement resources, which may be consumed by operations such as entanglement swapping, lost, or rendered unusable as their fidelity or residual coherence time evolves. Accordingly, the architecture distinguishes between two complementary graph-based views:¶
A realization may use the physical-graph view to plan the generation of additional resources and the entanglement-graph view to select among resources already available. The QCP coordinates resource management within the relevant control scope, while ESPs execute the applicable operations in the QDP. This division does not require an EDC to initiate every generation attempt or prescribe every local operation. Nor does it require either graph view to be globally complete or synchronized.¶
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 identifiers, or sets of identifiers, representing candidate nodes or domains and supporting operations over candidate paths. In particular, QA enables reasoning over potential connectivity before entanglement resources are instantiated, supporting scalable orchestration decisions such as which physical links to activate, which paths to provision, or which domains to involve in distributed coordination.¶
GQF executes the local operations required to establish, extend, maintain, transform, consume, or, where required, physically transfer entanglement resources. These operations may be guided by quantum identifiers and optional control or processing information carried in the quantum header, together with locally maintained routing and resource-state information. GQF may exploit already available resources represented in the entanglement graph or execute or participate in procedures that generate additional resources through the physical graph. The architecture does not require a particular lookup or search mechanism, and implementations may use quantum, classical, or hybrid processing as appropriate.¶
Repeater-generation classifications distinguish physical approaches to loss and operational-error management. They do not classify the control and data-plane functions defined in this document. Within this architecture, a repeater is treated primarily as a network function rather than as a fixed network entity. Accordingly, the architectural tenets remain applicable across repeater generations, while the physical mechanisms implemented in the QDP may evolve with technological progress.¶
In first- and second-generation repeater networks, heralded entanglement generation, classical signalling, and entanglement swapping may constitute central operational primitives, while purification or quantum-error-correction mechanisms may be used according to the adopted repeater realization. QA represents the quantum identifiers of the participating nodes, while the entanglement-graph view maintained within the QCP reflects the dynamic entanglement relations established among them. GQF executes the corresponding local operations on the available entanglement resources.¶
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 quantum-native control abstraction for node identifiers, or sets of node identifiers, while the resource representations and operations supported by the QDP may refer to logical quantum systems or logical entanglement resources. Nevertheless, the functional distinction between the QDP and QCP, the orchestration role of EDCs, and the GQF abstraction remain applicable.¶
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.¶
The following section therefore illustrates how the functional distinction between the QDP and QCP, together with the QA and GQF abstractions, can support intra-domain and inter-domain routing and forwarding in a multi-domain deployment. This discussion is illustrative rather than prescriptive and does not mandate a particular multi-domain routing protocol or administrative model.¶
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.¶
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.¶
Across domains, routing information is exchanged between boundary ESPs belonging to different administrative domains. The information exposed and its validity are matters for the adopted inter-domain mechanism and administrative agreements. Because inter-domain routing spans independently operated networks, it cannot rely on a single centralized controller [CalCac25]. Instead, routing information propagates through distributed coordination between domain-level controllers and gateway ESPs.¶
Control coordination may involve EDCs, boundary ESPs, or both, according to the deployment. Recursive organization, as explored by QRNA [VanTouHor-11], can abstract a domain without exposing its complete internal topology. Such organization is compatible with the functional abstractions in this document, but the association and timely reconciliation of resource information across domain boundaries remain to be specified by a realization.¶
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 [Liu2024QBGP]. However, in the quantum networking context, routing decisions may also account for entanglement-generation probability, fidelity, residual coherence time, availability, reservation state, and the cost of the operations required to establish the requested connectivity. The QA abstraction can support operations over identifiers, or sets of identifiers, associated with candidate nodes or domains. The selection among candidate paths or forwarding targets nevertheless depends on the adopted routing realization, administrative policies, and available resource-state information.¶
The QCP therefore combines two complementary roles:¶
Classical signalling remains necessary for exchanging such information. The architecture does not require inter-domain reachability information or complete entanglement-resource state to be represented or disseminated exclusively through quantum states.¶
As discussed in Section 5, QA enables identifiers, or sets of identifiers, associated with nodes or domains to be represented and operated upon as quantum states. QA does not require forwarding entries to be associated exclusively with individual nodes, nor does it require the packet to carry a complete routing table. Routing and resource-state information remain locally maintained by ESPs. The mapping from those identifiers to domain-level reachability, resource information, and policy is defined by the adopted routing and control mechanisms.¶
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.¶
In an inter-domain context, QA may represent the identifiers of reachable nodes or domains and support operations over candidate forwarding targets. Information concerning established entanglement resources---including their availability, fidelity, ownership, reservation state, and residual coherence time---remains part of the corresponding resource-state views. Any compactness or path-stretch properties depend on the adopted encoding and routing construction and are not guaranteed by QA alone.¶
Once routing information has been installed at ESPs, forwarding decisions are executed locally through GQF in the QDP. In this document, forwarding is used in a generalized sense and does not necessarily denote the hop-by-hop transmission of an unchanged packet. An ESP may process quantum identifiers and optional control or processing information carried in the quantum header together with its locally maintained routing and resource-state information. The architecture does not prescribe whether the corresponding lookup and decision procedures are quantum, classical, or hybrid.¶
The resulting GQF operations may establish, extend, maintain, transform, consume, or, where required, physically transfer entanglement resources. Depending on the adopted routing and resource-provisioning model, an ESP may select a candidate next processing node, generate elementary link-level entanglement with a physically adjacent ESP, allocate locally available resources, or perform entanglement swapping. Identifying a forwarding target does not, by itself, select a specific locally held quantum system or establish that sufficient resources are available; concrete resource selection and allocation remain local resource-management decisions.¶
As an Informational document, this draft does not propose any specific mechanisms to ensure security. The security considerations provided in RFC 9340 apply for this document as well.¶
This memo includes no requests to IANA.¶
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.¶