<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.23 (Ruby 3.3.6) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-lopez-qirg-qi-multiplane-arch-03" category="info" consensus="true" submissionType="IRTF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.27.0 -->
  <front>
    <title abbrev="qi-multiplane-arch">A Multiplane Architecture Proposal for the Quantum Internet</title>
    <seriesInfo name="Internet-Draft" value="draft-lopez-qirg-qi-multiplane-arch-03"/>
    <author initials="D." surname="Lopez" fullname="Diego Lopez">
      <organization>Telefonica</organization>
      <address>
        <email>diego.r.lopez@telefonica.com</email>
      </address>
    </author>
    <author initials="V." surname="Martin" fullname="Vicente Martin">
      <organization>UPM</organization>
      <address>
        <email>vicente.martin@upm.es</email>
      </address>
    </author>
    <author initials="B." surname="Lopez" fullname="Blanca Lopez">
      <organization>IMDEA Networks</organization>
      <address>
        <email>blanca.lopez@imdea.org</email>
      </address>
    </author>
    <author initials="L. M." surname="Contreras" fullname="Luis M. Contreras">
      <organization>Telefonica</organization>
      <address>
        <email>luismiguel.contrerasmurillo@telefonica.com</email>
      </address>
    </author>
    <date year="2025" month="February" day="26"/>
    <area>IRTF</area>
    <workgroup>Quantum Internet Research Group</workgroup>
    <keyword>quantum</keyword>
    <keyword>architecture</keyword>
    <keyword>QKD</keyword>
    <keyword>CLAS</keyword>
    <abstract>
      <?line 184?>

<t>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.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://dr2lopez.github.io/qi-multiplane-arch/draft-lopez-qirg-qi-multiplane-arch.html"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-lopez-qirg-qi-multiplane-arch/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        Quantum Internet Research Group Research Group mailing list (<eref target="mailto:qirg@irtf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/qirg/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/qirg/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/dr2lopez/qi-multiplane-arch"/>.</t>
    </note>
  </front>
  <middle>
    <?line 188?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>As another case of the "classical vs quantum" apparent contradictions, the nature of quantum communications <xref target="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.</t>
      <t>Several steps have been taken in this direction, including the identification of architectural principles and base technologies made in <xref target="RFC9340"/>, the description of relevant use cases <xref target="QUCS"/>, and specific approaches to layered models for Quantum Networking, summarized and discussed in <xref target="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.</t>
      <t>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 <xref target="Y3802"/>, experimental deployments <xref target="MADQCI23"/> and pilot infrastructures <xref target="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 <xref target="RFC8597"/>, intended to address the complexity of management and integration at scale beyond the basic layered constructs supporting connectivity.</t>
      <t>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 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:</t>
      <ul spacing="normal">
        <li>
          <t>Agility: Provide abstractions able to incorporate new protocols and interfaces as the technology evolves, avoiding a tight coupling with specific physical technologies.</t>
        </li>
        <li>
          <t>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.</t>
        </li>
        <li>
          <t>Pliability: Facilitate the seamless integration of classical and quantum network operational procedures, applying and adapting best practices in use by the Internet community.</t>
        </li>
      </ul>
      <t>And trying to address three essential characteristics already identified in <xref target="PSQN22"/>:</t>
      <ul spacing="normal">
        <li>
          <t>Universality, so a quantum network can accommodate any application.</t>
        </li>
        <li>
          <t>Transparency, so quantum networks can share physical media with classical networks.</t>
        </li>
        <li>
          <t>Scalability, so quantum networking protocols can support the growth of the network.</t>
        </li>
      </ul>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
      <?line -18?>

