<?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.1 (Ruby 2.6.10) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-lopez-qirg-qi-multiplane-arch-00" category="info" consensus="true" submissionType="IRTF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.18.2 -->
  <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-00"/>
    <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="2023" month="October" day="22"/>
    <area>IRTF</area>
    <workgroup>Quantum Internet Research Group</workgroup>
    <keyword>quantum</keyword>
    <keyword>architecture</keyword>
    <keyword>QKD</keyword>
    <keyword>CLAS</keyword>
    <abstract>
      <?line 136?>

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

<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="a-qkd-multi-plane-architecture">
      <name>A QKD Multi-Plane Architecture</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>Applying these principles, QKD infrastructures are 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 this interactions may incorporate a layered approach.</t>
      <t>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>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.</t>
      <t>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 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>
    <section anchor="introducing-clas-for-quantum-networks">
      <name>Introducing CLAS for Quantum Networks</name>
      <t>The Cooperating Layered Architecture for Software-Defined Networking (CLAS) <xref target="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.).</t>
      <t>A new extension of the CLAS architecture <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. 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.</t>
      <section anchor="clas-strata-for-quantum-networks">
        <name>CLAS Strata for Quantum Networks</name>
        <t>Following the CLAS philosophy, as proposed in its recent update <xref target="CLASEVO"/> of decoupling services, additional function, 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 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.</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.</t>
          </li>
          <li>
            <t>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.</t>
          </li>
        </ul>
        <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 enhancing the current QKD approach by:</t>
        <ul spacing="normal">
          <li>
            <t>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 <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>
          </li>
          <li>
            <t>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.</t>
          </li>
          <li>
            <t>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.</t>
          </li>
        </ul>
      </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>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This sections is TBP, 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>
      <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="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="10" month="July" year="2023"/>
            <abstract>
              <t>   This document proposes an extension to the Cooperating Layered
   Architecture for Software-Defined Networking (SDN) by including
   compute resources and telemetry data processing capabilities.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-contreras-coinrg-clas-evolution-01"/>
        </reference>
      </references>
    </references>
    <?line 322?>

