Skip to main content

A Multiplane Architecture Proposal for the Quantum Internet
draft-lopez-qirg-qi-multiplane-arch-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Diego Lopez , Vicente Martin , Blanca Lopez , Luis M. Contreras
Last updated 2023-10-22
Replaced by draft-irtf-qirg-qi-multiplane-arch
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-lopez-qirg-qi-multiplane-arch-00
Quantum Internet Research Group                                 D. Lopez
Internet-Draft                                                Telefonica
Intended status: Informational                                 V. Martin
Expires: 24 April 2024                                               UPM
                                                                B. Lopez
                                                          IMDEA Networks
                                                         L. M. Contreras
                                                              Telefonica
                                                         22 October 2023

      A Multiplane Architecture Proposal for the Quantum Internet
                 draft-lopez-qirg-qi-multiplane-arch-00

Abstract

   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, based on the
   already extensive experience in the deployment of QKD network
   infrastructures and related initiatives on the integration of network
   infrastructures and services.

About This Document

   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-lopez-qirg-qi-
   multiplane-arch.html.  Status information for this document may be
   found at https://datatracker.ietf.org/doc/draft-lopez-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.

Lopez, et al.             Expires 24 April 2024                 [Page 1]
Internet-Draft             qi-multiplane-arch               October 2023

Status of This Memo

   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 24 April 2024.

Copyright Notice

   Copyright (c) 2023 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   3.  A QKD Multi-Plane Architecture  . . . . . . . . . . . . . . .   4
     3.1.  Interfacing with Classical Networks . . . . . . . . . . .   6
   4.  Introducing CLAS for Quantum Networks . . . . . . . . . . . .   7
     4.1.  CLAS Strata for Quantum Networks  . . . . . . . . . . . .   8
     4.2.  Identification of interfaces and protocols  . . . . . . .  10
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

Lopez, et al.             Expires 24 April 2024                 [Page 2]
Internet-Draft             qi-multiplane-arch               October 2023

1.  Introduction

   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.  Nevertheless, the growing interest
   on 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 [QUCS], 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 seem applicable to the general case of
   a Quantum Internet.  A corpus of architectural proposals [Y3802],
   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 proposes a multi-plane reference architecture for the
   Quantum Internet, derived from available proposals and the
   operational experience with QKD infrastructure.  The proposal

Lopez, et al.             Expires 24 April 2024                 [Page 3]
Internet-Draft             qi-multiplane-arch               October 2023

   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]:

   *  Universality, so a quantum network can accommodate any
      application.

   *  Transparency, so quantum networks can share physical media with
      classical networks.

   *  Scalability, so quantum networking protocols can support the
      growth of the network.

2.  Conventions and Definitions

   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.

3.  A QKD Multi-Plane Architecture

   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 open
   disaggregation strategies, and the identification of separate data
   and control planes, connected by means of open interfaces.

Lopez, et al.             Expires 24 April 2024                 [Page 4]
Internet-Draft             qi-multiplane-arch               October 2023

   Applying these principles, QKD infrastructures are 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 this
   interactions may incorporate a layered approach.

   The Quantum Forwarding Plane (QFP) is in charge of performing the
   operations (quantum and classical) to ensure the forwarding 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.

   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 conventional, with a
   clear mapping to and overlay data plane in classical network, though
   the SOP elements should be aware of the nature and specific needs of
   the QFP they interact with.

   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.

Lopez, et al.             Expires 24 April 2024                 [Page 5]
Internet-Draft             qi-multiplane-arch               October 2023

   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.

   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.

3.1.  Interfacing with Classical Networks

   The interface of QKD infrastructures with classical networks
   (commonly identified as OTN, Optical Transport Networks) has been
   based on three basic principles, related to the ones we mentioned
   above: facilitate the reuse of 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).  We can
   classify the interface mechanisms according to the level at which
   they occur.

   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.

Lopez, et al.             Expires 24 April 2024                 [Page 6]
Internet-Draft             qi-multiplane-arch               October 2023

   At the control and management level, 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, but 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.

   At the forwarding level, 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 OTN connectivity
   for the quantum algorithms.