</section>
    <section anchor="base-technologies-qkd-experience-and-evolved-sdn-concepts">
      <name>Base Technologies: QKD Experience and Evolved SDN Concepts</name>
      <t>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.</t>
      <t>In what relates to the evolution of SDN concepts, the Cooperating Layered Architecture for Software-Defined Networking (CLAS) <xref target="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.</t>
      <section anchor="a-qkd-multi-plane-architecture">
        <name>A QKD Multi-Plane Architecture</name>
        <t>Applying the SDN and disaggregation principles, QKD infrastructures have been essentially structured around three different planes <xref target="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 <xref target="ETSI04"/> <xref target="ETSI14"/> <xref target="ETSI15"/> <xref target="ETSI18"/>, and these interactions may incorporate a layered approach.</t>
        <t>In this 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" <xref target="QTTI21"/> or the reuse of a common channel, as proposed in "packet-oriented" approaches <xref target="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.</t>
        <t>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.</t>
        <t>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.</t>
        <t>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.</t>
        <t>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.</t>
      </section>
      <section anchor="interfacing-with-classical-networks">
        <name>Interfacing with Classical Networks</name>
        <t>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.</t>
        <t>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 <xref target="NFV06"/>, seems the most reasonable option.</t>
        <t>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:</t>
        <ul spacing="normal">
          <li>
            <t>Quantum management applications requiring operations on topologies and physical paths in the OTN mediated by an OTN controller.</t>
          </li>
          <li>
            <t>OTN management applications requiring operation on quantum topologies mediated by the quantum controller.</t>
          </li>
          <li>
            <t>Topology updates exchanged between quantum and OTN controllers.</t>
          </li>
          <li>
            <t>The coordination through an integrated controller (commonly referred as "orchestrator"), able to provide a common view to application network functions.</t>
          </li>
        </ul>
        <t>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.</t>
      </section>
      <section anchor="applying-network-virtualization-principles">
        <name>Applying Network Virtualization Principles</name>
        <t>Recent proposals for QKD network management have explored the use of operational models that radically leverage the virtualization of control and key management functionalities <xref target="EVCK25"/>. 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 QKD network standards. Integrating these mechanisms enhance security measures and ensure that quantum networks can seamlessly interface with existing and future telecommunications infrastructure.</t>
        <t>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.</t>
        <t>As 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 <xref target="QNSA24"/>.</t>
        <t>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 <xref target="EVCK25"/>, has a forwarding table, which can be dynamically updated whenever necessary by the control plane. Adittionally, 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.</t>
        <t>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.</t>
      </section>
      <section anchor="clas-and-quantum-networks">
        <name>CLAS and Quantum Networks</name>
        <t>As discussed above, 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 archiecture, as defined by <xref target="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 infeastructures, 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.</t>
        <t>The new extension of the CLAS architecture, as defined in <xref target="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.</t>
        <t>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.</t>
      </section>
    </section>
    <section anchor="a-framework-architecture-for-the-quantum-internet">
      <name>A Framework Architecture for the Quantum Internet</name>
      <t>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.</t>
      <t>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 <xref target="CLASEVO"/>. In what follows,we will discuss how this framework architecure would support the required properties: agility, allowing for technology evolution, sustainability, fostering infrastructure reuse, and pliability, supporting operational best practices.</t>
      <t>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.</t>
      <section anchor="strata-for-quantum-networks">
        <name>Strata for Quantum Networks</name>
        <t>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 structured of the original SDN proposal. Following the CLAS philosophy, as proposed in its recent update <xref target="CLASEVO"/> of decoupling services, additional functionality, and base connectivity, the architecture of a quantum network should be composed of:</t>
        <ul spacing="normal">
          <li>
            <t>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. 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. 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.</t>
          </li>
          <li>
            <t>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.  It is important to note that this stratum must be able to support the service units that constitute, but there is no need for a one-to-one mapping between those quantum forwarding units and the service units. As example, let us consider entanglement forwarding 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.</t>
          </li>
          <li>
            <t>A 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" <xref target="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.</t>
          </li>
        </ul>
        <t>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 <xref target="CLASEVO"/>, and it is the main reason for using it as the base for the framework proposed by ths 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 <xref target="ALTOQ24"/>. 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.</t>
        <t>Based on the images used to illustrate the strata proposed in <xref target="CLASEVO"/> and <xref target="RFC8597"/>, the relationship among the strata described above would be as shown in the following diagram:</t>
        <artwork type="ascii-art"><![CDATA[
                                    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.| .  |
                       |        ||        .  +----------+ | .  |
                       |  +-----\/---+    .  | Control  |-+ .  |
                       |  | Resource |    .  | Plane    |   .  |
                       |  | Plane    |<==>.  +----------+   .  |
                       |  +----------+    ...................  |
                       +---------------------------------------+

]]></artwork>
        <t>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.</t>
        <t>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 <xref target="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 forwarding among different locations, or the incorporation of future quantum repeaters into the Quantum Forwarding Stratum to support more ellaborated behaviors of the Service Stratum.</t>
        <t>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 <xref target="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.</t>
        <t>The evolved CLAS proposal in <xref target="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.</t>
        <t>Finally, by explicitly addressing the issues related to the connectivity of quantum links, the architecture considers the interactionis with any other relevant oparational aspects required 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.</t>
      </section>
      <section anchor="identification-of-interfaces-and-protocols">
        <name>Identification of Interfaces and Protocols</name>
        <t>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.</t>
        <section anchor="the-role-of-network-virtualization">
          <name>The Role of Network Virtualization</name>
          <t>As a natural consequence of what is disucssed above in the framework of cloud-native QKD, the use of network virtualization techniques would be essential for the Service Stratum, at all of their planes:</t>
          <ul spacing="normal">
            <li>
              <t>The SDN intelligence plane, allowing the dynamic management of service units and their association with the corresponding units in the Quantum Forwarding Stratum.</t>
            </li>
            <li>
              <t>The telemetry plane, for dynamic monitoring and data aggregation.</t>
            </li>
            <li>
              <t>The resource plane, in support of the different nature of the interactions at the Quantum Forwarding Stratum, like the case of entanglement persistence beyond direct physical reachability.</t>
            </li>
          </ul>
          <t>The current trends in optical disagreggation and the use of orchestrated SDN mechanisms for network path management and monitoring provide a natural path for leveraging network virtualization mechanisms iwithin the Connectivity Stratum, facilitating their integration with the Service Stratum.</t>
          <t>In what relates to the Quantum Forwarding 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.</t>
        </section>
        <section anchor="the-role-of-synthetic-environments">
          <name>The Role of Synthetic Environments</name>
          <t>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 availabilty. This is especially true for experimentation at the scale required to validate network protocolos and inter- and intra-strata interfaces. In this context, it becomes appropriate the use of synthetic testbeds where it is feasible to emulate the deployment of quantum networks, thus enabling the execution of experiments and trials, where even potential network attacks can be analyzed without compromising the integrity of an already built quantum network or a signinficant number of physical devices. Based on the results introduced in <xref target="QKNDT24"/> for QKD networks, a characterization of such Quantum Network Digital Twin (QNDT) will support a better understanding of the properties of the different interfaces and protocols, and the applicability of the architecture proposed in this document.</t>
          <t>A more detailed description of the features of a generalized QNDT, based on <xref target="QKNDT24"/> findings and the principles of the architecture described in this document is planned once the experiments on the revamped version of the mentioned QNDT becomes available, and will be integrated in a future version.</t>
        </section>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This section is TBP in detail, as the identification of interfaces and protocols progresses. The general considerations made in <xref target="RFC8597"/> apply, as well as an elaboration on the following points regarding:</t>
      <ul spacing="normal">
        <li>
          <t>The requirements on mutual authentication in the channels used for quantum interactions, as they should require methods rooted at physical properties.</t>
        </li>
        <li>
          <t>Specific physical attacks related to the particular quantum mechanisms in use by the quantum forwarding stratum.</t>
        </li>
        <li>
          <t>The interaction of these physical attacks with classical attacks to the control and monitoring activities, possibly translating into a threat surface augmentation.</t>
        </li>
      </ul>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC8597">
          <front>
            <title>Cooperating Layered Architecture for Software-Defined Networking (CLAS)</title>
            <author fullname="LM. Contreras" initials="LM." surname="Contreras"/>
            <author fullname="CJ. Bernardos" initials="CJ." surname="Bernardos"/>
            <author fullname="D. Lopez" initials="D." surname="Lopez"/>
            <author fullname="M. Boucadair" initials="M." surname="Boucadair"/>
            <author fullname="P. Iovanna" initials="P." surname="Iovanna"/>
            <date month="May" year="2019"/>
            <abstract>
              <t>Software-Defined Networking (SDN) advocates for the separation of the control plane from the data plane in the network nodes and its logical centralization on one or a set of control entities. Most of the network and/or service intelligence is moved to these control entities. Typically, such an entity is seen as a compendium of interacting control functions in a vertical, tightly integrated fashion. The relocation of the control functions from a number of distributed network nodes to a logical central entity conceptually places together a number of control capabilities with different purposes. As a consequence, the existing solutions do not provide a clear separation between transport control and services that rely upon transport capabilities.</t>
              <t>This document describes an approach called Cooperating Layered Architecture for Software-Defined Networking (CLAS), wherein the control functions associated with transport are differentiated from those related to services in such a way that they can be provided and maintained independently and can follow their own evolution path.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8597"/>
          <seriesInfo name="DOI" value="10.17487/RFC8597"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="QTTI21" target="https://epjquantumtechnology.springeropen.com/articles/10.1140/epjqt/s40507-021-00108-9">
          <front>
            <title>Quantum Technologies in the Telecommunications Industry</title>
            <author initials="V." surname="Martin" fullname="Vicente Martin">
              <organization/>
            </author>
            <author initials="J. P." surname="Brito" fullname="Juan Pedro Brito">
              <organization/>
            </author>
            <author initials="C." surname="Escribano" fullname="Carmen Escribano">
              <organization/>
            </author>
            <author initials="M." surname="Menchetti" fullname="Marco Menchetti">
              <organization/>
            </author>
            <author initials="C." surname="White" fullname="Catherine White">
              <organization/>
            </author>
            <author initials="A." surname="Lord" fullname="Andrew Lord">
              <organization/>
            </author>
            <author initials="F." surname="Wissel" fullname="Felix Wissel">
              <organization/>
            </author>
            <author initials="M." surname="Gunkel" fullname="Matthias Gunkel">
              <organization/>
            </author>
            <author initials="P." surname="Gavignet" fullname="Paulette Gavignet">
              <organization/>
            </author>
            <author initials="N." surname="Genay" fullname="Naveena Genay">
              <organization/>
            </author>
            <author initials="O. L." surname="Moult" fullname="Olivier Le Moult">
              <organization/>
            </author>
            <author initials="C." surname="Abellan" fullname="Carlos Abellan">
              <organization/>
            </author>
            <author initials="A." surname="Manzalini" fullname="Antonio Manzalini">
              <organization/>
            </author>
            <author initials="A." surname="Pastor-Perales" fullname="Antonio Pastor-Perales">
              <organization/>
            </author>
            <author initials="V." surname="Lopez" fullname="Victor Lopez">
              <organization/>
            </author>
            <author initials="D." surname="Lopez" fullname="Diego Lopez">
              <organization/>
            </author>
            <date year="2021" month="July"/>
          </front>
        </reference>
        <reference anchor="RFC9340">
          <front>
            <title>Architectural Principles for a Quantum Internet</title>
            <author fullname="W. Kozlowski" initials="W." surname="Kozlowski"/>
            <author fullname="S. Wehner" initials="S." surname="Wehner"/>
            <author fullname="R. Van Meter" initials="R." surname="Van Meter"/>
            <author fullname="B. Rijsman" initials="B." surname="Rijsman"/>
            <author fullname="A. S. Cacciapuoti" initials="A. S." surname="Cacciapuoti"/>
            <author fullname="M. Caleffi" initials="M." surname="Caleffi"/>
            <author fullname="S. Nagayama" initials="S." surname="Nagayama"/>
            <date month="March" year="2023"/>
            <abstract>
              <t>The vision of a quantum internet is to enhance existing Internet technology by enabling quantum communication between any two points on Earth. To achieve this goal, a quantum network stack should be built from the ground up to account for the fundamentally new properties of quantum entanglement. The first quantum entanglement networks have been realised, but there is no practical proposal for how to organise, utilise, and manage such networks. In this document, we attempt to lay down the framework and introduce some basic architectural principles for a quantum internet. This is intended for general guidance and general interest. It is also intended to provide a foundation for discussion between physicists and network specialists. This document is a product of the Quantum Internet Research Group (QIRG).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9340"/>
          <seriesInfo name="DOI" value="10.17487/RFC9340"/>
        </reference>
        <reference anchor="QUCS">
          <front>
            <title>Application Scenarios for the Quantum Internet</title>
            <author fullname="Chonggang Wang" initials="C." surname="Wang">
              <organization>InterDigital Communications, LLC</organization>
            </author>
            <author fullname="Akbar Rahman" initials="A." surname="Rahman">
              <organization>Ericsson</organization>
            </author>
            <author fullname="Ruidong Li" initials="R." surname="Li">
              <organization>Kanazawa University</organization>
            </author>
            <author fullname="Melchior Aelmans" initials="M." surname="Aelmans">
              <organization>Juniper Networks</organization>
            </author>
            <author fullname="Kaushik Chakraborty" initials="K." surname="Chakraborty">
              <organization>The University of Edinburgh</organization>
            </author>
            <date day="16" month="October" year="2023"/>
            <abstract>
              <t>   The Quantum Internet has the potential to improve application
   functionality by incorporating quantum information technology into
   the infrastructure of the overall Internet.  This document provides
   an overview of some applications expected to be used on the Quantum
   Internet and categorizes them.  Some general requirements for the
   Quantum Internet are also discussed.  The intent of this document is
   to describe a framework for applications, and describe a few selected
   application scenarios for the Quantum Internet.This document is a
   product of the Quantum Internet Research Group (QIRG).

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-irtf-qirg-quantum-internet-use-cases-19"/>
        </reference>
        <reference anchor="QIPS22" target="https://www.sciencedirect.com/science/article/abs/pii/S1389128622002250">
          <front>
            <title>Quantum Internet Protocol Stack: a Comprehensive Survey</title>
            <author initials="J." surname="Illiano" fullname="Jessica Illiano">
              <organization/>
            </author>
            <author initials="M." surname="Caleffia" fullname="Marcello Caleffia">
              <organization/>
            </author>
            <author initials="A." surname="Manzalini" fullname="Antonio Manzalini">
              <organization/>
            </author>
            <author initials="A. S." surname="Cacciapuoti" fullname="Angela Sara Cacciapuoti">
              <organization/>
            </author>
            <date year="2022" month="August"/>
          </front>
        </reference>
        <reference anchor="Y3802" target="https://www.itu.int/rec/T-REC-Y.3802">
          <front>
            <title>ITU-T Recommendation Y.3802: Quantum key distribution networks. Functional architecture</title>
            <author>
              <organization/>
            </author>
            <date year="2021" month="April"/>
          </front>
        </reference>
        <reference anchor="MADQCI23" target="https://ieeexplore.ieee.org/document/10207295">
          <front>
            <title>The Madrid Testbed: QKD SDN Control and Key Management in a Production Network</title>
            <author initials="V." surname="Martin">
              <organization/>
            </author>
            <author initials="J. P." surname="Brito">
              <organization/>
            </author>
            <author initials="L." surname="Ortíz">
              <organization/>
            </author>
            <author initials="R." surname="Brito-Méndez">
              <organization/>
            </author>
            <author initials="R." surname="Vicente">
              <organization/>
            </author>
            <author initials="J." surname="Saez-Buruaga">
              <organization/>
            </author>
            <author initials="A. J." surname="Sebastian">
              <organization/>
            </author>
            <author initials="D. G." surname="Aguado">
              <organization/>
            </author>
            <author initials="M. I." surname="García-Cid">
              <organization/>
            </author>
            <author initials="J." surname="Setien">
              <organization/>
            </author>
            <author initials="P." surname="Salas">
              <organization/>
            </author>
            <author initials="C." surname="Escribano">
              <organization/>
            </author>
            <author initials="E." surname="Dopazo">
              <organization/>
            </author>
            <author initials="J." surname="Rivas-Moscoso">
              <organization/>
            </author>
            <author initials="A." surname="Pastor-Perales">
              <organization/>
            </author>
            <author initials="D." surname="Lopez">
              <organization/>
            </author>
            <date year="2023" month="July"/>
          </front>
        </reference>
        <reference anchor="EUROQCI" target="https://digital-strategy.ec.europa.eu/en/policies/european-quantum-communication-infrastructure-euroqci">
          <front>
            <title>The European Quantum Communication Infrastructure (EuroQCI) Initiative</title>
            <author>
              <organization/>
            </author>
            <date year="2023" month="September"/>
          </front>
        </reference>
        <reference anchor="PSQN22" target="https://journals.aps.org/prresearch/abstract/10.1103/PhysRevResearch.4.043064">
          <front>
            <title>Packet switching in quantum networks: A path to the quantum Internet</title>
            <author initials="S." surname="DiAdamo" fullname="Stephen DiAdamo">
              <organization/>
            </author>
            <author initials="B." surname="Qi" fullname="Bing Qi">
              <organization/>
            </author>
            <author initials="G." surname="Miller" fullname="Glen Miller">
              <organization/>
            </author>
            <author initials="R." surname="Kompella" fullname="Ramana Kompella">
              <organization/>
            </author>
            <author initials="A." surname="Shabani" fullname="Alireza Shabani">
              <organization/>
            </author>
            <date year="2022" month="October"/>
          </front>
        </reference>
        <reference anchor="ETSI04" target="https://www.etsi.org/deliver/etsi_gs/QKD/001_099/004/02.01.01_60/gs_QKD004v020101p.pdf">
          <front>
            <title>ETSI GS QKD 004: Quantum Key Distribution (QKD); Application Interface</title>
            <author>
              <organization/>
            </author>
            <date year="2020" month="August"/>
          </front>
        </reference>
        <reference anchor="ETSI14" target="https://www.etsi.org/deliver/etsi_gs/QKD/001_099/014/01.01.01_60/gs_qkd014v010101p.pdf">
          <front>
            <title>ETSI GS QKD 014: Quantum Key Distribution (QKD); Protocol and data format of REST-based key delivery API</title>
            <author>
              <organization/>
            </author>
            <date year="2019" month="February"/>
          </front>
        </reference>
        <reference anchor="ETSI15" target="https://www.etsi.org/deliver/etsi_gs/QKD/001_099/015/02.01.01_60/gs_QKD015v020101p.pdf">
          <front>
            <title>ETSI GS QKD 015: Quantum Key Distribution (QKD); Control Interface for Software Defined Networks</title>
            <author>
              <organization/>
            </author>
            <date year="2022" month="April"/>
          </front>
        </reference>
        <reference anchor="ETSI18" target="https://www.etsi.org/deliver/etsi_gs/QKD/001_099/018/01.01.01_60/gs_QKD018v010101p.pdf">
          <front>
            <title>ETSI GS QKD 018: Quantum Key Distribution (QKD); Orchestration Interface for Software Defined Networks</title>
            <author>
              <organization/>
            </author>
            <date year="2022" month="April"/>
          </front>
        </reference>
        <reference anchor="NFV06" target="https://www.etsi.org/deliver/etsi_gs/NFV/001_099/006/04.04.01_60/gs_NFV006v040401p.pdf">
          <front>
            <title>ETSI GS NFV 006: Network Functions Virtualisation (NFV) Release 4; Management and Orchestration; Architectural Framework Specification</title>
            <author>
              <organization/>
            </author>
            <date year="2022" month="December"/>
          </front>
        </reference>
        <reference anchor="EVCK25" target="https://ieeexplore.ieee.org/document/10870375">
          <front>
            <title>An Enhanced Virtualized Control and Key Management Model for QKD Networks</title>
            <author initials="B." surname="Lopez" fullname="Blanca Lopez">
              <organization/>
            </author>
            <author initials="I." surname="Vidal" fullname="Ivan Vidal">
              <organization/>
            </author>
            <author initials="F." surname="Valera" fullname="Francisco Valera">
              <organization/>
            </author>
            <author initials="D." surname="Lopez" fullname="Diego Lopez">
              <organization/>
            </author>
            <date year="2025" month="January"/>
          </front>
        </reference>
        <reference anchor="QNSA24" target="https://ieeexplore.ieee.org/document/10628345">
          <front>
            <title>Unleashing Flexibility and Interoperability in QKD Networks: The Power of Softwarized Architectures</title>
            <author initials="B." surname="Lopez" fullname="Blanca Lopez">
              <organization/>
            </author>
            <author initials="I." surname="Vidal" fullname="Ivan Vidal">
              <organization/>
            </author>
            <author initials="F." surname="Valera" fullname="Francisco Valera">
              <organization/>
            </author>
            <author initials="D." surname="Lopez" fullname="Diego Lopez">
              <organization/>
            </author>
            <author initials="A." surname="Pastor" fullname="Antonio Pastor">
              <organization/>
            </author>
            <date year="2024" month="July"/>
          </front>
        </reference>
        <reference anchor="ALTOQ24" target="https://ieeexplore.ieee.org/document/10628176">
          <front>
            <title>Using  Protocol to Address SD-QKD Federation in Multi-Domain Scenarios</title>
            <author initials="A." surname="Muniz" fullname="Alejandro Muniz">
              <organization/>
            </author>
            <author initials="R." surname="Canto" fullname="Rafael Canto">
              <organization/>
            </author>
            <author initials="L." surname="Contreras" fullname="Luis Contreras">
              <organization/>
            </author>
            <author initials="A." surname="Pastor" fullname="Antonio Pastor">
              <organization/>
            </author>
            <author initials="D." surname="Lopez" fullname="Diego Lopez">
              <organization/>
            </author>
            <author initials="J." surname="Morales" fullname="Juan Morales">
              <organization/>
            </author>
            <date year="2024" month="July"/>
          </front>
        </reference>
        <reference anchor="CLASEVO">
          <front>
            <title>An Evolution of Cooperating Layered Architecture for SDN (CLAS) for Compute and Data Awareness</title>
            <author fullname="Luis M. Contreras" initials="L. M." surname="Contreras">
              <organization>Telefonica</organization>
            </author>
            <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
              <organization>Orange</organization>
            </author>
            <author fullname="Diego Lopez" initials="D." surname="Lopez">
              <organization>Telefonica</organization>
            </author>
            <author fullname="Carlos J. Bernardos" initials="C. J." surname="Bernardos">
              <organization>Universidad Carlos III de Madrid</organization>
            </author>
            <date day="5" month="July" year="2024"/>
            <abstract>
              <t>   This document proposes an extension to the Cooperating Layered
   Architecture for Software-Defined Networking (SDN) by including
   compute resources and data analysis processing capabilities.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-contreras-coinrg-clas-evolution-03"/>
        </reference>
        <reference anchor="QIROAD18" target="https://doi.org/10.1126/science.aam9288">
          <front>
            <title>Quantum internet: A vision for the road ahead</title>
            <author initials="S." surname="Wehner" fullname="Stephanie Wehner">
              <organization/>
            </author>
            <author initials="D." surname="Elkouss" fullname="David Elkouss">
              <organization/>
            </author>
            <author initials="R." surname="Hanson" fullname="Ronald Hanson">
              <organization/>
            </author>
            <date year="2018" month="October"/>
          </front>
        </reference>
        <reference anchor="QKNDT24" target="https://doi.org/10.3390/app14031018">
          <front>
            <title>Service for Deploying Digital Twins of QKD Networks</title>
            <author initials="R." surname="Martin" fullname="Raul Martin">
              <organization/>
            </author>
            <author initials="B." surname="Lopez" fullname="Blanca Lopez">
              <organization/>
            </author>
            <author initials="I." surname="Vidal" fullname="Ivan Vidal">
              <organization/>
            </author>
            <author initials="F." surname="Valera" fullname="Francisco Valera">
              <organization/>
            </author>
            <author initials="B." surname="Nogales" fullname="Borja Nogales">
              <organization/>
            </author>
            <date year="2024" month="January"/>
          </front>
        </reference>
      </references>
    </references>
    <?line 418?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>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).</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA9V92XIbybXgO76ihn4hbwPgIrVaopdriqTadIsiJVLtcIwn
