| Internet-Draft | qi-multiplane-arch | July 2026 |
| Lopez, et al. | Expires 4 January 2027 | [Page] |
A consistent reference architecture model for the Quantum Internet is required to progress in its evolution, providing a framework for the integration of the protocols applicable to it, and enabling the advance of the applications based on it. This model has to satisfy three essential requirements: agility, so it is able to adapt to the evolution of quantum communications base technologies, sustainability, with open availability in technological and economical terms, and pliability, being able to integrate with the operations and management procedures in current networks. This document proposes such an architecture framework, with the goal of providing a conceptual common framework for the integration of technologies intended to build the Quantum Internet infrastructure and its integration with the current Internet. The framework is based on the already extensive experience in the deployment of QKD network infrastructures and on related initiatives focused on the integration of network infrastructures and services.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://dr2lopez.github.io/qi-multiplane-arch/draft-irtf-qirg-qi-multiplane-arch.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-irtf-qirg-qi-multiplane-arch/.¶
Discussion of this document takes place on the Quantum Internet Research Group Research Group mailing list (mailto:qirg@irtf.org), which is archived at https://mailarchive.ietf.org/arch/browse/qirg/. Subscribe at https://www.ietf.org/mailman/listinfo/qirg/.¶
Source for this draft and an issue tracker can be found at https://github.com/dr2lopez/qi-multiplane-arch.¶
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 4 January 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.¶
As another case of the "classical vs quantum" apparent contradictions, the nature of quantum communications [QTTI21], associated with natural physical effects that require a specific infrastructure to be used for communications, poses a significant challenge in the definition of any network reference architecture to be used for such communications. Furthermore, given that a quantum network necessarily depends on some classical communications and protocols to function fully, we need this reference network architecture to also incorporate these classical elements. We should not think of two separate environments, but rather a unified one where the classical and quantum parts interoperate as seamlessly as possible. The growing interest in quantum networking, its applications, and the eventual availability of a Quantum Internet, require of consensus on an architecture framework able to support the definition and evolution of different protocols and interfaces.¶
Several steps have been taken in this direction, including the identification of architectural principles and base technologies made in {RFC9340}}, the description of relevant use cases [RFC9583], and specific approaches to layered models for Quantum Networking, summarized and discussed in [QIPS22]. While the principles provide an extremely valuable common ground for further collaboration among quantum and network practitioners, they are not intended to provide the solid framework required for progressing in the definition of specific protocols and other interfaces for common network management tasks and interactions with user applications. On the other hand, the proposals made for a layered approach provide interesting insights on requirements and potential mechanisms to structure quantum communications, but, first, they do not include essential aspects for a network at scale and, second and most important, they do not take into account the need for direct interactions beyond the layered structure, such as those between classical and quantum networking services, between applications and the quantum network, etc.¶
In parallel, the operational experience with the first kind of infrastructures using quantum communication technologies to provide an actual network service, those focused on Quantum Key Distribution (QKD), has allowed practitioners to explore the solution space and identify design patterns that can serve as concrete examples within the general case of a Quantum Internet. A corpus of architectural proposals [ITUY3802], experimental deployments [MADQCI23] and pilot infrastructures [EUROQCI] have become available in the recent years, and can be used to derive useful conclusions, especially if combined with recent proposals in network architecture [RFC8597], intended to address the complexity of management and integration at scale beyond the basic layered constructs supporting connectivity.¶
This document is intentionally a framework document: it does not prescribe a single protocol stack or a fixed layering. Instead, it provides a set of architectural anchors that allow new proposals to be positioned, compared, and discussed consistently. The document proposes a multi-plane reference architecture for the Quantum Internet, derived from available proposals and operational experience. The proposal attempts to define a framework with three essential properties to guarantee a seamless evolution of the technology, and the consolidation of applications and management practices:¶
Agility: Provide abstractions able to incorporate new protocols and interfaces as the technology evolves, avoiding a tight coupling with specific physical technologies.¶
Sustainability: Considering it at all levels and in full scale, especially regarding environmental and social impacts, including open availability in technological and economical terms, and fostering infrastructure reuse.¶
Pliability: Facilitate the seamless integration of classical and quantum network operational procedures, applying and adapting best practices in use by the Internet community.¶
And trying to address three essential characteristics already identified in [PSQN22]:¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
SDN concepts are at the core of current networking technologies. From the original ideas of separating control and forwarding planes, connected by open interfaces and supporting programmability and logically-centralized management. As part of this evolution of SDN concepts, the Cooperating Layered Architecture for Software-Defined Networking (CLAS) [RFC8597] described a SDN architecture structured in two different strata, namely Service Stratum and Transport Stratum. On one hand, the Service Stratum contains the functions related to the provision of services and the capabilities offered to external applications. On the other hand, the Transport Stratum comprises the functions focused on the transfer of data between the communication endpoints, e.g., between end-user devices, between two service gateways, etc.¶
It is worth noting this management centralization does not contradict the distributed principles generally applied in current networks. Local control decisions are intended to be coordinated by centralized management. While the communication between the controller and the controlled elements relies on some kind of SDN protocol, the controller exposes a consistent abstract model of the network devices and topology, that can be structured in a hierarchy of abstractions, from lower-level, element-focused ones, up to application-oriented ones.¶
While SDN ensures higher degrees of flexibility and reconfigurability by allowing network functions to be easily modified and upgraded through software changes, virtualization enables the abstraction of hardware devices by creating virtual instances, which improves scalability, resource efficiency and allows the dynamic allocation of softwarized network functions in different locations. As quantum technology evolves, a virtualized layer for softwarized network functions significantly aids adaptation to these changes, ensuring pliability and responsiveness for seamless updates, and incorporating new mechanisms without extensive hardware modifications.¶
These approaches pave the way for a tighter integration of quantum functionality with functions already established in state of the art classical networks, including support for user/function authentication and authorization, and support for user and function mobility, while adhering to established network standards. Integrating these mechanisms enhance security measures and ensure that quantum networks can seamlessly interface with existing and future telecommunications infrastructure.¶
The use of these base technologies support a seamless interface with classical networks (commonly identified as OTN, Optical Transport Networks), addressing three basic principles, related to the ones we mentioned above: facilitate the coexistence on physical infrastructure (sustainability and transparency), apply the abstractions commonly used in open and disaggregated networks (agility and universality), and reuse the best practices in network management being applied in current infrastructures (pliability and scalability).¶
SDN and virtualization support the integration of control and management, even if the distinct nature of network elements and the mediation nature of the controller role do not make advisable the use of common quantum/OTN controllers. There are common abstractions able to support cross-interactions among controllers and management applications, especially regarding:¶
Quantum management applications requiring operations on topologies and physical paths in the OTN mediated by an OTN controller.¶
OTN management applications requiring operation on quantum topologies mediated by the quantum controller.¶
Topology updates exchanged between quantum and OTN controllers.¶
The coordination through an integrated controller (commonly referred as "orchestrator"), able to provide a common view to application network functions.¶
The design and deployment of QKD infrastructures has followed a number of design principles, based on the best practices in network architecture and management established during the lifetime of the Internet (and even before), and focused on the separation of concerns, that have been converging on the trends around applying SDN principles and virtualization mechanisms, addressing open disaggregation strategies and the identification of separate data and control planes, connected by means of open interfaces. This section reviews the practical knowledge acquired from the engineering and operation of QKD infrastructures and uses them as a practical reference point for the architectural discussion that follows. Although several of the concepts and interfaces examined here have been shaped by specific QKD implementations and standardization efforts, the intention is to highlight which elements appear reusable as general design patterns and which remain specific to the assumptions and limitations of QKD. In that sense, QKD is treated in this document primarily as an informative example within a broader architectural space, and the discussion is framed in a way that remains compatible with other quantum networking technologies and service models as they mature.¶
Applying the SDN and disaggregation principles, QKD infrastructures have been essentially structured around three different planes [QTTI21]. While we are not talking about a rigid, layered structure, where a given layer can only provide services to the immediate upper layer and consume services from the immediate lower layer, it is worth noting that interactions among elements in the different planes must use well-defined interfaces [ETSI04] [ETSI14] [ETSI15] [ETSI18], and these interactions may incorporate a layered approach.¶
In this approach, the Quantum Forwarding Plane (QFP) is in charge of performing the operations (quantum and classical) to ensure the exchange of the quantum signals or enable the utilization of persistent quantum resources, like persistent, distributed entanglement. In QKD, the QFP encapsulates all the functionality required to obtain an end-to-end secret key across the network. This implies the transmission of the quantum signals and the execution of any associated protocols. Note this would require the use of classical procedures, either via a separated physical "classical channel" [QTTI21] or the reuse of a common channel, as proposed in "packet-oriented" approaches [PSQN22]. In this sense, the forwarding of the keys at intermediate nodes in the multi-hop chains used to overcome current limitations in propagation of quantum signals or states, has to be considered part of the QFP, since it is done exclusively on behalf of the QKD functionality.¶
On its side, the Service Overlay Plane (SOP) supports the use of the keys derived from the QFP by applications. This includes the storage, identification, delivery, and lifecycle management of the units of consumption (keys of different length, delivered according to specific patterns) at the endpoints of the network. All network functionalities at this plane can be considered application-oriented, with a clear mapping to an overlay data plane in a classical network, though the SOP elements should be aware of the nature and specific needs of the QFP they interact with. Key management mechanisms, beyond key forwarding by intermediate nodes, fit within the SOP. This comprises methods such as hybridization and augmentation techniques, or the means for synchronizing key identifiers across API boundaries.¶
Finally, the Control and Management Plane (CMP) is made of the elements that create and supervise the state of the network. This decoupling between network configuration and (general) data forwarding is supported by the controller, a mediation logically centralized element between the control capabilities supported by the elements in the QFP and SOP and the management and control functions. These management and control applications rely on the controller, taking advantage of the centralization it provides, to guarantee the best performance of the network and avoid diverging local control decisions that might lead to sub-optimal configurations.¶
Supported by these abstractions, QKD infrastructures are evolving from a conglomerate of links, where keys derived from the protocol applied to a link are used to secure the communication between two entities directly associated to the endpoints of the link, into real networks, able to forward a key to be used between any two entities attached to the network. The entities in the SOP play a key role for this, supporting the storage, delivery and lifecycle management of the service units being consumed by the applications attached to the network. These SOP entities, are commonly referred as KME (Key Management Entity), acting as key storage for a specific element or elements in the QFP, and providing an endpoint for applications to request and consume keys for a specific secure interaction. The interfaces KMEs use to interact with the QFP elements are usually provided by specific (commonly software-based) components, acting as agents in the QFP, and therefore termed Key Management Agent (KMA).¶
Several of these KMEs can be logically grouped into what is called a KMS (Key Management System), supporting a set of related applications grouped into a trust domain, and therefore consistently operated by a corresponding entity in the CMP. The differentiation between KME and KMS functionalities becomes more apparent as networks expand and consolidate, with many cases of current QKD link-oriented infrastructures referring to a KMS as the entity integrating both roles.¶
In summary, QKD infrastructures are converging into an extended SDN model, with two differentiated data planes, controlled in a coordinated manner through a common Control and Management Plane, that supports aggregated mechanisms for further orchestration. The QFP/SOP duality constitutes a common abstract foundation for a general approach to quantum communications networks, regardless of their final purpose.¶
At the application level, end-to-end key management and end-to-end key creation are obviously the main target. Since many applications of these keys are related to classical communications (direct encryption, key derivation for symmetric algorithms, peer identity…) there is a clear interface for the SOP, with classical network functions acting as consumers of the keys or, in general terms, the bit streams generated by the QFP. Further on, the application of NFV mechanisms to any network function allows for its implementation through software virtualization techniques (virtual machines, para-virtualization containers, unikernels, etc.), irrespectively of their application environments or specific plane. The lifecycle management of all network functions, of any nature, under a common MANO stack [NFV06], seems the most reasonable option.¶
While there is a radical difference between the network elements in quantum networks and OTN, and therefore interactions in data forwarding are not feasible, with only two exceptions: the possibility of sharing physical media, and the use of classical channels to support QKD algorithms, as it is the case of distillation channels in protocols like BB84. In this case, a proper control of the path and physical parameters has to be applied to minimize interferences of any nature and guarantee optical classical connectivity for the quantum algorithms.¶
Recent proposals for QKD network management have explored the use of operational models that radically leverage the virtualization of control and key management functionalities [EVCK25]. For key exchange, current technology does not allow direct end-to-end quantum key exchange between distant nodes. Instead, key distribution must rely on trusted intermediary nodes to transmit keys hop-by-hop. A key management layer where the actions of all nodes are coordinated is needed to ensure secure and efficient key distribution. Virtualizing and decoupling key management from the physical QKD devices enhances flexibility and scalability, and supports the integration of hybrid cryptographic strategies, combining QKD and post-quantum algorithms to ensure security and performance. Additionally, it allows real-time performance monitoring, data-driven control and management, and tailored access and admission mechanisms [QNSA24].¶
The virtualized key management layer acts as an intermediary between the clients and the cryptographic material generating devices. This layer would have as functions both those that fall within the framework of the SOP defined in previous sections, as well as key forwarding, specific to the QFP. For the latter, each functional element of this layer, identified as key managers entities in [EVCK25], has a forwarding table, which can be dynamically updated whenever necessary by the control plane. Additionally, they implement a token bucket for each application session, to control the request rate by limiting it to an agreed-upon value at the Quality of Service (QoS) level.¶
The virtualized control plane can have different functional elements, and, as with the key management layer, several instances of the same element can be executed as necessary for the correct operation of the network. Foundational elements include: a controller, an access control and an admission control component, a routing module, and a monitoring element. This set allows the execution of network access policies, ensuring that no unauthorized user or process enters the network, verifies the configuration parameters of new sessions opened by applications, ensuring that they are granted the appropriate QoS, and performs performance tests on the physical links and collecting statistics on the QKD modules, quickly alerting about any failure or possible attack on the QFP.¶
Based on the available experience on the deployment of existing QKD infrastructures and on the evolution of SDN-enabled architectures described in the previous section, this document proposes an architecture framework intended to offer a conceptual common framework for the integration of technologies intended to build the Quantum Internet infrastructure and its integration with the current Internet.¶
Once we presented in the previous section the lessons learned from QKD deployments, introducing a general architecture applicable to those deployments, in this section we propose the generalization of such architecture towards a Quantum Internet, augmented by the extended SDN approach proposed by the evolved CLAS in [CLASEVO]. In what follows, we will discuss how this framework architecture would support the required properties: agility, allowing for technology evolution, sustainability, fostering infrastructure reuse, and pliability, supporting operational best practices.¶
As discussed in the previous section, SDN principles have enabled the base abstractions for the conceptualization of QKD infrastructures, including the services they provide and the required interactions in the use of classical infrastructure to support the required connectivity patterns. The original CLAS architecture, as defined by [RFC8597], addresses SDN evolution considering the forwarding (transport) and service aspects in two separated but coordinated planes. This approach matches the multi-plane approach described for QKD infrastructures, though it seems somehow limited to address the required interactions with physical connectivity, as well as to incorporate general requirements regarding automation to support convergence with operational practices.¶
The new extension of the CLAS architecture, as defined in [CLASEVO], intends to address the current evolution of networks and the services they support introducing new aspects, in particular the considerations of distributed computing capabilities attached to different points in the network, and the introduction of evidence-driven techniques, such as Analytics, Artificial Intelligence (AI) and Machine Learning (ML) to improve operations by means of closed-loop automation.¶
The CLAS framework provides a sound foundation for incorporating the experience gained with QKD deployments in a general proposal applicable to the Quantum Internet, as it is essentially compatible with the architectural lessons learned within the QKD fields, and at the same time supports additional degrees of freedom regarding the integration of control mechanisms, and the interplay with the (shared) infrastructure and its management.¶
Furthermore, we propose here a general network architecture trying to incorporate relevant trends such as cloud nativeness, the integration of zero-touch management, or the considerations about intent. With this in mind, in what follows a CLAS-based architecture frameworks for quantum communications networks is introduced, including the proposed strata and their main characteristics.¶
The CLAS architecture was initially conceived from the perspective of exploiting the advantages of network programmability in operational networks, complementing and going beyond the traditional layered structure of the original SDN proposal. Following the CLAS philosophy, as proposed in its recent update [CLASEVO] of decoupling services, additional functionality, and base connectivity, the architecture of a quantum network should be composed of:¶
A Service Stratum, dealing with the functionality related to the purpose of the quantum network, and aligned with SOP described for QKD networks above. At this moment, the most general service, beyond QKD key management, is obviously entanglement distribution in a general quantum network. This stratum is intentionally defined in a technology and service-agnostic way. It does not assume a fixed layering or a single, primary service. In addition to QKD key management, candidate services include entanglement distribution, time synchronization, identity assurance, or sensing. The service stratum would consider the relevant service units (keys, shared states, identities, timelines...), deal with their appropriate disitribution and routing, and deliver these service units as requested by the user application functions. The concept of service unit becomes essential here, as the cornerstone for fundamental network characteristics (addressing, routing, information structuring...) and for the interface to the applications using the network. As the discussion on how to identify and relate keys in a wide-area QKD network is still alive, the need to identify how to “pack” qubits in a way useful for, say, distributed computations or teleportation coding, how to route these packs, and how to request and consume services based on them is crucial to define how a global quantum network should be built and operated.¶
A Quantum Fabric Stratum, in charge of the direct application of quantum protocols and algorithms among the endpoints of a quantum link, whatever their number, providing support to bipartite and multipartite entanglement distribution. It is important to note that this stratum must be able to support the appropriate service units, but there is no need for a one-to-one mapping between those quantum entanglement units and the service units. As example, let us consider entanglement distribution via swapping, which would likely occur on a pairwise basis at this stratum, but needs to be considered in a collective view to make sense to the applications interacting with the service stratum.¶
A Connectivity Stratum, taking care of providing the paths to support the quantum links used by the quantum fabric and service strata. Typically, the connectivity stratum would be supported by OTN infrastructure, via fiber and/or open-space links, and would follow a common connectivity paradigm, specifically a circuit-based or packet-based one. While current quantum links deal with OTN infrastructure according to a circuit-based paradigm, recent proposals are addressing the idea of "quantum packets" [PSQN22] and the connectivity stratum would have to deal, in general terms, with the classical headers of such packets. Furthermore, classical links are always required for supporting quantum links procedures, and by any kind of monitoring, control, and management connections. The provisioning of related quantum and classical links, and their consistent operation to meet service levels will be the main concern of this stratum.¶
This architecture, following the CLAS proposal itself, is built under the assumption that planes within and across strata communicate through well-defined, open interfaces supporting programmability, as a generalization of the common SDN architecture that defines a controller as a mediator between application and network (forwarding) devices. It includes the archetypal case of a centralized controller but is not limited to that particular realization. These broader implications of SDN principles are among the main motivation of the original CLAS proposal in [CLASEVO], and it is the main reason for using it as the base for the framework proposed by this document. The archetypal case of a centralized controller would be the most common deployment style, but the architecture is able to support more distributed approaches, in which each participating domain runs a specific instance of the different strata, providing collaboration by the exposure of tailored information to the other domains via border protocols, as proposed in [ALTOQ24], in a way equivalent to the peering mechanisms in use among current Internet Autonomous Systems. Even configurations where a particular domain focuses on one or two of the strata, supporting the other strata being hosted in different domains is also conceivable.¶
Based on the images used to illustrate the strata proposed in [CLASEVO] and [RFC8597], the relationship among the strata described above would be as shown in the following diagram:¶
Application Functions
/\
||
+-------------------------------------||-------------+
| Service Stratum || |
| \/ |
| +--------------+ ........................... |
| | Telemetry Pl.| . SDN Intelligence . |
| | |<===>. . |
| +-----/\-------+ . +--------------+ . |
| || . | Mgmt. Pl. | . |
| || . +--------------+ | . |
| +-----\/-------+ . | Control Pl. |-----+ . |
| | Resource Pl. | . | | . |
| | |<===>. +--------------+ . |
| +--------------+ ........................... |
| /\ /\ |
| || || |
+--------------------------------||-------------||---+
Standard API -- || -- ||
+--------------------------------||-----+ ||
| Quantum Fabric Stratum || | ||
| \/ | ||
| +----------+ ................... | ||
| | Telemetry| . SDN . | Std. ||
| | Plane |<==>. Intelligence . | API ||
| +-----/\---+ . +----------+ . | -- || --
| || . | Mgmt. Pl.| . | ||
| || . +----------+ | . | ||
| +-----\/---+ . | Control |-+ . | ||
| | Resource | . | Plane | . | ||
| | Plane |<==>. +----------+ . | ||
| +----------+ ................... | ||
+----------------------------------/\---+ ||
Standard API -- || -- ||
+-------------------||-----------||-----+
| Connectivity || || |
| Stratum || || |
| \/ \/ |
| +----------+ ................... |
| | Telemetry| . SDN . |
| | Plane |<==>. Intelligence . |
| +-----/\---+ . +----------+ . |
| || . | Mgmt. Pl.| . |
| || . +----------+ | . |
| +-----\/---+ . | Control |-+ . |
| | Resource | . | Plane | . |
| | Plane |<==>. +----------+ . |
| +----------+ ................... |
+---------------------------------------+
¶
Essentially, this architecture model incorporates the findings from QKD deployments and addresses the requirements for providing a general framework for quantum networks towards the Quantum Internet. It is intended to support the evolution of network base technologies, provide the degrees of freedom necessary to encompass different deployment models, and align with relevant trends in network operation, while considering the practical aspects related to classical connectivity.¶
The proposed architecture will address the evolution of network base technologies by providing abstractions able to accommodate to this evolution. Considering the stages analyzed in [QIROAD18], the QKD deployment patterns described in the previous section already cover "Trusted Repeater Networks" and "Prepare and Measure Networks", and the general architecture proposed here is able to accommodate the more evolved stages, namely "Entanglement Distribution Networks", "Quantum Memory Networks", "Few Qubit Fault-Tolerant Networks", and "Quantum Computing Networks". As immediate examples we can consider the integration of features in the Connectivity Stratum with the other two strata to support entanglement distribution among different locations, or the incorporation of future quantum repeaters into the Quantum Fabric Stratum to support more elaborated behaviors of the Service Stratum.¶
In addition, these network abstractions are intended to provide specific degrees of freedom for network design and deployment, through the incorporation of independent resource and control planes at each stratum. Given the control mechanisms identified as "SDN intelligence" on the diagram above are able to expose open interfaces, the approach for coordinating the different strata via mechanisms like those defined in [ETSI18] is totally feasible, and different aggregation patterns (multi-stratum, multi-domain...) and models (federated, hierarchical...) can be applied. These aggregation mechanisms are equally applicable in the case of telemetry data and their integration with closed-loop mechanisms for automation, in support of the required quantum network agility.¶
The evolved CLAS proposal in [CLASEVO] explicitly incorporates current trends in network automation, in whatever the flavor including AI and intent expressions. This architecture guarantees the future pliability of quantum networks, in alignment with the evolution of best practices in general network management.¶
Finally, by explicitly addressing the issues related to the connectivity of quantum links, the architecture considers the interactions with any other relevant operational aspects required for providing quantum network services. The direct integration of a stratum focused on these aspects makes the proposed architecture better aligned with the sustainability goal.¶
The service units provided by a QKD network have to be uniquely identified within the network, so they can be properly managed by the SOP, including their routing across the different required KMEs, the requests of appropriate links in the QFP, and the management of the lifecycle events related to making the key available to the applications willing to use it. It is important to note we are talking about a service unit, and not a data unit associated with a particular protocol, and therefore what is relevant here are the identification of the two application endpoints (that should include a nonce mechanism to identify the specific pairing) together with relevant parameters regarding the key lifecycle, such as its length and valid time-to-live. While these are the two essential lifecycle parameters, others, as it might be the case of applicable crypto algorithms, could be considered as well. The service unit identifier is not directional, i.e., it has no source or destination addresses, as it defines a shared state to be used by two applications. We can consider the analogy of transport flows in the current Internet, rather than packets.¶
The current proposal we are experimenting with advocate for using URNs [RFC8141] as endpoint identifiers, taking advantage of their nature of location-independent, persistent resource identifiers. The q-component of the endpoint URN can be used to carry the nonce part of the specific application identifier. If we consider that lifecycle parameters can be expressed using a specific URN in its q-component, we have that a service unit identifier consists of the combination of three URNs.¶
As an example, let’s consider URNs for application endpoints use the qkd namespace id, and that lifecycle parameters use the URN qkd:lifecycle assigned name, with the parameters size and valid-until. A service unit identifier for QKD between two domains, with roots madqci and quditto, would look like:¶
urn:qkd:madqci:ccips?=nonce=177923 urn:qkd:quditto:emulator:ipsec:controller?=nid=af33017 urn:qkd:lifecycle?=size=256&valid-until=1750708945¶
The nature of the endpoint identifiers support the use of any aggregation and routing mechanisms, ranging from strictly hierarchical and centralized schemas based on orchestration mechanisms to fully distributed routing algorithms. The approach also supports the use of non-routable identifiers, limited to that a given domain or KMS.¶
The QKD service unit identifies a shared state between two application entities, and therefore cannot be consider directional, and the concepts of source and destination do not apply here. Nevertheless, directionality is relevant in the process of establishing the QKD service unit, both in terms of its identifier and of its contents. In the case of the identifier, one of the application entities will request a service unit to the relevant KMS/KME it is attached to, identifying itself and the other peer in the service unit, together with the applicable lifecycle parameters. Relying on the available route information and the replies of the intermediate elements in the SOP, the final identifier of the QKD service unit will be built. The associated content, i.e., the bit string defining the key to be shared between the two application endpoints, will be derived from the elements in the participating links in the QFP and the application of any additional mechanisms (key encryption, augmentation, trusted node forwarding…) required by the participating KMEs and the corresponding links.¶
The fact we remarked above about the QKD service unit being a shared state between two application entities supports a direct translation of the concept to apply it in a generalized quantum network. A service unit in this context will correspond to the shared quantum states to be consume by the application entities, according to the goals of their sharing of these quantum states. This implies that a QKD service unit can be considered a specialized quantum service unit, where the shared state has been somehow pre-processed to distill the bits that define the shared key. A similar pattern could be applicable to other specialized quantum network applications, as it would be the case of distributed quantum sensing or metrology.¶
The identification of such service units can follow the same patterns described for the QKD service units, but in this general case with N+1 URNs, being N the number of application entities (two for the case of bipartite entanglement) sharing the state, and a final one defining the lifecycle parameters. Obviously, these parameters should differ from the ones postulated for QKD, and it is possible to envisage parameters such as shared state size (the number of entangled states), a timestamp regarding lifetime of the shared state, and others addressing aspects like fidelity. As the quantum memory technology at the foundation of these shared states evolve, a clearer view of the parameter URN will become available. Experiments on this issue will be really useful to identify these parameters and shape the q-component of the parameter URN.¶
The content of a QKD service unit is a bitstring corresponding to the shared key. This bitstring is stored in the memories of the corresponding KMEs, with individual bits differentiated by their position in the string. Quantum memories must be available at the resource plane of the Service Stratum (SS), and the service unit should contain the addresses used by those quantum memories to identify the corresponding entangled states. The elements equivalent to the KMEs in the control plane of the SS interact with these quantum memories to identify the applicable addresses, and to require the elements in the control plane of the Quantum Fabric Stratum (QFS) to activate the corresponding exchanges in the quantum links they operate. Each of the endpoints of these quantum links is expected to provide a functionality equivalent to the agents discussed for QKD networks, in support of the SS quantum memories.¶
For these service units, directionality (the specification of an origin and a destination) is not applicable, as service units correspond to a shared state. The only directional element that can be considered is an originator of this shared state, corresponding to the application element requesting the establishment of the service unit. This would trigger the SS control plane element attached to the application to start its route decision procedures and to start the interactions with the relevant SS control planes to start the necessary exchanges to establish the shared quantum states. The structure and delegation mechanisms provided by URNs allow for arbitrary aggregation of prefixes, enabling any kind of routing style, from the aggregation and inter-domain announcement similar (or compatible) to BGP in classical Internet to the decision on which prefixes are announced and how they are routed by means of SDN controllers, whether by means of a federation approach or in a hierarchical control structure. The approach also supports the use of non-routable identifiers that cannot be announced outside a given domain and can only establish service pairing with other applications within the same domain. These mechanisms would be applied by the corresponding elements in the control and management planes of the Service Stratum.¶
As a result of the routing procedures and the interaction among SS control plane elements, there should be corresponding interactions with elements in the control planes of the Connectivity Strata (CS) and the QFS, to verify and require, as needed, the establishment of the individual entangled states and, as required, the physical links to support them. There is a consolidated corpus of interfaces (usually known as North-Bound Interfaces, NBI) for the control of classical connectivity, and specially of optical links, such as the TAPI specification [TAPI240], and different proposals to select and establish paths. It seems necessary to explore and experiment with similar interfaces and procedures for the management and control of quantum links, addressing the challenges already identified in [RFC9340] and exploring the implications of quantum-native routing proposals as made in [QUADDR] and, more recently, in [QNAD]. A specially significant question is the mapping between the entangled states, as identified by the service unit, and the payloads exchanged within the QFS.¶
Finally, a word on the telemetry planes in each of the proposed strata. It should be obvious the elements in the control planes at each of the strata should start monitoring mechanisms at the involved elements in the resource planes and activate telemetry collection mechanisms. This brings the requirement of defining and experimenting with appropriate metrics and telemetry data models for both the SS and the QFS, as already being defined for QKD infrastructures [ETSI23].¶
Service unit identifiers are intended to be stable and meaningful to applications and SS functions, typically by combining endpoint identifiers and lifecycle parameters. However, the internal handles used to access quantum memories, communication qubits, entangled pairs, or other device-local quantum resources are often local to a device, technology, implementation, or administrative domain. Exposing such device-local handles outside their local scope can unnecessarily reveal resource structure and can complicate reallocation, recovery, and inter-domain operation.¶
A useful indirection mechanism is a domain-scoped Quantum Unit Identifier (QUI). Following this approach, the application-facing service unit identifier corresponds to one or more domain-scoped QUIs, and each QUI may be mapped inside its domain to the corresponding device-local quantum resource handles. A QUI is not expected to be globally unique. Its scope can be an administrative domain, a technology segment, a trust domain, a controller domain, or another operational scope appropriate to the deployment.¶
A QUI may represent a single entangled pair, a set of entangled pairs, a quantum memory allocation, a local share of an end-to-end shared state, or another quantum resource unit relevant to the service. The same end-to-end service unit may therefore be associated with different QUIs in different domains, while preserving the service-unit abstraction presented to applications.¶
Because quantum resources are time-sensitive, a QUI may naturally be associated with lifecycle information. Such information may include a time-to-live, a coherence window, an expiry time, an age value, or an availability window. The relevant lifecycle properties are exposed through the interface betweehn the SS and QFS, so it is possible to decide whether a resource remains usable, whether it has to be consumed immediately, or whether it has to be replaced to fulfill a given service unit denotation.¶
A QUI may also include, or be associated with, freshness information such as a nonce or other one-time value. Freshness information is useful to distinguish different allocations, avoid accidental reuse of stale state, and reduce replay or mix-up risks when several service units or resource allocations are active at the same time.¶
The use of a QUI may also enable re-binding. For example, when a particular entangled pair decoheres, a quantum memory allocation fails, a link-level establishment attempt does not reach the target fidelity, or an implementation decides to regenerate the underlying state, the domain can bind the same service-unit context to a new local quantum resource allocation. Such re-binding may not imply preservation of a consumed or measured quantum state; it is a control-plane mechanism for replacing or refreshing the underlying resource associated with the service unit.¶
Resolution among service unit identifiers and QUIs happens at the interface between the SS and QFS control planes, while the mapping of QUIs to the applicable device-local resource handles would be typically performed by QFS resource-plane agents, managed by the QFS control plane, though particular architectures may define specific control and management functions for this purpose. The mapping between a QUI and device-local handles is expected to remain local to the relevant scope unless explicitly exposed through an inter-domain or management interface.¶
Admission, routing, resource reservation, and maintenance of entanglement-based service units require parameters that describe the requested and achieved quality of the quantum resource. These parameters will be carried in service requests, used internally by SS and QFS control functions, and exposed through telemetry. They apply at different granularities, including a physical quantum link, a link-level entanglement, a segment, a domain, or an end-to-end service unit. Quantum QoS parameters to be considered include:¶
Target fidelity: the desired minimum quality of the shared state, either end-to-end or per segment.¶
Achieved or estimated fidelity: the observed or predicted quality of an established state, including the effects of link loss, local operations, swapping, purification, and storage time.¶
Entanglement generation rate: the expected, requested, or observed rate at which usable entangled pairs can be generated.¶
End-to-end success probability: the probability that the requested shared state can be established with the requested parameters, optionally expressed per link, per segment, or for the complete service unit.¶
Establishment latency: the time required to create a usable service unit, including link-level entanglement generation, heralding, swapping, purification, resource reservation, and relevant control interactions.¶
Quantum communication latency: the latency relevant to the quantum application, including any classical-assist signaling required for measurement outcomes, timing, feed-forward operations, or completion of teleportation-based procedures.¶
Age, time-to-live, or coherence window: the time for which a shared state or resource allocation is expected to remain usable.¶
Swapping depth cap: the maximum number of entanglement-swapping operations, or the maximum repeater depth, acceptable for the requested service unit.¶
Quantum memory constraints: the amount, type, and availability of memory qubits and communication qubits at the endpoints and intermediate nodes.¶
Purification support and cost: whether purification is available, which purification schemes or cycles are supported, and their effect on fidelity, rate, latency, and resource consumption.¶
Classical-assist constraints: latency, reliability, timing, and synchronization properties of the classical channels used for heralding, measurement-outcome exchange, calibration, and feed-forward control.¶
Loss and error indicators: parameters describing photon loss, failed entanglement attempts, decoherence events, operation errors, or classical packet loss affecting the quantum procedure.¶
Application or service constraints: policy or application-level constraints such as availability windows, allowed technologies (for example fiber or free-space links), supported service types, or restrictions on which domains or node capabilities can be used.¶
These parameters provide the basis for evaluating the suitability of a candidate path, deciding whether a service unit request can be fulfilled, selecting among alternative paths, deciding whether purification is needed, and triggering refresh, re-establishment, or re-binding when the observed quality no longer satisfies the service objective.¶
Many quantum-network procedures require a classical ancillary function associated with a quantum node or quantum resource. This function can be realized in the same physical node as the quantum resource, in an attached classical controller or agent, or in a logically separate control-plane element. Its role is not to carry quantum information, but to support the control and consumption of quantum resources.¶
Examples of these ancillary functions include translating service-unit identifiers to QUIs, and these into local resource handles, forwarding service requests to local quantum resources, exchanging measurement outcomes, coordinating heralding and entanglement swapping, distributing timing and calibration information, performing authentication and authorization checks, and applying feed-forward information such as correction data required by teleportation-based procedures.¶
The use of such functions requires clear interfaces among the different strata, applying classical control and timing paths as part of the quality and security envelope of an entanglement-based service unit.¶
Let us outline an example procedure for establishing an entanglement-based service unit between two quantum-capable endpoints. The procedure is informative and does not define a protocol or prescribe a particular control architecture. Different realizations can map the functions described below to SS, QFS, and CS control-plane entities in different ways.¶
0. Capability and Service Discovery¶
A requesting application or service consumer obtains information that quantum services or quantum-enhanced services are available. This information can be obtained through configuration, service discovery, registration, policy distribution, or another discovery mechanism. The discovered information can include service identifiers, endpoint identifiers, supported quantum QoS parameter ranges, availability windows, technology constraints, supported node capabilities, and any policy constraints relevant to service establishment.¶
1. Service Request¶
The requesting application or service consumer requests a service unit from an SS function. The request can include the requested service type, peer endpoint identifier or identifiers, lifecycle parameters such as size or time-to-live, and quantum QoS objectives such as target fidelity, minimum generation rate, success probability, establishment latency, or classical-assist latency. The SS function performs the applicable admission, authentication, authorization, and policy checks.¶
2. Candidate Path and Resource Evaluation¶
By request of the SS, QFS control functions evaluate candidate quantum paths between the relevant endpoints. The evaluation can consider available nodes, quantum memory constraints, communication-qubit availability, link-level entanglement generation rates, expected fidelity, purification capabilities, swapping depth, classical-assist latency, and policy constraints. Where physical or optical connectivity has to be established or reserved, the relevant CS functions are engaged to provide the required paths and classical assist channels.¶
3. Hop-by-Hop Resource Allocation¶
For each selected hop or segment, the relevant QFS control function requests allocation of the quantum resources needed to support the service unit. The allocation can be associated with a domain-scoped QUI. If a hop or segment cannot provide the requested resources or cannot satisfy the requested quality parameters, the control logic can attempt an alternative path, reduce or renegotiate objectives according to policy, or fail the establishment attempt and release previously allocated resources.¶
4. Entanglement Generation and Multi-Hop Operations¶
Once the required hop-level resources are available, the QFS coordinates entanglement generation on the relevant links. For multi-hop service units, intermediate nodes can perform entanglement swapping and, where supported and useful, purification. Classical ancillary functions carry the required heralding information, measurement outcomes, timing information, and feed-forward data. The resulting fidelity, success probability, age, and other relevant quantum QoS parameters are recorded or exposed to the responsible control functions.¶
5. Service-Unit Binding and Delivery¶
If the established shared state satisfies the requested objectives, the SS binds the resulting resource to the service unit identifier expected by the application. The application receives the information needed to consume the service unit, while domain-local mappings from service-unit identifiers to QUIs and from QUIs to device-local resource handles remain within the appropriate administrative scope.¶
6. Maintenance, Re-Establishment, and On-Demand Activation¶
Because coherence windows can be short and quality can degrade over time, telemetry can trigger refresh, re-establishment, or re-binding when a time-to-live is close to expiry, fidelity drops below the requested level, intermediate resources fail, or policy conditions change. Some deployments can also separate authorization and reservation from actual entanglement creation. In such cases, the service request establishes the right to consume a quantum service, while the shared state is generated later, when the application is ready to use it.¶
The architecture proposed in this document is intended as a framework to evaluate and explore compatibility among the different proposals on protocols and interfaces for the future availability of quantum features in the global Internet, with the goal of providing a uniform reference model to choose and apply the most appropriate solutions to the Quantum Internet challenges. While the reference architecture does not intend to identify a concrete set of these protocols and interfaces, it is useful to analyze current proposals and trends, and provide some guidance on how the framework can be useful for assessing the integration of the solutions applicable to the different elements that have to converge to realize the Quantum Internet.¶
There is a significant corpus of standards and operational practica applicable for the Connectivity Stratum, sustained by a well established experience in the management and use of optical and, to some extent, satellite-based networks. The differentiation of the planes considered in the CLAS architecture within the Connectivity Stratum has been common practice in the deployment and operation of IP converged services over optical networks. The abstractions and topology views described in the ACTN framework defined in [RFC8453] constitute a solid foundation to describe the functionality of the planes within the Connectivity Stratum, and the interfaces to be used in the interactions with the other strata. An element like the Path Computation Element (PCE) described in [RFC8637], able to address the considerations related to quantum connectivity and the implications of entanglement-based distribution, could constitute the core of the intelligence and telemetry planes. Specific distribution elements, able to fulfill the conditions for quantum signals, including the potential co-propagation with classical signals, and to interface with future quantum repeaters [QREPS], would constitute the essential substrate of the resource plane. The current trends in optical disaggregation and the use of orchestrated SDN mechanisms for network path management and monitoring provide a natural path for leveraging network virtualization mechanisms within the Connectivity Stratum, facilitating their integration.¶
In what relates to the Quantum Fabric Stratum, current best practices indicate that telemetry and SDN intelligence planes will follow the same directions as the other strata, with virtualized, likely cloud-native implementations for them. Even in the case of the resource plane, one can expect the availability of specific software agent elements in charge of managing devices, interacting with the Connectivity Plane and providing support to the service units relevant for the Service Stratum. The proposal in [QUADDR], beyond the foundations described in [RFC9340], can be used to exemplify the main objective of the framework architecture described in this document. The proposal presents quantum-native mechanisms for routing procedures, and the corresponding addressing conventions supporting them, and considers network-wide mechanisms, structured in two tiers defining what could be assimilated to a local domain and an internetworking domain. This proposal can be naturally integrated in the Quantum Fabric Stratum (QFS), and its SDN-inspired architecture would map the proposed Entanglement-Defined Controller (EDC) at the kernel of the SDN intelligence plane. The integration of an architecture like this within the framework described in this document would require to analyze the mapping between the node identifiers described in the paper and the service units discussed below. The choices for the coordination among the different strata if the QFS uses an architecture like the one proposed in the references paper would need to be also analyzed: on the one hand, the interface between the EDC and Service Stratum should be defined, and the QFS elements should need to be extended to include its interactions with the Connectivity Stratum, or consider it oblivious to physical connectivity and leave the coordination to the Service Stratum. This is the kind of evaluations the synthetic environments discussed in Section 6.2 will be extremely useful.¶
The discussion on the foundations of the Service Stratum (SS) is made on the previous section, which introduces and analyzes the concept of service units. Furthermore, As a natural consequence of what is discussed above in the framework of cloud-native infrastructures, the use of network virtualization techniques would be essential for the Service Stratum, at all of their planes:¶
The SDN intelligence plane, allowing the dynamic management of service units and their association with the corresponding units in the Quantum Fabric Stratum.¶
The telemetry plane, for dynamic monitoring and data aggregation.¶
The resource plane, in support of the different nature of the interactions at the Quantum Fabric Stratum, like the case of entanglement persistence beyond direct physical reachability.¶
To demonstrate the application of the framework proposed here, and to provide guidance in the future assessment of new proposals, this section discusses the mapping of a number of representative current proposals, addressing different issues in quantum networking and covering a number of relevant architecture solutions or protocol approaches to the general problem of the Quantum Internet. This mapping is also intended to clarify the main concepts (strata, planes, service units) underpinning the framework, considering how these concepts are applied in the context of already available, and in most cases well-known, approaches. Finally, the mapping also aims at supporting future experimental validation of the applicability of the different proposals and their potential interplay to support Quantum Internet infrastructure and services, in most cases to be performed by means of the synthetic environments discussed in the next section.¶
The discussion of the mapped proposals is structured according to a set of general categories and their connection to the reference framework. Within each category, proposals are ordered according to their publication date. An analysis of how each one of them fits in the reference framework, together with a few considerations on their interplay within the framework and possible experimentation paths are provided.¶
The papers in this category establish the physical mechanisms upon which quantum networking at scale depends, mainly quantum repeaters in their various forms, and analyze their architectural and operational implications. They are mainly related to the design of the resource plane of the QFS and the interface requirements for the CS.¶
[BRIEGEL98] introduces the base concept of quantum repeater, addressing the exponential growth of error probability with the length of the channel in direct quantum transmissions by means of a nested purification protocol over intermediate nodes. Quantum repeaters are essential elements in the reference framework, and in particular for the resource plane of the QFS. They are the foundation of the nodes that perform entanglement generation, swapping, and error correction operations that produce the shared entangled states consumed by the SS. The design of the QFS and its interface to the CS must accommodate the characteristics of repeater nodes.¶
This work also highlights an architectural implication discussed when introducing the service unit concept. The elementary entanglement events occurring within the QFS, such as the generation and exchange of entangled pairs at the individual links, do not correspond one-to-one with the units the applications expect to consume from the quantum connection. A service unit, as provided by the SS, represents a multi-hop end-to-end entangled state, whose construction may have involved a complex sequence of operations at the QFS level, typically spanning multiple repeater nodes and requiring classical coordination via the CS. This gap between elementary link-level entanglement events and the application-visible service unit is one of the motivations for the domain-scoped QUI indirection introduced in this document: the QUI allows the multi-hop, multi-operation construction internal to the QFS to be represented and re-bound independently of the stable service-unit identifier the application consumes.¶
[JIANG09] proposes a quantum repeater protocol that locally encodes qubits with CCS code and applies classical error correction during simultaneous entanglement connections. The scheme achieves substantially higher communication rates over long distances and relaxes the requirements on quantum memory fidelity. In the context of the multiplane architecture, this work exemplifies the class of implementations that the QFS resource plane must support. The encoding, decoding, and error correction operations are internal to the QFS and transparent to the SS, but they may place specific requirements on the classical channel capacity and latency that the CS must provide.¶
Another interesting aspect relates to the service unit lifecycle definition. Depending on the protocol implemented by the repeaters (for example, the one presented in this work versus a purify-and-swap scheme), the rate and fidelity of the end-to-end logical entangled pairs differ. The SS control plane needs to be able to represent and negotiate these QoS components when establishing service units, and the interface between the SS and the QFS must expose them in a technology-agnostic manner. The encoding scheme, logical error rate, and generation rate could be candidates for inclusion in the lifecycle parameter component of a service unit URN. The encoding scheme, logical error rate, and generation rate correspond directly to quantum QoS parameters, and the resulting per-link or per-segment characteristics can be naturally associated with the domain-scoped QUI representing the allocation on that segment rather than encoded directly into the application-facing service-unit identifier.¶
[MURALI16] presents a classification of quantum repeaters into three generations and analyses their performance in terms of communication rate and physical resources required. First-generation repeaters require two-way classical communication and quantum memories, but no quantum error correction. They reduce the exponential overhead in direct state transfer to only polynomial overhead, limited by the two-way classical signaling required between non-adjacent repeater stations. The second generation adds quantum error correction, which implies more complex hardware, but only adjacent repeater stations require two-way classical signaling. Finally, the third generation eliminates the need for two-way classical signaling by relying solely on quantum error correction. It only needs one-way signaling and thus can achieve a very high communication rate, just like the classical repeaters, only limited by local operation delay. Thus, each generation would place different demands on the classical channel model that the CS must support, and embodies a different capability level for the QFS.¶
This classification provides a roadmap for the potential evolution of the QFS as quantum hardware matures. The same service unit abstraction living in the SS should remain valid across all generations, with the QFS-CS interface evolving to accommodate the changing classical channel requirements as technology advances.¶
[QREPS] presents a comprehensive review of the conceptual frameworks, architectures, and experimental progress of quantum repeaters. The analysis contextualises the proposals and advancements on the broader goal of a Quantum Internet. This work includes a substantial portion of the technology space that the QFS must accommodate. It maps the diversity of repeater designs, their hardware requirements, and their operational constraints. This type of approach is key to defining which abstractions the QFS should expose to remain independent of the specific physical implementation used at any given stage of network evolution.¶
The review also notes that several near-term repeater architectures rely heavily on classical co-processing and on specific timing and synchronisation constraints that must be jointly provisioned with the quantum channel. This coordination role is one of the primary responsibilities for which the CS is designed. Furthermore, the discussion on the experimental state of the art in quantum memories, entanglement generation rate, and fidelity provide a physical grounding for the lifecycle parameters that service units in the SS must be able to express. Memory lifetime set the upper bound on the valid-until parameter of a service unit, generation rate constrains the throughput of the QFS, and achievable fidelity defines the quality floor below which a service unit cannot meaningfully be delivered. Memory lifetime sets the upper bound on the time-to-live or coherence-window information that can be associated with a QUI, entanglement generation rate constrains the throughput of the QFS, and achievable fidelity defines the quality floor below which the underlying QUI-bound resource can no longer satisfy the service unit's requested objectives.¶
The proposals in this category deal with architectural foundations and concrete protocols for quantum networking, covering the design of repeater network architectures, link-layer protocol engineering, and the application of classical architectural principles, such as recursion and end-to-end argument, to quantum networks. They are applicable to the QFS control and management planes and for the inter-stratum interface design.¶
[DAHLBERG19] presents a functional allocation of a quantum network stack with concrete physical and link layer protocols, transforming the isolated physical experiments that produce heralded entanglement into a well-defined, robust service. Their link-layer protocol manages the stochastic nature of entanglement generation, handles issues like timeouts, and provides a stable interface to higher layers that abstracts the deatil of the physical mechanism underlying the process. This timeout-and-retry behavior is a concrete instance of the kind of event that, in the framework's terms, can trigger QUI re-binding: a failed or expired link-level attempt is replaced by a new allocation without changing the service-unit context exposed to the application.¶
In the multiplane architecture proposed in this document, this work falls in the QFS and its interface with the CS. The link-layer protocol operates on the quantum links and exposes upward-facing events that the control plane of the QFS may consume to manage network-wide entanglement distribution.¶
This work also makes explicit he dependence of the link layer on classical communication, for heralding mechanisms, timing and post-selection processes. Thereby supporting the requirement for coordinated classical connectivity that the CS has to satisfy. The functional decomposition proposed in the paper is compatible with the QFS structure described in this document, and their protocol can be understood as an example of an operation within the resource plane of the QFS, managed by the control plane through well-defined events and triggers.¶
The proposals in this category address how the quantum resources produced by the QFS are abstracted into units that applications and higher-level computations can consume, either through concrete algorithmic techniques or through system-level layering. They are relevant primarily to the definition of the service unit and to the boundary between the SS and the lower strata.¶
[GOTTESMAN99] shows theoretically that single-qubit operations, Bell-basis measurements and a set of certain pre-shared entangled resource states, such as GHZ states, are together sufficient to construct a universal quantum computer, unifying several fault-tolerant protocols under a single teleportation-based technique. The entangled resource state consumed by this technique corresponds to the shared quantum state delivered by the SS as a service unit: the paper treats the state as an input to a local computation, decoupled from how it was generated, which is consistent with the separation between the SS, which delivers the service unit, and the QFS, which generates and maintains the underlying entangled state through entanglement generation and, where required, swapping and purification.¶
The proposed teleportation-based technique depends on classical communication of the measurement outcome to complete the operation at the receiving side. This places it within the scope of the classical constraints and quantum communication latency parameters that the CS has to support.¶
[CUOMO20] elaborates a layered abstraction of a distributed quantum computing ecosystem, structured from the underlying communication infrastructure connecting remote quantum devices up through successive logical layers to the functionality consumed by distributed applications. The lower layers described in the paper, covering the physical exchange of quantum information between devices, correspond to the QFS and CS. The upper layers, covering the abstractions exposed to distributed applications, correspond to the SS.¶
The boundary drawn between the communication infrastructure and the abstractions exposed to applications matches the separation maintained by the service unit: applications interact with the shared state delivered by the SS without visibility into the sequence of QFS operations, spanning individual links and, where applicable, repeater nodes, that produced it.¶
Works in this category address potential attack surfaces and security-relevant properties of quantum networking, related to the mechanims applicable to secure strata, planes and their interfaces, as dicussed in Section 8.¶
[SATOH20] models the internal components and structure of a quantum repeater network node and classifies attacks against them in terms of confidentiality, integrity, and availability, finding that while confidentiality is generally preserved by the physical properties of quantum states, integrity and availability introduce vulnerabilities with no classical counterpart.¶
The report also analyzes how classical computing and networking elements attached to a quantum node materially affect the system's overall security risk. Attacks on the classical control, timing, or heralding information exchanged between nodes can propagate into integrity or availability failures even when the quantum channel itself is not directly compromised. This is consistent with the elaboration Section 8 makes on the interaction of physical attacks with classical attacks on control and monitoring activities.¶
Due to the early stage of many, if not all, quantum technologies, experimenting with quantum devices and equipment can be seriously hindered by high costs and limited availability. This challenge is particularly evident for experimentation at the scale required to validate network protocols and inter- and intra-strata interfaces. In this context, synthetic environments, and synthetic testbeds enabled by these environments, become an essential tool. They enable the emulation of quantum network deployments in a fully controlled setting, allowing the execution of experiments and trials, protocol evaluations, and even security analyses, where potential network attacks can be tested without compromising the integrity of an already built quantum network or a significant number of physical devices.¶
Based on the results introduced in [QKNDT24] for QKD networks, the concept of a Quantum Network Digital Twin (QNDT) provides a foundation for such environments. QNDTs will enable a better understanding of the properties of the different network elements, interfaces, and protocols, and the applicability of the architecture proposed in this document. It is important to note that a QNDT is not a simulation tool, even though some of its components may apply simulation functionality to adapt their behavior to that of a quantum element. Rather, a QNDT represents a distributed classical system that mirrors the operational behavior of a quantum network, responding in real time and accurately reproducing the dynamics and interactions of quantum entities.¶
In the case of QKD network deployments, significant progress has been achieved thanks to both practical deployments, as exemplified in [EUROQCI] and the early coordinated efforts of standardization bodies. These advances include the definition of standardized APIs that specify the communication means between quantum nodes and customer applications, like [ETSI04], and the integration of network management mechanisms widely adopted in classical communication systems, like the SDN approach defined in [ETSI15]. This coordinated efforts have translated into more flexible, programmable, and scalable control of quantum resources, facilitating seamless interoperability between quantum and classical infrastructures. Despite these advances, several aspects of QKD networking remain under active development. These include the definition of interfaces that ensure interoperability across different administrative domains, as well as the design and validation of architectures capable of supporting large-scale deployments, that is, networks comprising hundreds of interconnected nodes. In this regard, platforms such as the one described in [QUDITTO] offer a valuable opportunity, as they enable the emulation of low-level quantum network behaviors using classical computational resources. Such synthetic environments provide the means to model and analyze complex network scenarios that are currently unattainable in fully physical experimental testbeds.¶
When considering general-purpose quantum networks, particularly those based on entanglement distribution and management, the role of synthetic environments becomes even more significant. Unlike QKD networks, whose architectural and operational principles are relatively well understood, entanglement-based networks are still in an early stage of development. Many fundamental networking aspects, such as entanglement routing, resource scheduling, and inter-layer coordination, remain open research questions, with a crucial lack of practical validation. In this context, QNDTs offer a unique opportunity to accelerate progress: by enabling controlled emulation of quantum states, interactions, and network behaviors, they allow to test novel architectures, evaluate protocol performance, and explore scalability under realistic yet fully reproducible conditions.¶
However, the development of a general-purpose QNDT introduces its own set of challenges. Such a system must not only emulate the functional behavior of quantum components but also ensure that the underlying classical infrastructure responds within the same temporal and operational constraints as its quantum counterpart, thereby enabling accurate validation of protocols and network strategies. Moreover, unlike QKD networks where standardized interfaces and APIs have already been established (or are at least emerging), no equivalent standards currently exist for general quantum networks. Consequently, a QNDT must be designed to be inherently flexible and extensible, capable of accommodating evolving definitions of interfaces, communication protocols, and architectural abstractions. In this regard, the QNDT once again becomes a key enabler for the development, integration, and testing of these foundational elements.¶
Building upon the above discussion, two primary challenges must be addressed as prerequisites for constructing a fully functional QNDT. First, it is necessary to develop a mechanism capable of handling the quantum-specific aspects of the system, executing simulations and distributing results across nodes, resulting in the emulation of the quantum behavior of network elements within the underlying classical infrastructure. Second, there must be a definition of a minimal set of core primitives or instructions that serves as the foundation for constructing more advanced mechanisms, such as standardized interfaces and communication methods between network elements and external systems. Together, these two pillars will establish the groundwork for a QNDT framework capable of evolving in parallel with the broader quantum networking ecosystem.¶
The core quantum emulation mechanism for such an environment, according to the current state of the art, would be the QNDT emulation engine, based on a centralized simulation component designed to execute the simulations needed to emulate the quantum behavior of all network elements. This engine may rely on quantum network simulators such as [NetSquid], [SeQUeNCe], or [QuNetSim]. However, these platforms alone do not fulfill the requirements of a QNDT, since, as discussed above, a QNDT is not a simulation of the network but a distributed classical system that replicates the behavior of a real quantum network. Therefore, the central simulation element must be complemented by a result distribution mechanism, for example, through a publish/subscribe (Pub/Sub) protocol. In such a setup, network elements subscribe to topics relevant to their operation and can communicate with the central simulation tool both to request simulations and receive results through asynchronous interactions.¶
Another essential aspect concerns the handling of temporal consistency between the “simulation time”, i.e., the time required to execute a simulation, and the “simulated time,” i.e., the time the simulation calculates the real system would take to perform the same operation. Since simulation time is generally shorter than simulated time, the QNDT must incorporate logic ensuring that results are delivered only after the appropriate simulated delay has elapsed. This guarantees that the QNDT responds within the same temporal boundaries as its physical counterpart, thereby preserving the fidelity and realism of the emulated network behavior.¶
In addition, to maintain state realism within the QNDT, it is crucial to take into account the natural decoherence and noise dynamics of quantum states over time. For instance, when entangled states are distributed among the participating nodes and stored for a period before being used in subsequent operations, the QNDT must emulate the gradual evolution and degradation of these states. This entails tracking the elapsed time between state creation and use, and updating the state accordingly before executing the next instruction.¶
The general considerations made in [RFC8597] apply, as well as an elaboration on the following points regarding:¶
The requirements on mutual authentication in the channels used for quantum interactions, as they should require methods rooted at physical properties.¶
Specific physical attacks related to the particular quantum mechanisms in use by the quantum fabric stratum.¶
The interaction of these physical attacks with classical attacks to the control and monitoring activities, possibly translating into a threat surface augmentation.¶
The integrity and access control protection of service-unit indirection mechanisms, such as QUIs, to avoid attacks leading to resource exhaustion, state mix-up, unauthorized consumption, or incorrect association between applications and quantum resources.¶
The explicit freshness and lifetime information about QUI allocations and service-unit bindings, to address attacks related to replay, stale-state reuse, and state confusion risks during establishment, re-binding, and consumption of shared states.¶
The protection of classical ancillary functions associated with nodes, as any manipulation of these functions can impact security, triggering wrong correction operations, incorrect service-unit binding, or unauthorized use of quantum resources.¶
The trust issues in inter-domain exchanges, especially at the control and management planes.¶
Furthermore, as the identification of interfaces and protocols progresses other considerations will be required. In particular, the security considerations included in the documents referenced for the Connectivity Stratum, [RFC8453] and [RFC8637] apply to the proposed framework.¶
This document is based on work partially funded by the EU Horizon Europe project QSNP (grant 101114043), the Spanish UNICO project OPENSEC (grant TSI-063000-2021-60), and the MadridQuantum–CM project (funded by the EU, NextGenerationEU, grant PRTR-C17.I1, and by the Comunidad de Madrid, Programa de Acciones Complementarias).¶