4.  Introducing CLAS for Quantum Networks

   The Cooperating Layered Architecture for Software-Defined Networking
   (CLAS) [RFC8597] describes 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.).

   A new extension of the CLAS architecture [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.

Lopez, et al.             Expires 24 April 2024                 [Page 7]
Internet-Draft             qi-multiplane-arch               October 2023

   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 are
   talking of a general network architecture trying to incorporate
   general 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.

4.1.  CLAS Strata for Quantum Networks

   Following the CLAS philosophy, as proposed in its recent update
   [CLASEVO] of decoupling services, additional function, 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 feasible services
      are the generation of management of keys in QKD, and entanglement
      distribution in a general quantum network, but others can be
      considered, as time synchronization, identity assurance or
      sensing.  The service stratum would consider the relevant service
      units (keys, shared states, identities, timelines...), deal with
      their appropriate forwarding and routing, and deliver these
      service units as requested by the user application functions.

   *  A Quantum Forwarding Stratum, in charge of the direct application
      of quantum protocols and algorithms between the two endpoints of a
      quantum link, even when it is a multi-hop one, very much as the
      QFP we described as part of QKD deployments.

   *  Connectivity Stratum, taking care of providing the paths to
      support the quantum links used by the quantum forwarding 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.

Lopez, et al.             Expires 24 April 2024                 [Page 8]
Internet-Draft             qi-multiplane-arch               October 2023

   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 Forwarding Stratum     ||     |       ||
           |                                \/     |       ||
           |  +----------+    ...................  |       ||
           |  | Telemetry|    . SDN             .  |  Std. ||
           |  | Plane    |<==>. Intelligence    .  |  API  ||
           |  +-----/\---+    .    +----------+ .  |    -- || --
           |        ||        .    | Mgmt. Pl.| .  |       ||
           |        ||        .  +----------+ | .  |       ||
           |  +-----\/---+    .  | Control  |-+ .  |       ||
           |  | Resource |    .  | Plane    |   .  |       ||
           |  | Plane    |<==>.  +----------+   .  |       ||
           |  +----------+    ...................  |       ||
           +----------------------------------/\---+       ||
                              Standard API -- || --        ||
                          +-------------------||-----------||-----+
                          | Connectivity      ||           ||     |
                          | Stratum           ||           ||     |
                          |                   \/           \/     |
                          |  +----------+    ...................  |
                          |  | Telemetry|    . SDN             .  |
                          |  | Plane    |<==>. Intelligence    .  |
                          |  +-----/\---+    .    +----------+ .  |
                          |        ||        .    | Mgmt. Pl.| .  |

Lopez, et al.             Expires 24 April 2024                 [Page 9]
Internet-Draft             qi-multiplane-arch               October 2023

                          |        ||        .  +----------+ | .  |
                          |  +-----\/---+    .  | Control  |-+ .  |
                          |  | Resource |    .  | Plane    |   .  |
                          |  | Plane    |<==>.  +----------+   .  |
                          |  +----------+    ...................  |
                          +---------------------------------------+

   Essentially, this architecture model incorporates the findings from
   QKD deployments, and enhancing the current QKD approach by:

   *  Providing some additional degrees of freedom 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.

   *  Incorporating the current trends to network automation, in
      whatever the flavor including AI and intent expressions,
      guaranteeing the future pliability of quantum networks, in
      alignment with the evolution of best practices in general network
      management.

   *  Explicitly addressing the issues related to the connectivity of
      quantum links and its interaction with the other relevant activity
      for providing quantum network services.  The direct integration of
      a stratum focused on this aspects makes the proposed architecture
      better aligned with the sustainability goal.

4.2.  Identification of interfaces and protocols

   This section, TBP once there is agreement on the architecture
   framework, will include a discussion on the applicable and foreseen
   protocols and interfaces to be used for intra-stratum (SDN and
   telemetry, essentially) and inter-stratum (APIs and models
   applicable) interactions, as well as the capability exposure
   mechanisms to support the aggregation mechanisms mentioned above.

Lopez, et al.             Expires 24 April 2024                [Page 10]
Internet-Draft             qi-multiplane-arch               October 2023

5.  Security Considerations

   This sections is TBP, as the identification of interfaces and
   protocols progresses.  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 forwarding stratum.

   *  The interaction of these physical attacks with classical attacks
      to the control and monitoring activities, possibly translating
      into a threat surface augmentation.

6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC8597]  Contreras, LM., Bernardos, CJ., Lopez, D., Boucadair, M.,
              and P. Iovanna, "Cooperating Layered Architecture for
              Software-Defined Networking (CLAS)", RFC 8597,
              DOI 10.17487/RFC8597, May 2019,
              <https://www.rfc-editor.org/rfc/rfc8597>.

6.2.  Informative References

   [CLASEVO]  Contreras, L. M., Boucadair, M., Lopez, D., and C. J.
              Bernardos, "An Evolution of Cooperating Layered
              Architecture for SDN (CLAS) for Compute and Data
              Awareness", Work in Progress, Internet-Draft, draft-
              contreras-coinrg-clas-evolution-01, 10 July 2023,
              <https://datatracker.ietf.org/doc/html/draft-contreras-
              coinrg-clas-evolution-01>.