HAlUAqhWLejKKlJoqR3+h3mdifDTRMzD/Qn7T/wlc7bcqgqUNPfOjRja0SKB
yqzMk2ffcjKZjJqsyfVxsnOSXLZ5k61zVerkpJ6vskbPm7bWyXVdrSuj8mRR
1Umz0snrVpVNWyQXZaPrUjc7IzWb1foOZvkxmxRumomCaXZGc9XoZVVvjpOs
XFSjtJqXqoBXprVaNJO8WuufJj9m9XLSHzw5eDQy7azIjMmqstmsYdjFm9sX
o7ItZro+HqUw9/FoXpVGl6Y1x0lTt3oEK3k0UrVWsCJ8fGd0X9XvlnXVruGT
7vKTN9pofFvyLT6xM3qnN/B8ejxKJsmP/DD+qgKg4N+vvzvDf05fntyM7nTZ
wkKS5LNfkiS8nZ3+F4XKcoJlvfxtVjeLaVUv8XN8Cj5fNc3aHO/v42O0pjs9
zTQ/to8f7M/q6t7ofZxgHwcus2bVzmBoWh8RvPeHzilJcoCmaYJX2OenPMM0
qwZG7n/GQU5XTZEDnrTNqqoJsIwDZxmgRvISh8L7E9iBKrOfVAOnfZzc6lwv
qjKbK/xOC1hSHDKtp/S+3zbumem8Knb8zN9ncw2wTy5V3WRlf/K315fhrHf8
+LSgx3/broupNsF0z2Erc7VtpReXZ+cnySvdIJ6ZcN4ZjZPFZkWqlZymnfhl
m5nkcpqcAn7Xulbmc+GQw8AiW7Y6h53L2KKtszyvelAZlVVdwGx3iKNvXpw+
/frZN8cjJEf/8evb24ujQ8RhyxIsDt/q+aqs8mqZaQM0TDwA1wRTFy2+BJdp
ANXT1jT1hlDVHvT287Bf/B7eklzrtK6S53XWVMFXp6oudJmcm3mdzVQZfgXT
zKvkUpfzlW6aLBoE66sz4GJ/QHINvjkp01rfwxnWafDpC51n75M/AIvRefSC
plllyiTftuW76Jtr1ebwTp18q+6yJdB28N0rdad1qZJv4T+b4POrPLvLdJ28
BABUQBrxJvPKJCcznQOuRMtt4Ahhk6r8SeVZmQ18d61MU9WTazj8XJsY3PCF
w9dheiPuCQeQb5Kjg6NDPHpVLzVwAMsA9PoH4YCNRYLN1KwBvEsNYkGXiF/7
eKRzeP/+4cH08PDxAQ1r9s3jg68PvpnAzJODg8ODp5NnhHzPHj0+QHx7e3oD
lDM5myKPE8bB75pkwjUnrdGTuTK4tdcX1zdHR0P46XgsSKqmmld5ctOo+bvj
RAFVFetar0A4AJInN219p7fg5+81yBig8Is8z/qoBmdTwUkBVS0y9dlntNS5
Sm5UDetQ83mm1m1FqMpwP2mXbYOAPxoA/P39/dTMM8BvnWY1CB0CtHxiAb6v
ZmZ/nWX7N4ePnj47PHr65OjoAOb7+mCU/PHR04MIWhe3bye3IIaQanWZEtEm
f5zSY06kg+hL0gyoOJu19EApPG2avGjLOX4EikAoCXf8fgAt8m2IhPvJmnYK
J7sP29m/nbw5P53w60fJ5cnZ69OLo0fhem9XyCzSOkuB2ZhmptNjFLnJzdkr
ZpZwzqpMk+9gyQB+tdSwrQb5k0JESFtarWXK3UPPSlAWvp+G7Ig++v30ehrw
Ifrs5TS5qpt//NtP/qM38tDk8h//u0x1/I2wunBSwAIQjs/bulVL5b84meJX
egZUnKlgFWfTb6fJybJVabCMy+nFFHhOPf/Hv6nJaZbG8+sGUMN/dI2vzJXx
n5xOO4yUPj2fJmfVWv1URbO9ye6UmVxWZl6ZKlzuEMORFW/hKo8GkCHTWr9f
51WNiovWpLiAWtjiAQIPOTr45ujZ16Pk/O2bK0CLLlKct8h5QGhYpD0N5RBw
gwVIQtADWXvdxcdhlj34IgMoo7TzOHuj141GVXLbUtMMVB+VT2BCVGM3Uz2f
alyAgn/2dbm/rvIMqNLsa1mWY2KReASWFi5rgk//OAdmcH3z+lXM1q6BdwEz
M/dZA2RWLhGlZU5HjnAWyRoEXdJUJI5/7KnkQzzuptFr4IUgBU5SVYQ87jm+
53XIvb7N4cFL0CZ0HXz6RhVAasl3wFZRXIXcLgc29ROwu5UCDPNc7grkkMB3
iM/9ULU1sBQzVWtDeLCua1GIkbsB1OcNi5WDR/vXq415o++sxjx9PD14/Ojg
yWNAldubi4PHIRTxk+TbG2IZB/CVwxbkF2chi9uFR/Z+CexrnXscAjAu1Dzk
bsCtDbHrgy3sTTcmY1QGjeJO1/v4wZ+XZh/m3wcB+OeDZ8/g38f7B0fTg0P4
/5+fHOwvzZ/ha/j0DiY+PDhcT9fpgvdzuH0/h5+xHycMkUnCHlTC2l5SLZI3
5ze3E+A6OmWOzwveJCfXF37HL/QM2FWNVHz47N+150PY82G05x/fpfDpHe44
3vPX2/f89af3bOWCOz+yWW+qRXMP5mByphegF6ZOUR+QXdtk8Wdu9Ouhwz38
euBwn27f6NNPb/QK0F8TT4rQ9T97u0+750rbfRqf66sX3x88GdotfAGk+eTY
LtCpGAZEaN20oFAZ3uAuPLoHukuuAWeTx78MBT6idwSOX4buC9BWXtTAoGj+
m7WeZwshcg+NMz13MuCLAQIrC4j7yf4BMiUPENz8wZO7g8fwP3f+359+dxQh
+gkYOeVKobLntv4T/P6AnnNZwUrovBFpwiPu8/2O8Wo/vrgDIfp9lqrQugFo
lfMMBH/yPUj4OmTxg8aDKoVHHH395ZL+6TcHj76Bca9f3ZwcRezubYlnTeLv
Ra7fZ7Msz5oNAYKwHRZRK/kQ5GMIAzCYQSJeV/dwosDrhBwInqFf6z8TVsNm
W09XevzlEHxy9PTRY4Dgycvbq9cdEBqEnpcDoCqcpGABGwM69AQh9kKnWlgI
wJD8f5OzqlDwxw2osAC0aguUTnL9A5wF2OyXoOKEW3yjFgoQ8xT4V6hgkJsj
9HFsBcnDECRvwWVltc//CPgdfvNkRF688++v2CB1/hTQ4bIS7NI5aNITfVfl
xITRFn1zdXIW83DLsq3tiiraXYZ+S+c4rSuVJmqlVfqAfgbKk07+oFdlpHid
qTswhM7zd1VrQvC9QYMsTX6nSoML6yldh0+HlNqKeRnpVUdPrFk5Vap4dvQU
Rrz+7tXZbYxNN7pGHxnt5UwDQDeIXWesHie392AFILV9mhm9UW3e9wL9B5Hd
86r+QSWvqmWMH55JDaFIAI5Hj54d7Kv1+vDxwaNDBN5oNJlMEquJjkYnCTqb
QSIjD671QtcIucgiTgrHmoe85QkQQq1/bEFdTpEm13W1JKIEqssakzg0G+NX
cOoIZ1DenBSzEyOiLYV8AfL40Vpo3SSKtdlZrvEdWTMm1gk0PctxPnxYpXco
cexY5fVfk7BuiHyhmQI7hSXzplbK4Hwols1iA+NqrRNYPEAjAzSQfSFtARtW
S+LP48TgCnDfdj0qVevG2i5uw7gSa8h0fIu4nqQJ/JAwKajjwKlECIwTMJdW
CbqkEnWHnnEvHPy4uWJZquEQq4L+hEMpDEMH9u9mm2kCu4WfgFrzW3DVJIB4
cTi28JIZDgHkOEoYfPm8BYMGPvWOFAKnZUH49Loy8Kxp5yuYKkYld+pj/+Zl
BcsGUIXYAfuZgykLegNBDnnOJ/El9uoCQqeMkLM2A44yjLqxbY0bR5QNZ3bL
tBu3g6cklv2ysgDLCP/yGhjjJtHvG3HXAd/WNXEm63VOifEQ3ITXCFg7K+Mz
gYlrjTENWKWz/Q3AY94G7+2A5aEJDfNAM2WuUGRpmuvR6Be4R+dxAh6BT1fo
hU7Qd2kJbAeliCGkuzMW0XeQ7hQBiqSOSjNWgcc0plQE6O2E8eED++1//hlw
2JhqntF+6RRoMLxtDWYzvVYvFoBXQMEr1VhaBeQxohZ3jxdxQScEK8Sh+M3A
nQhtYXi2LEmrxj2sVJ7rchmc2IJgz8BV5cYBeAvz7LyUqCJ+8xQEDGjgMDvw
eIHTsq7u2VUCyAaWAB5ux2cCX48JW0NGx4TPXAjOAOkn4h645h4ZjB3s4GsX
e8RXbiVfx0lMu15XddOFDTGlkA+m2YLA04Q8HcnNmnqIhDcIB1gySKO1Ad4M
NDPTwAAb9U6XfALIash/TAIlK+d5m1oBkKXItq09RHuNDCd088+zdS7Y3+PB
wPRSOugPH8Stj1jIO0NP49pOC1So7xA94FiJJAhv357eENYiYVkMhLMBJQmN
OQRWrjYapSTJHsPGjpzFq+BQTVsUouCTrwNUA1CSiOrxPRQ3+PnnKcaD8BBI
TrqdMRdFXoacB2UX6JJ3Km/pxISZYlS3ZIRctDVTdpUDllTCOBQ8tXQYh6uw
aL5GvYEOWdeMrGDFAGoAg4i4rl0HLs9UOSh7HnmcuoALsPqCeAb7ROaAGWMO
MySPP46mvZc/lGKNMu8ClFNimBNjgWOsIzKaJle8En4J6LDp2CoklDsguIKv
VO5Y7WG7vVvq5a0BX1k1hrm4VytYUleNaBwF4CNozKZgvcTxrmF2CXK9BfJd
ZLVp5CzSSo4CKSPUZRTCsTGyZgshYJwGWCnJPsA8VCQY64oKuE5WIHHDm+PJ
kR5xc6D4zOeASUz+pZYTZQKN4TzTm0o4kwWX29xYdAVk5MCD4dnmHsneyxdc
UJ/9Ofk1dkMipc+yws7IcaKbOXCbizIBSYX8PR/HKhCKFi+rnQZAYE7gzSmi
ZVegtoTBg+cUc5mAOJC/zolL2/OQLY0FFIFsf9iFNiZVFjZT3cPjEZHiC8Vk
tNTIA80aXWxEEsw50XOK0g9d8SgaRLIarYuOAk4ySpfEra1O0Bcs0wTNi3rd
miFmbCnpwweK7SHvZKgjXcATXjnCZ2xI7eefmWKyvOrqb/iYxFjgKREfcBDa
ysDciXFAUGQKG61qkZkg7p2ghg2msI47+nPR5qSO5q1hktPEkADUoIyjvCxm
5JUkNJF5/eYyz4wiSUoiBtMWcNsh31Ti0iCVsyrW6CxiwV3EPsJQz3NUHJAZ
iDfgmZbYUKwTnIwV2Yit8GmJsvQOXgEUsUWTVwllv0w4l2qLnrPNPBwLKJH/
V0VwEh5Glk4foj/UjePTZv3bzpIgxhbrxvDhoaM4MjKFiGPzbk1ut0aIcgk2
NaxdkwqpVYHaWKzE4CJ93oDXtRC4KOK83tFlQ5E5hbQJXOt4NPqX5IRtymN0
azFLENOchzp7DcmoIout1PdbdSjmoeEiaQN3yCLVXWWtqwYlEay6XZPxTLDx
UtZq1yHTmuJabyIL9RjdXybD00Xx1iASAlEkoBpptzBQL+Ajws2IcGq9VDWt
Rpd3WV2VQvOkPKHSn6PsATCYUMn7d1nDCxBostbYLKg1UDlt8NoZzMfJCzXH
3xDixDQtQnTMqwdlVITR3oweE36QvwkHkfMA/5ihou/QA/eG+uVsQwtwNqtI
FiLYE0TAmmaKWEeM5qBR4KSweVBF5sZZplZftpolh25//pkQ822JYQGgLOvx
UL3dzUl8kcqFfimyhgLMJ5DeAkkZMgjnPE038kuzmBWqkA7zCp1mitHSw9c5
HAgV4RPn2+jPigDxNEJvCOwUNK7Qt7IQtYWGwLRg+AJKo93k6PbMaaIG2aOm
8CImU5pk5/Ltze3OmP9NXl3R72/OX7+9eHN+hr/f/O7k5Uv3y0ieuPnd1duX
Z/43P/L06vLy/NUZD4ZPk+ij0c7lyR93GJV3rq5vL65enbzc8UaR5drK2ZzE
Fta1RvtZmRHbMDM+7Oen13//2+FjOPT/AnLo6PDwGUhM/uPp4TeP4Y/7lS7H
4nYAguU/UQkcwRGD2KTElByl/xo9pojUIFpW1X2ZgMpM9PRfETL/7Tj51Wy+
Pnz8G/kANxx9aGEWfUgw63/SG8xAHPho4DUOmtHnHUjH6z35Y/S3hXvw4a/+
NUdZMzl8+q+/GREOPUd9KMwx5Dyfcy/REKrnxJdTm/6D3i5BMdHByPTr+Ye6
Gg9qfYtK1D5Q6ymPmAxu0eScZTiO3VN9ZjOop3SEFwxCj6tZwUTAy6zlnWcL
3YDeZmnKMatddgRo1K1AQ9B7lhdHLiujURF3LBWhUbPHCGSKdwPMkTjrJUkC
Hgj2bQmkqNicJfEA1rJaLlG+sI7LeS7kYbXiuu8nkAVozisgdVAilaTzwFjR
lGDNwI8LrTg6QG+MXBhgVNyzN4qSjwd9wnjk4uAUd89pJZICtvZSNLaTrnZl
4+CTThwcB+1ivGcv1CoTT++K3hgdq8Mg4gYwTeCgIZCpMUUggPJtoOQGPxZn
AHN15Kfy6TRBixnMjcBW7g5EkKqsZA1l4ULj1qUpkCLTyLhzYQPPa1pqzWwf
dbaKVpyyfYMIh1L4c6z43vJJ0wbxqLuL6yBqgwMXQmCIKtbuFG09MPkAMdcV
oAYaDNPl1Juo8MWEHA6p7hiveAyy4wTQV9+rjbHG6i9+AbYUMgCOal73yhpA
GbBKBQEfT5ydRyE5hOxgmJ1YYnPqA6BAgC1CaqxiBE49IpPAe2u9U/faeYdA
SrzjIETVgpxK6myZwYEMuAPuUYLAE8sMOQc9QEKcJJG1nR1uCOJkBakNQMQg
6mEADxNaNiAc/QiyROIxOYXXacxYgjtAW+h0rhqGqep4NNhFpnNx41jXVRck
BWZZoR53r/N8kgrpBio72KyU7EUCmPOk/K9f+1+fWucivMboeC2F2kQ2Qt8n
xayJVAX70Tiy115U9b2o5Ixcu69fXO8hHDDos8IQIwVpYNlVXVg0C6JGu6G3
0Klte0SdAH9xPiz8a0RW2GEortAaBE5HYT1+HphmLoUD8nobrLTjAG2rtiZC
yrN3Onhk7FN/ARIJWhjlks9rCiIKCUBg8OIavgXeYlrm2qjYhIyAtOAoylnN
kJeRlxXouakmmuIpc1C3SEdU87oSK94qmBwoA7Mmz4TPEDuRYqBt4HD+/Pd6
7iQIado+OuJU3WnyqiKDhdC3zVPn2SdYsp/Gq9ShSaIzYpJ3oHgrJw9Tr5MH
0R70UJY63wnIPbEZAbq1ziBxxcrDpB6KR4Fkzs6a0kInFepE8Kad0FfubRE6
KNoPRiX0eAsSAchNYinU0nRZpb7Ag10Yq2qNK0IpZD09FegU5CSyAb48K9Du
I6TOSlq0WjoMHEBXg1aiGdtg8owdAmgZIwBV3dhVAp6BtZJRAJBYTIoSU78n
39IdCtsKFaWVyhduCDDpCAuBkK84sI5viCXtFWwFCN8S8M0VELAYPibEAAex
yDVjKWG26UhRxlt2KPM8mNoCKuG4o0qNXeYlcypUC+ebOZByoELK+9GENTbg
1BYcW9mlVUXhIoy+NSs3M7I0MDn58NFD7twW4rLcQzQggrECuGvoJSe597eG
sEWypMGwXfZ1iVMwOM4AMg51JZYNKJ+jYVTAM9YiLwm98ExIXeBZKaW/Z9iS
y7ddsqsZjs6LFrCqkJRhIYryIO1+lNPQHRTQB28CdGO3vZUVtM4peZCDA/Eh
h7H1HyIHC4hsthkgLAw78IxCYbBmwRWvTRUaNpUa5+BfbWZ1llqGTt6Pdkm+
H+8nz35scXbhKKxrU+h0U85XdVVmP+GacInOgVEby3BPri+SGaooqma31Yus
RB3G6tk+/zDIPRR6Ob1kgUehHYGhOwRSAIC9s6MjRbpCqjPiHiJHURfR2J+q
naPNKnrOgVKVi2zZ1h4au+JU33MZzvYMMue4ZRtE/I64nRx1FsVeE5pJnGHA
T9AbXUvypWylo7MyQCK9uveerpKDiIWrRSy18qnjnbYTO1Wa3LVm63ORx7QW
VtjdY6NYgcREn0YtHcDdLiX3r7FKIppXoWPXG76sxoT5Qs78RaREXykwIWtu
5hXJPVkrnChZKIIUBXlTgfRTDojPJhVws4IH+PMl63BIsSSMc0Dp7CWt4EBQ
e/bZFKJnes0miP4K+uTCwlnU9lN2Xm7ZD3KXKHUG4U/MVgk6hAjlVx3GomMz
aADZclHLo49Sj2Rw+mTdgfGOYtnG29CisYrOuDuffm9DFUE6m3WlS65X55zF
/OKlgF7CLn0mc2b7sZGskhUwGrSiOY0i8NOPWYCSDTEh//fYbmfiLUjExnZN
YmFAiNADrKVz/H8zbKHhEQWOEI7ClpxllIo/ifZrM6xC257VRS+K2LFhT4Dl
UnDeBapuyIZrEkxOp3uIjQoIndphrU+czse2w8yDKkx256gOMJh9ZC5py5o3
Ra+ypm3kiGkV7ngXxO8bm5mqXGTSBeSbalu+kaWJsYQkyMfPmJLBEjPy3Lc1
Yhdb4bY2wQVOTp0gd/XS5MZzJt42190W/3ayy/vLIwc9yM6r21fj5ApYCz7t
XRj2rXukf5LtHjj60EznSGBo+nd8Loh6aKkX7PrG181AbzlOFnEQxGn3ziro
hFJ24yRGpq0gArAnoQ+aLYp0uT23Yh9wrCf2YOg0gJJkY9IzbRCsEBcjr/Vh
T2fAdiU/ss80u6e267MqWQ/wkYg9YIOsM/KpLnifHhECAoiUWHKhIttA9fN+
lc1XrLdVc1gFhnmY5wdsI7Fcxhuf72KtjtNjo29JeyFNA5XI2V1WtUbOgnLk
OY94mtyQhVJ0wjmWLIy1tih05vAoMA9jCtuVdBA4/3qzZjOBi7TA9vBUazYF
KIs15kzlS2CKzQr10bXGHB8ig2bzz7/+rz1cAQop49RtD14bggbOMd5CXYFr
D/EBj9xY/1BtItuoQkdQ6XiJRBIJoTJykmpVWIEb6ErAurC2WFgbx0yik4N3
YKFQJ9MnzCS0a+R0DmaWlJaK2QCBsixs2dj6qDtbadNVppNd+QoOFUswkQWg
gT/pjBAPLSV2wQm+Qx9+Li5IIKsMSxnXlC9ACprlkuHugnAu28bOPkPhwNx9
m1moBuwyNAQkz1KxcxB4PSoQVgpcnry6QvV7/i758IFKs9BPhikrbKpSHhOc
lanYqVStJTYpRDUPZFmwHKEvq2oBRTRB8qpdpdNZnBbsdHD/cEdVgX+0TaQq
MJEK1Flgcc7hJU4a3p1IrX3g/cEcnPclpMAKQSQRo9wBG/kk+2gy4MIM5u1C
IU4tHYrfU6zY+hC3jBQnlETwrb8QMZTVrky0MCdVsBLYGRu4dTE8iciAvcbQ
oIAwPfX5rw/zaYNVhO8JnXGdl92KugjqXEr+Qv0eaXmJA0XfDZ2hncPjKVaB
ah1Ssyp9dn4a4o1XCygDp2alYMdrT1W9g7JPjt2lmFnkuMv0fUf57FObp4vA
9PS0YDkvGSKYoiWK5VxHin6PPAYqvi1knE+7pgBh7NeGcV072EYTFkDS2QzT
SrhQAgGDui4chSYSx+ZJGE8CrM989jNmGlB2QJRr4GODPR+p+C9NSEqozYVS
Cs6B/XkcouIpiG3kuXBWOws7FCUxgfzVz58/fey9nDgajXlOTXLcydbDYIl8
h1QwxalB2vXuR6vGwF9FVmYFWGsiJvmwTMxTaUZvJAu6usQwJ1cdTrutS2DK
Bp5s3ev3sVi5dprnaPSmmyBnKz4HdDIKRknmYnQ6YVqN5FJzCQCjJWBCTpnk
S2apHSnHPkfH9Dt6U9ch+OEDl7eiK5o9GIGfeo0rxFfcq43YHpRbJYnJQZ6Q
hV0cUSDUDVQSWzISRNmzMnYuoTu5bzSEWVIWS3E9GGjc9/pECzOUjaV+dr9h
PZuAZmw9W9F4jtjbOYrKFSiRya/SFWdVYZwnWHd4pvAxOuRSMyXzaSmRblYm
Az1Ic80wxlHaGuFTAJG7ahUXRVLNliwiydHKN4FSSCDW7zPOwuatcGFGv+NT
J8FwNGKvBprU/HIgMjheit2CRcJ0tOiU89bauX3kUxRaqMnhAvp6KJMscjNY
N2Cz2Hto1awBUuSJ6Wp6LG3g1DuozYEz0zWvcJnA91Iaa/0eM2sQwKqsepiV
eFQUS2MzBFROkCPoEwwTrmzIDQtwMqq15K2LvkpK06ZUBSnz6DtzeRZB7XIf
Esjtvd+/cvGHE+Nl9VBio4cCTMthX7IoHnxZUOWD3rIM00gwEU+kcSXY6SBN
CECSI7b/UCWuqL6rRNcBvdjmCop6MJZkSBufZTy4DzEfsRSj4r5YzJ0Xo4QF
BlVj4UuQbVm1Y+ys1QA+znNIp5I4K8yZhBam4UxOjKP0wgoXcvUj2ZoGWNO4
31CJ4tvOYVvDXza8TZK13kgYDiHK4c6G7atVtZ7MNhiRwzTxDhfmU+Q8AELm
uTNByUqgKVnz9e6qzFD8QzJCmFsQK2EJZ5G16W1i6iWWZRKB174rIGyszMlg
ZHWWqoSFmR5biAgoYLPG+QgCacFhkoQM5go+XwMxRqlMnHVOTW5QF6ESEtNM
+hK6Cwq7nMABPsUy+oyFEgZKssYSMrCHfEJ5XaG/HJTJDJRNKlVC7WyS1pSn
MWxJiWqlMpbiaj5HyuC8Vxv6DgjhwwfunQDilt1oIW0PIgkmCaMGJoqzQ7vI
85xnkZkWA7ZQmBsLBynGPIJVzlNiOIKOFIYjrQSz7hwrmVWUW14ZEU4LRNEg
MOaz0EWGk2vTZYKAMqTJF4MnZKv4DOWL4L9xLG7sLWpxHLHDQVS0nKKgwK3Q
6+l1DRf7oQXYDY07DkYP3hoRuWEFiFKDrQ4kZSahQo4iX1t5IZ5z4f6kijET
TCmDFLUyoFFEATqiKIxlXQQngIweGzmAaT0fqGBVWAw4a6mpFHJC2mto1RhN
aEWxHzs3uy/RGYJqYkNp1RTol+R19qIrlOrppF2jvaTyVttg8mtxRGMcQoLt
u6+rmz22jQZQNdoTgYXwxsu3/uGwnOCztyVHQxiP3g2uk3Ti2iKWAURzZy1n
wYkjfMIe9FanB5lEciGwjDtBzBfOux4s1aYDHHPExUchS0vhITfATx2xu5Bj
VQCYmUMkoN/QSYCwaxGbaFTAaeyLhR6NbkJlI8qNcXE8XoftZxZIcCLSskra
0mq/AB3SdLkckcZhUKaOEnhA2wI2sbDJO3HwNrDDaA33FgsNebLFdRG7U6L1
NLaQcklmWGr9hmAo1RR0B3Qbh6zbREwZG90aGzN1kgnkl1jaWN6p2eOJ5oRU
AsjzKEMY8rCsH9ts/g5VolxzkZDk64G5uAAuTk6tWsxq1P8b8r1VLjLMNiHm
o9KLOwWuhhQYX9JKgYaxBPdcGJMtP1JmXTFTJ2DgEdh2Cgjsu4FwS7dY2KcP
IuB9QV7qWEVW67Tnjhj0EfTrzMNyAzdXZFTbfBV2iVaYDIkExnDDvE4tyZDK
OFkBKBTVjUnBhzZsorgcY5uvYvcacOvdxgaO9sIWAK46NLNpqDYBDB2NoZLF
cUOhQxdgAxHKRc4u04oZn3vAZyNbgx+ApqPzkfSXrBHvLUZ/V6C5EpvuF8cN
HxFxTof/IcQjodqpqbJO/qgw19coAZuoCmcYOIcqR2F9jVpc7SPxJpENyBFE
ufc81h92M3DaJHiljw+c9t//xpF506sSFN0/yjGP3Gx9fLd7yKTRgzVJBA0o
8rGmrqxtrhyhEVL5YFCYg4DcnFl4lEpC3GElJZU+NZbzsrIyZq8uPz/oPoHv
0UiaAGWraIZZQjax6ASAvkGeNk5OaspIQ4UOvQ15nvEZ7Z5c7EnImoIgyUut
atKhdy9fUp6qWLuhlzrM9p/nmLw4yatqHaCEHDCdpdf0bAIKJlNKrX0UpI6t
QRZirj5kqXxFKRsXvhKWgvQWX331Y686t1+H6byUYWo3nhusAQc6pSMu1EVL
FiGBwTa7qszLDZCHeSomrihLpIWQ2eCzAJyFEblOUNuqioDSBmwhqy+EaWoB
puh6jel1bvG7VEuW7m3r7RIkrVC1zknQT69XcjEEyNHoedTmxRW0BgdYDbV3
cU6owbSO0s3YrRWZWEEYcgqTRPVcJPU7ZsQ4abbU827t6hHm/lB1xf8nrXgw
J3ZOxQZr7LZaNh4qPbBItD1GajLqO6Q2jrhjkFUS1Ud1CA+NwM4ciaQv89vv
bc0yOzZk0kB3YY4Wt5BB6W0GO7dI+mSQqxcmAoUdKTjz2j4l1WfEtWJBQ7EI
qmHiujIzvkfekOdWa0tQKNOegnYwsl5cLpvJgxqQL7gOumk53yhhU+zgk8Zh
3d5YD9fy9rtfBSXvoZCOM0MwWZTj9kVFVSj+pGw9imDAYKWcr8MNNQvXKkZK
1ay8AlnSphh/EcfheIiOftJ1NWmqlhQs71CpBgUyq+lEbZiPx7TC5RtFhnZl
Fh8rdpOHM5e2ucMMgdXsT6ROcY0IU4pOu3q2wzwuK7OsO6s556RTm8zGww0/
OtAfxwTCNlryPUo3aorFUg3YQZzZjmUhkrvAzBhoNHPC16WUmtCEpNY0qiiC
avMQfXzwhRs1UPqU+A+XFSf8unYMlLwpA3slT6nVCJ0dINmOJN3RBrc04tTG
9SoDdaQCVbdXWpGR8kpxNna+hOT9979RcajzbvoeKoGMjqJUTE5kgcX6dEdX
kLqPbpW4z14ni59E54J7H3RLBDHLX/mWBGS6dCpw4lpBTszrls5ECiUMXDpl
ih1vXUvE68pojE6TE6kBKCqmN5dGYunfNWmR88VJYk/NGInCp1iFpUex+zxS
5zobmCZXyI1MvwyBjpw1LJcULxE8myyF9UFtzQnONRXPAFzZ2LQ2n5HiR2bY
dnbh2MK27LNcrkH1GWMu109d3Yu8kpwsuCgsiDbTKaYM4Xm6w+RUIefQCIP6
GEhhF9BY3O9U7SFBmHgRylhPnpdn3Q5Onbxzq8QENaU0mfSHCVRiYvVj20cD
+DhmQzVYpsMpq6DDS6sKl8Tf6a6wK7YZ7cVtyt1NwzXJRPZ4IAAlqYj2mhQH
LgXHo0wW7jEUuedOjE1SQtksqS0koSvf1ocDVUg7HHshrLuHryd4q1TceBBk
FOYtIOHcSX0RdXYK55P5//nX/4FVXP/86/8E1J1l1jrBYLg0zllgFp1Rm/GA
sWgNyZpCsdRoSrwX7OiWlyAItSACvk3Uf/ut+HQH6zzDgvcCdzYHwOMh+x4x
OA0QYF7N+vQXsC5UXPklLAB0OmUONlA+6ZhZVDjJh0S+1k42oH1r3NQlCOGE
kQxKcQkrmzzDRWffmIvt0dduW5QGlW8VpmdTY/zCNdziao57HdaLG1e11lGJ
p0nCJQyuMRiCsuSaQ1s6ZdkKRQYxG2WgVWBM0Zx073K8w+w2jOlVvrWYwj1g
ABMp0hZaefigMHCZFv5EhG/EnhD+lAhIv1cov8dgDmCtrmeFEd8OJsQqSXPP
r7ehD+aimNKTS+YudVAEUGb1PdYJYRq2LzAzFktwr1y21asdlIR89tzeaZfC
RWmDVA85yCWcQywUpB2mL+h7GrokHeJKnc1cis18Y1abg2S65xnioJRWdlLo
Otw+Wo4CJr1Zc7zIlXb4dcVyaqbjAiVMV4qtgDGdzyKbce7KPuAN+uAn3O+M
lsg8hCdkfTioWI3dtKi3LQsfd+PqmmSe1fM2a0R9Ro8417NanqNtTYw1VmMQ
ecHYX3+cHK6Szrv8knrdxvDAvPhhgQJvwkPccWyG1ml2giLbsBxnG9jJJU98
U+VDidHeOHducWwMLgERMnvkzS49ms0s/7xEK3APOfY+iPtEBjZcDMqosVIp
OaIbVzcUhqvFlzTu5rnafTt9wXWhkBpjq3gO1riHKMVqTlCE5ANrSLhae5VK
GmWRaT1jbwCbRNz/xMVqPcWyzz3yFy8GLAPrFAT2pvMFqaIsvzh1mviFcTW3
xHylWYH49kj+cD2lWG3e9MOFcjZS2NBg3G2FEh5Xx4wi7UoNeD4YA4kGew1L
aJX8MhPFHHkyTtwFLBloBEnbsSJ91/OhPR/kv3ANM42zanSzWUfdDcPStzDm
iQw841SbIFTBYPUudMylkL3aRMIZ9s/HVMEiLrLoBMOIIChT26FIUTW2dqJr
OHZQII4hiFvNpqrSXJwbL9l+tpWb8VE3q5lGvu3AmeQ9jEw6XwA7z9GdiSXn
H3hOTbPJvUoQY0XQgt1KI2QqkbLp0zXFBYLCmnIG+HSytWR88EURdVuauIc0
x9i9Dtftk+PFY9xD1znkAFi2FMCmwYTmgC3CaiixkFZhSILBTIgeTi/sGfof
Psg1Gei1O5ccnKDi1DVSCfBQtslliRQBRlUKz/i+cmkEsrOAhv0KhSNwwdSq
knyvAC52C3g4uamsMwYPatpxnmcFuVxsKwbghC1nOQXL6OzYITPhchQOFcOV
977K1gHVyFSBjoumvsc/17vMpuw4tgp8BZnX8Wj0l7/8BZ6bZxkYTc0Iry79
5E94B5e7DOizRvqf/T994YCPH92Aryaf8/PxY/TnV274x14Pp+H3xX8Gwz/n
50/724d31v8VfT7d/tMZ/pGudcWyMuyJMeX1TIm/RpFB+ekPj1f2q1//+te/
mW7dSHc4L37/T/Hi7QO9rXWHyy/xIqbhA5fLAngubAz//NzhgyDtD+fH/rTf
XTx8Zat/8cUftyz+I94PzTnC9FgwPALpFtBtg/zg4rdB/v8abR7+2f9T/88v
GN6llo/R8E8SbIdW6c+vtjOIG8m8p74Ykwm+Dv4bvP2L3/xVf+jHB7wg4Z4/
Dg39xI9wh+GhwZppWcNHOzg0YA30AHOF8IeH3jTptDeU+4UkjJi/mfaYCQ9F
kA8umFjCV/JgZxd2wfasHiLpKX/u2MDHZOt2B4ZGr31gaMAJ7Jo/Oh4ADOCr
7UMDLvDRDfXAS5KHhnaB3D3tTyz4y7HiM4SlP7l46MDPg5S3fejQIiKat2S4
bYKPsU9HXhc+IMS4fYK+sP/CCfo/kZC3NP3ABJ93hg9M8Hn0/eAEn0Pln9zC
p2j9k0D8FLl/2QQDRP/JLXyK9B8E4ucwgC86hSE28P8MkT5Pf0ZqROtgNDr3
mVWSfTNwkVqQHiDtRrMSRabZkoXCtRI20zPIp+CEMLlDxV2dZf1ycZZOr2DO
JpUMJeNMrZc/SN0Jvb1DmYZDV5qFd8AMpH35bHQqUqFUNGNCS9J7AbjMMwjp
2vsW4vSKoLmHc7zZSsVuVqwkfgRXo2xpZ9G5IyHIaYhTEChqFiRmfh6Y0E8Q
nN9QCX/YZJ28BVlwMcE06sPPxi5Z1QpTIn+ydrO94tEayjGa+Rs/PplW5qpU
59jaLtm5lZqvN3qNzdFqf10i9yq/rjGXmDO6Lrme0z/iU/kGs6scoF3p+RBE
yHdU+6Qm3r9rYLxzHkZxoqtTgnW4+y4vNUy2ib56oe+BRrDtxwvV5s3ktsJr
Gsumuw83x6nLhnVPUKDJ95uVkBO13aGOMWH0vZMGtNCqsdfvkZd3IGgTXORH
XhpK4manR0C82+JZ7CgZKL50yUZBvqosqo3uJarl9A13pAq5yoBR0PXXaes3
ow4KKwUI57uxdHwQ3CPLJquMJTLsUrIi+um0M3Otg61zb4ApIbP0LcIGOrGP
nQN8EC7AywEUJUbKfZ1sv6M4xgHJCWm9+8m3nNu88vVQQVlcXKi1g7pMFqgj
Oy7jlL1V4t4ishOK4Q5pXTe9a0/DaYJ8hZbtSiHspOvxJN9ksDbqYmAzH4PU
ddu1mLzNVUNxM9+1gVs72ZmjHtWWFe1y5NpFSvlPdi+6xAmp/99d8N2/GIqw
fdqQfdNzkj8jbRFcHX/wzrAzE+IjoLVrojcPLw5yFyA6x1IaZ7X1ElbDrPFO
BzSfRE6uaUsSgvcu+tVNS5DMSRFGUSrnFsc/pbtl86zJN7H64eqGe+KzszbM
HNSSkZMscnXHOeyS6HdyISXOFPKCl9VS/GTrREKm7jpN2GbrzOp9WXWQExH2
N2C5T6zLMbtIxPYbfXUTNqPkb9cZdLYJ4dONnxqDHZQ6mWdRoDRYr0QCe4EK
y959ta8wqUxKVjBiyZzbqTSVvRQh0lDim/NEa+glrtiLPSkiE9zHFkgV5QK8
UZN7PC15GaYZmDiJM9rUTCOhxhl2pH/ETeDwflfpnde7eOHCBwwRgezd3kZi
nS6T/fb5dVJRnZvTBJBzc2p92Yd3dM9sntvoHmw6TpQKcidmfAkeQha4gy47
+ThBaLNzpSfmvirLpZJd23nfcYhxWHCx5yfzQ06uL0zIzPyK9qLqpriEaRVc
h7DxYabODYKB2r6F4XW6/tFR/YIQ5w22qsJ+ZYN9XfhiWHcrK10c+mOrJVZG
qcZ0W6dp577UzwVYwppoSoaecDK078ouZXYWp7d3N3NRHJ/F51rBdRNM5ZIq
17uMpfGxbcnUFaz8fZCjTgJRelvE3cs6SYpOINg+7XEFQ1Vz44ggP8kW1WxV
m1zjKC98ZHl066JdlS+aJRlL4smfvJvEKScyR18AefEcNzOLe4g1n1j12CoI
XnhGaqjr1z9319cJw3JlfDVqSoLoIvX6gquSzpjULxJ2u/TB/wCbfLss2ys1
Fsku9Rs7LXXaKQaQ9d213KXEOABnkNZDYbOXDuqGel1QTTWci+VacAr2DakY
W7XkoatoHjopC9WeJE1t6gcet8M+6gE9SDGS1iKpVSQUsCjMXd3rbqoLY8qS
RBSU0Y9tPl3EIeI+iK4UuJAYeFdTG8D1SmrysWRLGip3r0l2NoJrugOogMpN
0NPMZ3cSpgR9I8bDSXjREbNni0pVnCB37LoaSJN0msEW7jbAuW82JTwIp5ic
B40ZR6Oz1qUOalXTFS/K7QR7gCxs65hxv/cOV9O7qzrdDu2DYWdl1FfWYTsC
2JIkxa/QVKo5jQTbKgFTNMI5bR6NOxSge7mGwIRtCJu65QSV4OJQpnpJM6VL
McN7O+4U3dOowxoPkvJVIOYn9lcr11Ug/oNebWCn6fcNdUyxieRhgnvAdow7
ByzUn2G2J+dmcDKONYvIUCvoEhJxmoUFhH2luFm1huvkfRVp0ArBQ0UEEnY5
MfZ+HcoU9jcP+xuBsaDfFR04L5JtUUTN/asi8xoysSN7u7j3D3HOWe9KxNpe
sV7KHev+zjLH8F1iVpQtAlQMFmBYbCSure9end1iEkyvogNbS/j8/E6NXae0
KDnLlniTXXILgj7ZfQ1z7jEXs0SprMZLeXTU1Cy4giS4TLQnP7NYzQ0zekrX
6YFUPsd/eiptmAYTFXZiTyhJe9KYYKTT7n3lpHBZJxKp/i75Dju1wU6Dy+EC
eP79b841bdcZ5KUNLbLjPQzLT+VSjZLewpp8hKDukO9UsYaHsKFzsH6vpeJ6
Pb3Z8lvJ6JVkyqCFJiVRi5EpcyKjBOYp7ZBOozq62PLAVaPtgQlOBFxXGtK/
RG7bIbsbzq095i5Ojgv4otvn5RI36pYdqf0otYIks6qbrySVAXGD1ttu0IAa
d1FNb6cnoBWetl+ls3IsHffskYb6Cayi24bstR91VREbD3Q5TyZ8kWfv2lnL
f7q1Xj6FzS4l1KOiu1IHcs5NR4UOtuH7WvfW0GkibT/2TgDf8CrQulnAcwSE
26RsuPdZrhrfsx/diJo65XO9T3gRCixzMpkATc7fUY36/F1Z3QNhL1l8fzhm
nqnTX+8sgKPrnZ87dzdnQfGL6LO11EZiDZNPzz9/m/wOO+DAc+ctHg0e0A+o
FL2+eXWd7FI3muTw4PDw8PHB40d7cuHQGuG+St6+uji9ciOurs9f3Zyf2kG3
NxeTgyePDg4OJkcHR4eTJwd7nt9dqrTOUmHB//zrfz+9dNPsdlc4Bhb9vvlW
mnNVJX7Cr7h+c/tmcnr4zfTi0OV+s56F2cqpQk4orxqjcwF9o5gFCBCdZ9T1
/tRVbioQjmZvOvo/S1XfJUWgAAA=

-->

</rfc>