<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:
H4sIAH5YNWUAA71d63LcyHX+P0/Rof+Q2blRt5Vo78YURcm0RZESqXVtZVOu
HqBnpi0MMEIDQ40uLr9DXsC/UpUffgn7TfwkOZe+YmYoblwJnVqRAPp27uc7
B8hgMOg1uinUkdg7Fudt0ehlIUsljutsrhuVNW2txGVdLSsjCzGtatHMlXjd
yrJpF+KsbFRdqmavJyeTWq1glvd6sPDTDCRMs9fLZKNmVb0+ErqcVr28ykq5
gCXzWk6bQVEt1cfBe13PBpuDB+Nxz7SThTZGV2WzXsKwszfXz3tlu5io+qiX
w9xHvawqjSpNa45EU7eqBzu535O1krAjfHyvd1PV72Z11S7hSnf74o0yClcT
L/CJvd47tYbn86OeGIj3/DD+KiOi4N+vf/cM/zl5eXzVW6myhY0IcedFhODj
7G3eWEhdEC3r2a913UyHVT3D6/gUXJ83zdIcjUb4GO1ppYZa8WMjvDCa1NWN
USOcYIQDZ7qZtxMYmtf3iN6jbXwSogBqmiZawj0/5BmGutoycnQHRg7nzaIA
OWmbeVUTYVkGnmkQDfESh8L6Ak4gS/1RNsDtI3GtCjWtSp1JvKcsWXIcMqyH
tN6vG//MMKsWe2HmH3SmgPbiXNaNLjcnf3t5Hs+64seHC3r81+1yMVQmmu4p
HCWTu3Z6dv7s9Fi8Ug3KmYnnndA4u1m9yJW03HQTv2y1EedDcQLyXatamrvS
oYCBCz1rVQEnt2MXba2LotqgSq+s6gXMtkIZffP85PHDJ98e9VAdw+XX19dn
9w5Rhp1JcDJ8rbJ5WRXVTCsDOkw2APcEUy9aXAS3aUDU89Y09ZpE1TF6Nz/c
jd/CKuJS5XUlnta6qaJbJ7JeqFKcmqzWE1nGt2CarBLnqszmqml0Mgj2V2uw
Yr9HdY3uHJd5rW6Ah3UeXX2uCv1B/B5MjCqSBZpmrqURL9ryXXLnUrYFrKnE
C7nSM9Dt6N4ruVKqlOIF/GcdXb8o9EqrWrwEAlSgGukhi8qI44kqQFaS7TbA
QjikLD/KQpd6y71LaZqqHlwC8wtlUnLDDS+v2/WNrCcwoFiLe+N7h8h6Wc8U
WABnANTyj9YCNk4I1kOzBPLOFLgFVaJ8jZClGaw/OhwPDw8fjGlYMzIPxg/H
3w5gZrDjh+PHgyckfE/uPxijvL09uQLNGTwboo2zhoPXGmhrNQetUYNMGjza
67PLq3v3tsmnt7HgqZoqqwpx1cjs3ZGQoFWLZa3m4BxAyMVVW6/UDvn8rQIf
Axp+VhR6U9SANxVwCrRqquWdeTRThRRXsoZ9yCzTctlWJKpM9+N21jZI+Htb
CH9zczM0mQb5VrmuwekQoe0VR/CRnJjRUuvR1eH9x08O7z1+dO/eGOZ7OO6J
H+8/HifUOrt+O7gGN4Raq8qclFb8OKTHvEsH1ydyDVqsJy09UFqbNhTP2zLD
SxAIxJ5wL5wHxKLYJUh4Ht20Q+DsCI4zuh68OT0Z8PI9cX787PXJ2b378X6v
52gs8lrnYGxMM1H5EbpccfXsFRtL4LMsc/E72DKQX84UHKtB+yRREPKWduuM
cpfpuoRg4YdhbI7o0m+Hl8PIDtG1l0NxUTd//+vHcOmNfWhw/vf/LnOV3rGm
Lp4UpACc49O2buVMhhvHQ7ylJqDFWka7eDZ8MRTHs1bm0TbOh2dDsDl19ve/
ysGJztP5VQOiES5d4pKFNOHKybBjSOnq6VA8q5byY5XM9kavpBmcVyarTBVv
d5vBsTveYVXubxEGrZT6sCyqGgMXpShwgbCwRQaCDbk3/vbek4c9cfr2zQWI
RVcoTlu0POA0nNCexH4IrMEUPCHEgRy97uPjMMsB3NBAZfR2QWav1LJRGEru
2mquIfSRxQAmxDB2PVTZUOEGJPwzUuVoWRUatNKMlN2WN2KJewSTFm9rgE+/
z8AYXF69fpWatUuwXWDMzI1uQM3KGYq0ndOrI/BCLMHRiaYid/x+IyTfZuOu
GrUEWwhe4DiXi9jGPcV1XsfW60UBD55DNKHq6OobuQBVE78Ds4ruKrZ2BZip
j2Du5hIkLFi5C/BDlr7b7Nwfq7YGk2KGcmlIDpZ1bQNitG5A9axhtzK+P7qc
r80btXIR8/DBcPzg/vjRAxCV66uz8YOYinhFvLgikzGGW15a0F48i03cPjxy
8EswX8siyBCQcSqz2LqBtTZkrsc7zJtqjGZRhohipeoRXvjDzIxg/hE4wD+M
nzyBfx+MxveG40P4vz88Go9m5g9wG66uYOLD8eFyuMynfJ7D3ec5vMN5vDNE
IwlnkIKjPVFNxZvTq+sBWB2Vs8XnDa/F8eVZOPFzNQFzVaMWHz75p858CGc+
TM78/l0OV1d44vTMD3ef+eHXz+z8gucf5axX1bS5gXRQPFNTiAtzH6hv8V27
fPEdD/pwG3MPH25h7uPdB3389YNegPgrskmJuP5/H/dxl6903McpX189/2H8
aNtp4Qao5qMjt0EfYhhwoXXTQkBl+ID78OgBxC6FApkVD34ZO3wU74Qcv4zh
C4hWntdgoGj+q6XK9NQqeaDGM5V5H/CzCQI7i5T70WiMRikQBA8/frQaP4D/
OYIgYnD6wwUHvz53A3+hS4iBM/DaA7WqCmJ4r9cbDAbCmcJe71gg2gEigWev
1VTVGBEmIZlYVLDLnXCNgISzVu9bsNc5+o9lXc3A5lJqpxsj/Np9vLXSOfoG
sB6ejG5ijNJnVgTBqOClpTU6Rkg2p5NC4Rq66ROjIC2aFDgfPizzlcS927Ey
GGAj2DhVuKOhuJ7DlvlQc8jIYD6UCzNdw7haKQGbB2po4LU9FwoG+Eg504Vu
1n1hcAd4brcfmctl45ynPzDuxHnSTnKL+xFNlAjDpOAPpIYD2UXAX88F5kRC
rhCa4euUMPtxmWR7DFF4WS3oT2DKwjB14Px+tokisjv6WVIrXgV3DSvVdnM4
dhE0ApgAWQMIArE0a8GjwtUQyRM5XbyFTy8ryLDgPNkcpkpFyXO9H1hCzCpq
JfO1UB8am1xBRAdpNwmjxQhyBTHemhYBwqJts3sQaTDEB6gVwk853HNhmnGL
dQTttlmMqhHKMUPWm4XO80L1er9A6fdJAWgRPl0hUCAwvXQiuIfKZ4gtK+NE
YQ8lUxINSVllrtlK9WlMKYlQu0Xn0yeGVr58AS4bU0EiiOckRtJgWG0JkQ0t
CwkmUB5kfC4bJ82gfMZars6ZUTQmSrTIGNTKdGXQX2IsDNezkgwfnmEuIaiD
3DSwaUo0Z+LKcu0JvMO8dBYluUlXHoJJByMJs0OSYOk0q6sbjmZB4sFYI3M7
YS3c7pMJik0BqwbrKfCgRQ2K9Qv3vGHj+p52cNvDw7jkTgH3umba5bKqmy5t
SG1jS5HrKZGnia1emfMB0RujEF4hHWDLYK+XBqwXKMpEgYlo5Dv4L3EAlZFS
fDK5usyKNncmUudo2JzLorMmvg2RmEwvCyv9G1YKzEJOjP70ySIvKIV8MkwG
l25a0D61QvEAtpJKkNy+PbkiqUXFchIIvKkrif4WiVXItUI/QtbZkDw4XryK
mGraxULW+iM8SeGoNllrDGk7rkPQzpcvQ4TskAnkSfzJ2AspZB2YG7TukFqu
ZNESx1Dy4AwIvJcskNO2Zs2uIEWZVNZwQMIDRHUSh7twYr5Ez0pMVjUL61pg
/AQGgpgJCb5zlLQP3J6BtC+PhMc7VNyA86g2edtUMk/MVHLYIAX58TodgJjY
zjfSvItETtrYiQwLsLFO1GgoLngnvMgchvWdy6byjpUVXFJ6tjpm+7M77eWj
gV2ZN6RWseNlX1Y11icvQB4hIzQL9tzedm03l+BnWlDfqa5NY3mRV5YVqBmx
t5dIx8bYPTsKgeE0YEpRXuCIBl0tS92iAqujF6jcsHI6OeojHg5CgywDSWL1
L5XlKCtoSueJWlfWMjly+cP1rTdFQw42GJ5tblDtg3/BDW2aP++/+n5IEhY5
U9gZ2ReqycDanJUCPBXa96KfBgnoWoKD9kEEkVnAyjmKZdehtiTBW/mUWplI
OdC+ZmSlHT/skfqWFFMIPGwgcXuW06dgDw5T3cDjiZLighZBctrIA80SsyBS
CbacmNyi90O0BF2D9axGqUUnRCUfpUqy1i4m2HQsQ4EBeL1EZ7JpjJ0mffpE
8CvaTqY66gU8ESIifMahnl++sMbogqQ85cGnTxYGg6es+wBGKOcDC+/GQUDR
KKyVrK3PBHfvHTUcMId9rOjPaVugUwR1MqxyigwSkBrCVfSXiwkljiQmdt5w
OB2MUeJJycVgZQmPHdtNmeeUX+AuYW6w6R+s416kaVwc53ktjtQM3BvYTKds
6NaJTsa5bJRWuFqiL13BEqARO2JdKahAOeBy9444Z1cC1bekRPtfLSJOBBo5
Pb1N/zAgTrmNoXmYRaDELpaNYeZhLp+kYVaJ0wQIB0PgZZVy1oI1gF1TCKnk
AqOxNIjBTYbSToi1kLjo4kLc0TVDScKBuglW66jX+1dxzFnXESJQbBJs8spD
fUaDalRRTlOqm50xFNvQeJN0gBWaSLmqXHbaoCeCXbdLSi+JNsHLuug6NlpD
3OtVksMdIYBkNHIX3VuDQghKISA0Un5jEF7AJZLNRHFqNZM17UaVK11XpdV5
Cp4w6C/Q9wAZTBzk/VP54hQcmt1rmhbUCrScDnjpU8oj8Vxm+BtSnIymE4hO
enWrj0okOiSafZKPNfECvS2m1/jHBAN9Lx54NowvJ2vagAckrGchhT1GAaxp
psR0pGIOEQVOCoeHUCQzPh118bKLLBld//KFBPNticgNaJbDBOTG6TJyXxRy
ITZE2VAk+UTSa1ApQwlhxtN0wXmaxcwxhPSSt1C5liyWgb4+JSdRhCs++9+c
FQkSdIRWiPIUTK4QfZjasIWGwLSQ+IJIY97k9faZj0QNmkdFCDD2uxixd/72
6nqvz/+KVxf0+5vT12/P3pw+w9+vfnP88qX/pWefuPrNxduXz8JvYeTJxfn5
6atnPBiuiuRSb+/8+Mc9FuW9i8vrs4tXxy/3QlLkrLb0OSeZhWWtMH+Wpsc5
zISZ/fTk8m9/OXwATP8X8EP3Dg+fgMfkPx4ffvsA/riZq5JXq0pQWP4Tg8Ae
sBjcJtUOC/T+S6z5oFCDa5lXN6WAkJn06d+RMv9xJH41yZaHD763F/DAyUVH
s+Qi0WzzysZgJuKWS1uW8dRMrncone73+Mfkb0f36OKv/q1AXzM4fPxv3/dI
ho7JWVGD2OByo0OMxcjGWZTebQA/3agGI7tpZUM7CN2pnYuSahut+eyvgztt
GpStsUjHQcEgxB3NHCYCe+Wy60JPVQOxmdMbb5D2OdlXGD9BFKAOnL31oSsb
UAy2vdmEgAoDzD5HmCHVz1AB6xlZex4IOWwJ6iY5ZSUXABmxnM3Qh3Acy+VG
whmdS97EAuwGFJd3KOSzBRCKa2CsjYZgz2BzFwoMF46jFROY4thZb1jIqIT8
29iHGumNMaiSv5W7Q7HBjiAS2lCEhblc/0b5XBt07h2DnlULWi9qPdOQwW1J
rm5QH+GJmUYe0QNkEkmvXSbiUikX3OsFGWEgFxhOGMDDLNUMmJowguK6dAyK
qh3Tt2AyiB1CeFXDhJOd/JABB1XYpNgBAV2SLLCsiF7xRhXFILc1mygAggyA
qptkzrgwGH59GH597KAasp7JVhZynQRcmwn+kJXYhbrPq/rGRjOs7/uvn18e
CM2I8hwLJChIQEYsKjp9iiDp/Rho8R7vgBI3ILbN26ZhGauCbhhaAQykIQSn
mgE/D2FrYdvi7PKuEuLGgXRWbU0JdKEhpQ+P9ENjC5xbYHBWzpg5Q9B8lHPO
meGkcBecgGmpIZJ8Au3Wd8BgnBaXUKoJRpEEUJX5oKkGiqDoDDwVuVeZ1ZVN
gJxvZhQeIsKCYnWyCqCettV1Fzk8FPpBZT6GpyAlAMs+ShiKVxXFeiSrbZF7
UJRoySluiEbiaE5pQolWELNIb2byEM5EQDmCO6Uq9iLdFjZxojCU82iLYtmH
ybPaZIyc996Smh4GFSZIsNJeDDOGMI4YRedBQFf1dwgRkNwIp45OgcsqD+2L
nP3NqyXuSJfGJ8kVmGrKr13ZpNALDJlJqHVJm5YzL4FbxNVggG36rlI14VwK
kwokoKwbt0uQMwj0NBVMyJ7kVYmcpbR8hRhnhf5nLoupHwK2OJFCq7ZXbLjE
BeweNNvp7NUF6KwNE03MdE+kJJF1wj9Zd5BDFlWG33gebAIC59rvOKW+byVg
S4QONltnoL2RM7brY8BvHDzfLhiJ3qddJeA61iqauZ8ZbRYE6MxvxBN9kmcB
ngPkPOlImS8rXfIiieodFwGdismJmkiD4biMDFgIJeJg5sNpWdiaH0h3geHj
Aqjm8hb065YZ5Jx5Ol1uRv+Ei7UzxuOAY8FjQOiJSgvrS6rnu2NIH+L4wyNQ
aSLBYmzT+QDaphWVuHUuqqJbiTk5ZytPULCdzu+HXBzYNE6McpQslDtj00lK
LLukZvxF+cTcoZo+4arKqZ61DvSBWfctCHfgm1acdmsP9HA8Y3EKPE6BXlly
lkUz2eQZlAjRK5iOag/2KH4X0QwY9XP6pdWWdbpuHGmMu0WGOaPcQbPcxE7C
SJEwutrxXIKw1Fb/u2dsJIdIWDpv5MwT3J+Sj68bFwZhPBoDQSGIZt8dV+B9
KI0pPGIroIYudC0qMvZ2r8BRTdghC8WC0BdQgpwLaJNBBfq84AGBvxhpnm0L
nUjiPFE6Z8krYAjGh6H6aiOp4M6japEVn8IaMfYvm0XwlzvOg4oWg5ek/WRu
pBWHWKDCruPaVYqUbxG2wgaeyaU8CBlwX3P526Avcvg8tr46797vzqc+OGgz
ahBx0JvtnujwOVcc7tJWwBkzBMhqzoYvCuypsXaugbaQaHHZNcL1+uxCKEoe
EF7Wd8cZhLQJpbFdkoEMwu6dPj3AVQyuF653Zx9RUsVVm5JbEZBrSCY6r7XP
cNjgTzhGCjaZkyTHATpkzO8FxisYzdRko30gc5sZtST0jtcldjhdqIXFlcoq
7l9iFBgMzAiNS95yuElot27axrKYduHZO8Wki8WNi2GukuELeE21qz/B6UTf
QpiECbKkaNiiJqSvrVG6gDm/+IVvN/NA64n3af4VGPI1PonZBQPswMPEPp+v
SAA9iKcurl/1xQWYFnyacThEwNyqBxR0UdIdgQaYiHLlIE5rXbuJTQ5R9DAX
XbBvx+Um4MCPxDQFTX1I60PhDvS6n7YFsW5FiOGBhUq5iyZGxv2ZWxsUMzbM
5fJIhgKVbH8TPdNG4KaFK3ivt6Mmkdm1HUebRrPLtf3Qp8RxQEAuD8AMctTE
XJ2ufQMPC0KkAEkYR3AMmg0MwG7mOptzCFNlsAsEKNjmR2ZDOCsTMi5MtTrO
tXOXoheKNDCemqx01RrLiwVmcNz6NxRXFJYvOvCvUwvjUgyC2r0cRTlRqmH7
tnwM/K/XSw6Uue8Wou+gtWa9WChwaRlknDMwis0cgf6lwp4AUoNm/Y8//9cB
7gCdlPGBZyCvK1mB5ejv0K4Qj2ChllhuHAJSmyQ7qBDqKL0tsZUHEigIMEAi
lFw4hxvFSmC68HURa9oYY004B2tg72enMyDuPHJ75PIvG0tMFzBfJubaIrQ1
y8a1vK5s3+jHqEit37cotPYWMBW76tEEYFY76IxAXwCCQI0gwMF3iAciEoz1
dVArjd3pS6ovUoDmrGR8uqj8wwmhz1DQObB135UYyS2ZCazu+rIkw19g6zGA
cF7g/PjVBYbf2TtIlanbFpEgLHFzskZ9D8ArUzGSUi1tLcMqVRb5smg7Vr9c
qAUa0UTNbm6XPmbxUbCPwcPDnVAF/lGu8WKBjRcQzoKJ8yiPRSb4dNZrjcD2
R3Nwn4hVBQ4IEo+Y1BpdpYRQmMEWkC6at0uFtBVtW72PaksOONsx0iIvtuLn
QDKUUA67tI3CvFfBlzt8soFHtzAGKRmY15QaVECip+6+fNx/F+0iXidGoDqL
XdtwEcK5nEAy9QF1eYYDbbwbI4Ad5vEU8yi0jrVZlqHfNY/lJoQFVLGvOSjY
C9FTVe+h77Ns9y0pTjhWWt10gs9NbQt6EaWeQRec5aVEBFs6bGCZqSTQ31CP
LS/xOMp4iL+mYkMK3cK4bh7s8PIpqLSeYBmaW4+RMBjrAisUqTi+D48NBSD1
OnRLYmWSqolJbTLUGTaAQQvamViVMJqLvRTwgUEsUnXbPkNmoyisZXWzMIpm
C5kE0j59+vhBgPZwNCbz3MrgrZPrMMe3njqqgi0RDepuwNxcGAN/LXSpF5Ct
WTfJzDKpTaUZQ5JsxdU3kni/6mXaH52LrK67GOmK7f3bGiGNA2CsCsKjLy0K
f9xtO3HvcAw673DgoH1c4CButxGuEIqCidlPUgtLc7gkGeI6E/Ae3+EC6XE4
4hVetqobwmx7dSiwlRCxytBE2B1o3ahJcHPTDbpJQR3c7YsvPjGOAZmKdpxz
4xfifLK4W3vjxvapBanWRnU316nuUdA+tVVJ1MA0j48z/IA07qvhbBh69zD6
pE5Mm2mHO8gGe2KBYf2NXLsoAw0QtcTY3vpQDSDJ6vRc2ZdJvnz5218YtjAb
LVc2jE/6fhIbxMVMVy3DsNupuY7kGrdkOy4pLFzSW8htIWvn3wkjDZFyDNAg
0Vtu0IrZKpsGMX7uTwuVMSamTkxpVAiNWvlxHYVWHnR6kNdUDwxRX2jDPAaB
WWOrSB+UjQBrbCPBTLYo9IzM9/7x2YHN5ylCFC8hti5J485fUuUKok+Q2KTO
FZdVswLLGYMCFBxfvqwWrmfk2vEuNG85dA7LK7ZxOcngQ7XOFdei9rGZDO15
aIjjtkJCMFzEHlrJNlodN5vavAmPK7vIN9gDDvRNo2nXI8IFSAnMRNyuHEiK
5QqtitxWsS0wb4AIguruASLJc22binJw/Irt8xR+yatF1FrlkslZUncn/xCS
iURSVL1EEN5vfp8ac/KDbt5OzV2NSRA9m8MsKqo5c5zpitRU1XJ03tqDELqY
4tKrT6a4B8DJJ8hOm6MzQgn270x0jvpR1RVkszgkbLPvqm0dBeQqOtkEBCf5
/FzABY+YkwrfIE7FfRgoiSij9rXQ7e9IcCL2FRyJq8SsoirvvtHgq37sehyr
dM0JeKexiwEn0p0rfn67Y31OZ3Br0PPLuQZ9rCBM2Kg2aoJYqa2Vw9fUjlIb
iq9YhI7sSEid1+iH1y7ieKHf1RNbBe22m4UKD+oZba+achNl16ViAUyG3sZt
9ejUtzJi1y0kJ8YUBs68ISGw0TdUEZnDG1uG4bChOLblsUXFsufzSxeMRn7c
FpotPmBlOM13CWbQtvjOeE0oy6dfokgM28ZxMBkk1282a3bEf7Y36zKDJMN9
WqfvcRWsn4M1o1pITcVloDSn6s5LGxs+cCXdzW5BQfvyjHuWa5tUzOxzJ2Du
68J2SWrtwU1hr5UZDhFdQA579jKqAFJbU/k6jv8R26vIm/ZtvxWVRi00lW5C
cvIH+VHI6bovhyTJD8reljYQL4ZJAwiDAwRudQAex6G0rzfEzUk4RVlLXK4N
qgLkwdcb0K9jw557jzOq4FeIuNPr6wv/zgUX6G5UJNFoA2z1veMz6dAncbjv
D2vLbZktv4b3YV0qkiRFsaLhvm1bQSeT7nAykS8JMrdecuXSV3jCvlIZnKi0
TolZS+rV+tTBMdUTrjeNQLYRVB7waxK0RZYgnpA9QdStEa+NaVauZ0AUB2hx
kU1kus5a3VjHga8/cS+Hg+CVK425QDQlURD6zf2nGLEUnbXCljZeUkCG2SA4
epdOIhP3vGjSPs1e1GASV+V2kZ06+6glHzsANvFRb59DBj1XMrfgKjl8uzII
3tO4uVEvwDSGXhRInVtuBLQFdnKAsSOL3BbtPHkFw1om9s5zvbRYVzRVpBxo
3YNY+b5XG8hNvXvNtYSAZAE+6k9/+hM8l2k9AK3q4ZfJvvoTf2LDv+t/p5Hh
Z/TTzxzw+bMf8M3gLj+fPyd/fuOHf95Ic7evl/4ZDb/Lz0+j3cM7+/+Grg93
/3SGf6avtmGJATuEhryfIQEGSSJkfzaHpzv71Xfffff9cOdBusN586Of0s27
BzaO1h1uf0k3MYwfOJ8tINCFg+Gfdx2+laSbw/mxn0bdzcMtVwnGhT/v2Pxn
/Pwj9SXyY9HwhKQ7SLeL8ls3v4vy/2uxuf1n9NPmnz9jeFdbPifDv6qwHV2l
P7/ZbSCuILjMwffih27EYIDLwX+j1X/2yt9sDv18S/gUn/nztqFf+bHWYfvQ
aM+0re2s3To0Mg30AFuF+IeHXjX5cGMo944JFszvhxvGhIciybdumEzCN/bB
zinchh2vblPpIV/3ZuCz2HncLUOTZW8ZGlkCt+fP3gaAAfhm99DICnz2QwPx
hLhtaJfIXW5/ZcM/Xyru4CwD59KhW35u1bzdQ7dtItF5p4a7JvicBvZ2ufgB
q4y7J9h09j9zgs2fxMk7nb5lgrvx8JYJ7qbft05wFy3/6hG+putfJeLX1P3n
TbBF6b96hK+p/q1EvIsB+Flc2GYG/s8E6W7xM2ojZge93mkAkvsMG235TFUE
jtqKjC7RZdq3cDq5ukOJ5rLMXGLn8kqqSbp+t8macLRLn7FTJ+XtOLMrQDP0
6gF4BjRgV2qJDYb03S3Lxs13rhDkVrgB46plL7goETVaRH0vaX/bHmqljhRr
z6WGNu+yiRpltxbM577P7jtdvumGqcEfEnG1dku3bhmQwIJob1Sb5Y82hNeS
oreNqNxbNQQDhFo0N6y5meOX2vwnGPYZvDEOZeE/gQNSl4iE2a910Bdl9qcq
5/aivu8+xZyanrNQny32uv7qeM243wxfWoPc37cGZ/HnE/xnoHyKlKfwdIzF
286qUO7p9HWG6g8BBA4fsoCZf3OoCwfbfj7Co842CkBOzG3lAFjvx6XLIaqv
LB4opoVccT3JgvDHZ/4NeywKflgSRkLdLb4A7pactqSoUb9fhOyFvlF6b1bP
qOUpwB9JvXGzA7FbO4kKL3j+0w/IId0gszo4jjHY0NXBuxPAJtolg0yuuhO1
VkRfUqOSsQdxZVz0D4jfBnbvvjRGKHH0gZioYCM9dJQUl9EQ2k/XYPuTSQsj
iY2c4JfG6xSpJwQn7TKdVaAR3Jy78ZZo/C2FMno9zH4cw7gvT10/vRT4DmvU
5YIWkqH6crOiEX0a7kYXhf8+j3Sfd7JNRlH334S/yoOUBUVVZQcdjnba+cYY
1pOkMxhin3ocUDOdsvbjouVBmCwMgbjTxHYl7OggabihYgG+iumAZF+vXrOp
Jc+VftIogn932J5OWzGySlwp0Gic9iQp3KVsoWoacKbvtrP5FvAu/vrPUDkZ
9V+3SQuFySfCbEMJtSgnpMAG++hrWlUXGLTYfdoVdx2snW2HBKq0/A23FsaX
jTuHs8KuSchz3qndBo+4T2GevNcIsjCvwDbWVUWfCGiiLiH/YRT+2sLGt0Go
FeHdZo9K6HJwW4ndd/JBiy0Iv4sCHDViA+SbiTf20OncdZeDqQv9mlWpm4r6
uazdosISt3xhPxh2sRSyCS9KYJSj6PUEbhmW7cw31NqvJk5gNXrtP3tXVjeF
yukJ0/t0xC/qq/y7vaksjNr70vnAjo6+3Ml9Dkg+jhBaejnDkur0rfgNbPsj
PMff80YG/RFN6OurV5dif4aOSByOD/H/n8CD+we2zWiJdJ+Lt6/OTi78iIvL
01dXpyduEEQng/Gj++PxeIAfox88Gh+EjgD+orwFaP7x5/88OffT7Hd32Bev
1IfmhS9f4hVe4vLN9ZvByeG3w7NDWwHmMScVFsRziSU5u1QfQ1AM3RBuB4pm
ml41OKl8J3OtpTkY9v4HV93T741nAAA=

-->

</rfc>