Lopez, et al.             Expires 24 April 2024                [Page 11]
Internet-Draft             qi-multiplane-arch               October 2023

   [ETSI04]   "ETSI GS QKD 004: Quantum Key Distribution (QKD);
              Application Interface", August 2020,
              <https://www.etsi.org/deliver/etsi_gs/
              QKD/001_099/004/02.01.01_60/gs_QKD004v020101p.pdf>.

   [ETSI14]   "ETSI GS QKD 014: Quantum Key Distribution (QKD); Protocol
              and data format of REST-based key delivery API", February
              2019, <https://www.etsi.org/deliver/etsi_gs/
              QKD/001_099/014/01.01.01_60/gs_qkd014v010101p.pdf>.

   [ETSI15]   "ETSI GS QKD 015: Quantum Key Distribution (QKD); Control
              Interface for Software Defined Networks", April 2022,
              <https://www.etsi.org/deliver/etsi_gs/
              QKD/001_099/015/02.01.01_60/gs_QKD015v020101p.pdf>.

   [ETSI18]   "ETSI GS QKD 018: Quantum Key Distribution (QKD);
              Orchestration Interface for Software Defined Networks",
              April 2022, <https://www.etsi.org/deliver/etsi_gs/
              QKD/001_099/018/01.01.01_60/gs_QKD018v010101p.pdf>.

   [EUROQCI]  "The European Quantum Communication Infrastructure
              (EuroQCI) Initiative", September 2023, <https://digital-
              strategy.ec.europa.eu/en/policies/european-quantum-
              communication-infrastructure-euroqci>.

   [MADQCI23] Martin, V., Brito, J. P., Ortíz, L., Brito-Méndez, R.,
              Vicente, R., Saez-Buruaga, J., Sebastian, A. J., Aguado,
              D. G., García-Cid, M. I., Setien, J., Salas, P.,
              Escribano, C., Dopazo, E., Rivas-Moscoso, J., Pastor-
              Perales, A., and D. Lopez, "The Madrid Testbed: QKD SDN
              Control and Key Management in a Production Network", July
              2023, <https://ieeexplore.ieee.org/document/10207295>.

   [NFV06]    "ETSI GS NFV 006: Network Functions Virtualisation (NFV)
              Release 4; Management and Orchestration; Architectural
              Framework Specification", December 2022,
              <https://www.etsi.org/deliver/etsi_gs/
              NFV/001_099/006/04.04.01_60/gs_NFV006v040401p.pdf>.

   [PSQN22]   DiAdamo, S., Qi, B., Miller, G., Kompella, R., and A.
              Shabani, "Packet switching in quantum networks: A path to
              the quantum Internet", October 2022,
              <https://journals.aps.org/prresearch/abstract/10.1103/
              PhysRevResearch.4.043064>.

Lopez, et al.             Expires 24 April 2024                [Page 12]
Internet-Draft             qi-multiplane-arch               October 2023

   [QIPS22]   Illiano, J., Caleffia, M., Manzalini, A., and A. S.
              Cacciapuoti, "Quantum Internet Protocol Stack: a
              Comprehensive Survey", August 2022,
              <https://www.sciencedirect.com/science/article/abs/pii/
              S1389128622002250>.

   [QTTI21]   Martin, V., Brito, J. P., Escribano, C., Menchetti, M.,
              White, C., Lord, A., Wissel, F., Gunkel, M., Gavignet, P.,
              Genay, N., Moult, O. L., Abellan, C., Manzalini, A.,
              Pastor-Perales, A., Lopez, V., and D. Lopez, "Quantum
              Technologies in the Telecommunications Industry", July
              2021, <https://epjquantumtechnology.springeropen.com/
              articles/10.1140/epjqt/s40507-021-00108-9>.

   [QUCS]     Wang, C., Rahman, A., Li, R., Aelmans, M., and K.
              Chakraborty, "Application Scenarios for the Quantum
              Internet", Work in Progress, Internet-Draft, draft-irtf-
              qirg-quantum-internet-use-cases-19, 16 October 2023,
              <https://datatracker.ietf.org/doc/html/draft-irtf-qirg-
              quantum-internet-use-cases-19>.

   [RFC9340]  Kozlowski, W., Wehner, S., Van Meter, R., Rijsman, B.,
              Cacciapuoti, A. S., Caleffi, M., and S. Nagayama,
              "Architectural Principles for a Quantum Internet",
              RFC 9340, DOI 10.17487/RFC9340, March 2023,
              <https://www.rfc-editor.org/rfc/rfc9340>.

   [Y3802]    "ITU-T Recommendation Y.3802: Quantum key distribution
              networks. Functional architecture", April 2021,
              <https://www.itu.int/rec/T-REC-Y.3802>.

Acknowledgments

   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).

Authors' Addresses

   Diego Lopez
   Telefonica
   Email: diego.r.lopez@telefonica.com

   Vicente Martin
   UPM

Lopez, et al.             Expires 24 April 2024                [Page 13]
Internet-Draft             qi-multiplane-arch               October 2023

   Email: vicente.martin@upm.es

   Blanca Lopez
   IMDEA Networks
   Email: blanca.lopez@imdea.org

   Luis M. Contreras
   Telefonica
   Email: luismiguel.contrerasmurillo@telefonica.com

Lopez, et al.             Expires 24 April 2024                [Page 14]