Re: [Qirg] Common control plane for QKD and entanglement networks

["Diego R. Lopez" <[e-mail]>]

Hi Joaquin

Glad to see we are in sync in this architectural view, and in the applicability of SDN principles for quantum communications. Just as a note, let me remark I believe we should go for a flexible interpretation of these SDN principles, aligned with the IETF view, allowing for fully centralized approaches (a-la-OpenFlow), as well as more distributed solutions, as devised by works such as ForCES and I2RS.

Be goode,

--
“Esta vez no fallaremos, Doctor Infierno”

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/dr2lopez/

e-mail: [e-mail]<mailto:[e-mail]>
Mobile: [phone]
---------------------------------

On 5/5/23, 20:43, <[e-mail]> wrote:

Hi Diego,

Thanks for the great summary, I definitely need to read the ETSI QKD documents so I can contribute better to this discussion. I just wanted to highlight two pieces of work from my group about points you made:
·         Regarding using planes to reason about a quantum network architecture, we proposed a similar approach for a metropolitan scale network https://ieeexplore.ieee.org/document/9946408
·         Regarding the entanglement management service (EMS), we consider a similar entity in the architecture of our SeQUeNCe network simulator (which is based on an early draft of QIRG RFC) https://iopscience.iop.org/article/10.1088/2058-9565/ac22f6
Definitely there are many architectural principles from SDN that can be applied to quantum networks.

Regards,

Joaquin


________________________________
From: Qirg <[e-mail]> on behalf of Diego R. Lopez <[e-mail]>
Sent: Friday, May 5, 2023 12:41 PM
To: [e-mail] <[e-mail]>
Subject: Re: [Qirg] Common control plane for QKD and entanglement networks


Hi,



Let me chime on this, as I feel somehow guilty for drawing Wojtek’s attention to what ETSI QKD is doing, and the potential application of its results to an architectural proposal for the Quantum Internet.



Let me start saying I share Wojtek’s concern about the maturity stage of the technology when it comes to going in such detail as the one currently provided in the different ETSI QKD documents. I find the race for transforming any research result in part of a standard a trend that is threatening both the research activity and the applicability of standards in the future. But I believe there are several architectural principles that can be incorporated in the analysis of the future Quantum Internet, that I understand is what we mainly intend to do in QIRG.



The ETSI QKD set of standards is based on a clear separation of concerns principle, that I would refrain to call “layering” because we don’t know how many layers we should be talking about yet, and therefore I’d prefer to talk about *planes*, each one with the layers that are required as the technology evolves, and we gain sufficient operational experience to standardize them. The ETSI QKD approach is based on two these planes: a “quantum forwarding plane”, dealing with the quantum mechanisms (the QKD algorithms) involved, and a “service plane”, dealing with the service provided by quantum forwarding (key distribution).



Following this analogy, in the case of the general Quantum Internet we could talk of a quantum forwarding plane dealing with the mechanisms supporting entanglement forwarding, and a service plane dealing with qubit distribution. Interfaces equivalent to those defined by ETSI QKD 015 (the North-bound interface of the service plane) and ETSI QKD 018 (the interface for coordinating services planes among one another or with other network infrastructures) would be considered.



And the transposition of the element acting as the core of the service plane, interacting with the quantum forwarding plane, the KMS (Key Management System) in QKD, can be considered as well, as something we could call an EMS (Entanglement Management System), in charge of keeping the logical connection between the service unit (qubits) and the forwarding mechanisms (entanglement status). This EMS would be responsible of creating and managing the “sessions” proposed by Bruno, keeping track of how the forwarding mechanisms (like entanglement swapping) are applied. We can think of an EMS logically centralized, as a controller in SDN, and/or distributed, such control processes in routers. Again, interfaces for the interaction of these EMSes with user applications (as in the case of ETSI QKD 004 or ETSI QKD 014) and with the quantum forwarding plane (as analyzed in ETSI QKD 003) would be considered.



These could be the foundations for an architectural analysis of the Quantum Internet based on the experience gained from deploying and operating QKD infrastructures.



Be goode,



--

“Esta vez no fallaremos, Doctor Infierno”



Dr Diego R. Lopez

Telefonica I+D

https://www.linkedin.com/dr2lopez/



e-mail: [e-mail]<mailto:[e-mail]>

Mobile: [phone]

---------------------------------



On 3/5/23, 18:06, <[e-mail]> wrote:



Hi Bruno, Hi QIRG,



Thanks for your e-mail. It’s great to see someone else has already put some thought into this!



However, since the response to my e-mail has been rather small, I’m not convinced that a working subgroup might be best. I think that for now rather than doing that, perhaps it might be better to encourage smaller, but more targeted discussions on individual topics.



With regards to your question on ETSI 014 I would indeed keep the discussion separate since it must tackle wildly different problems. I think a first step would be to first produce a few concrete and non-trivial examples of applications that we would want to support. For example, I don’t think I’ve ever seen a QNE/NetQASM application that exceeds 1-2 qubits being used at a time (although I haven’t checked lately so my info may be out of date). They’re sufficient to build some proof-of-concept interfaces that work on a small scale, but I’m not sure these examples are big enough to fully understand the problem. QKD can have a reasonably stable application interface, because we understand how we want to use encryption keys much better than how we want to use entanglement. And then there’s the problem of quantum memory lifetimes. QKD keys have “infinite memory lifetime” while entangled pairs do not. Even with the current NetQASM/QNE I’m not sure there is enough understanding on how best to account for memory lifetimes in more complex network applications (i.e. > 1-2 entangled pairs per iteration). And then I keep asking myself, do we even want to address these problems at this stage of technology? Or should we just wait for memory lifetimes to improve since even with a perfect interface, there is no device today that could execute a meaningful application?



Wojtek





From: Bruno Rijsman <[e-mail]>
Sent: dinsdag 25 april 2023 17:20
To: Wojciech Kozlowski <[e-mail]>
Cc: [e-mail]
Subject: Re: [Qirg] Common control plane for QKD and entanglement networks



Hi Woj,

I completely agree with your observation that it makes a lot of sense to explore the idea of generalizing the existing ETSI QKD YANG data models for SDN control (ETSI QKD 015<https://urldefense.com/v3/__https:/www.etsi.org/deliver/etsi_gs/QKD/001_099/015/02.01.01_60/gs_QKD015v020101p.pdf__;!!PAKc-5URQlI!82e-rvvOohKFmTzvof5aTV8cRCSDmil9_K2MgGxhdwqtasjwkC90JlhHKoY1fGRmnomVsC_TPulxKWkGQp9kfUEnXhAn$>) and orchestration (ETSI QKD 018<https://urldefense.com/v3/__https:/www.etsi.org/deliver/etsi_gs/QKD/001_099/018/01.01.01_60/gs_qkd018v010101p.pdf__;!!PAKc-5URQlI!82e-rvvOohKFmTzvof5aTV8cRCSDmil9_K2MgGxhdwqtasjwkC90JlhHKoY1fGRmnomVsC_TPulxKWkGQp9kfQ9p0gHU$>) beyond QKD towards general-purpose entanglement-generating quantum networks.

I would be very much interested in participating in a working subgroup on this topic.

On the SDN control side, the ETSI QKD 015 YANG data model<https://urldefense.com/v3/__https:/forge.etsi.org/rep/qkd/gs015-ctrl-int-sdn/-/blob/master/etsi-qkd-sdn-node.yang__;!!PAKc-5URQlI!82e-rvvOohKFmTzvof5aTV8cRCSDmil9_K2MgGxhdwqtasjwkC90JlhHKoY1fGRmnomVsC_TPulxKWkGQp9kfbcwueQb$> includes the concept of a qkd_link to model a point-to-point key distribution session.

And it includes the concept of a virtual_link_spec to model a (trusted) relay node in a multi-hop key distribution session.

( I am not a particular fan of using the word "link" here; I would have much preferred "session", but I digress. )

I can see how 015's very narrow concept of a key distribution session, assuming trusted relay nodes, could be generalized in a rather straight-forward manner to:

(a) A slightly broader concept of a key distribution session that does not assume trusted relay nodes but also allows for quantum repeaters or quantum routers, and

(b) A much broader concept of an entanglement distribution session that could be used not just for quantum key distribution but also for other applications such as clustered or distributed quantum computing and sensing.

On the orchestration side, the ETSI QKD 018 YANG data model<https://urldefense.com/v3/__https:/forge.etsi.org/rep/qkd/gs015-ctrl-int-sdn/-/blob/master/etsi-qkd-sdn-node.yang__;!!PAKc-5URQlI!82e-rvvOohKFmTzvof5aTV8cRCSDmil9_K2MgGxhdwqtasjwkC90JlhHKoY1fGRmnomVsC_TPulxKWkGQp9kfbcwueQb$> could be similarly generalized.

Probably, fewer changes are need in 018 because it (a) it operates at a higher level of abstraction and (b) the need to orchestrate across multiple domains (quantum and OTN) really does not depend very much on the particular use case (key distribution or clustered quantum computing).

Perhaps it is too much of a stretch, but we could also have a look at the quantum network to application interface.

Currently, ETSI QKD 014<https://urldefense.com/v3/__https:/www.etsi.org/deliver/etsi_gs/QKD/001_099/014/01.01.01_60/gs_qkd014v010101p.pdf__;!!PAKc-5URQlI!82e-rvvOohKFmTzvof5aTV8cRCSDmil9_K2MgGxhdwqtasjwkC90JlhHKoY1fGRmnomVsC_TPulxKWkGQp9kfWDBZOXx$> defines the interface for QKD nodes (KMS's really) to deliver keys to encryptors (SAEs).

What would the interface look like for a general-purpose entanglement-generating quantum network to deliver a stream of entanglements to the quantum applications?

In other words, what would be the "socket" of a quantum network? I know that this is something you are also looking into (QNE and NetQASM).

Clearly, such a "quantum network entanglement socket" would not be a straight-forward generalization of 014; it would be a completely different beast. So perhaps, we should keep this conversation separate from the control/orchestration conversation.

-- Bruno



PS 1: As you know, I am intimately familiar with classical SDN controllers, orchestrators, YANG/NETCONF/RESTCONF as well as QKD systems, QKD protocols and the ETSI QKD standards.

PS 2: Apologies for the “plug” but as pure coincidence would have it, I am already scheduled to do a (free) seminar<https://urldefense.com/v3/__https:/www.brighttalk.com/webcast/19861/578474__;!!PAKc-5URQlI!82e-rvvOohKFmTzvof5aTV8cRCSDmil9_K2MgGxhdwqtasjwkC90JlhHKoY1fGRmnomVsC_TPulxKWkGQp9kfSkmJiB6$> on May 4th which covers this exact topic (the slides are already done). In the second half of that seminar I introduce the ETSI QKD 014/015/018 standards and in the final slides I talk bring up the prospect of generalizing the ETSI standards to entanglement-generating networks. I'd be happy to present the relevant subset of this deck if you end up scheduling a subgroup meeting for this topic.



On Apr 25, 2023, at 2:05 AM, Wojciech Kozlowski <W.Kozlowski=[e-mail]<mailto:W.Kozlowski=[e-mail]>> wrote:



Dear QIRG,

<with my individual hat on, chair hat off>



At the QIRG we focus on networks beyond QKD, but it is a growing likelihood that quantum entanglement networks will not be deployed from scratch, but likely be an evolution of the earlier QKD networks.



At the physical layer, things will be very different even if both technologies share the fact that they send photons down optical fibres. There is not much discussion to be had over here, also since this is not the domain of expertise of QIRG members.



However, at the control and orchestration layer, the story is quite different. It is likely that at some point, we will want to support both generations at the same time. Therefore, a common control plane for QKD and entanglement networks will likely have to be a thing at some point in the future.



A good starting point for such a discussion would be the ongoing ETSI QKD standardisation work: https://www.etsi.org/committee/qkd<https://urldefense.com/v3/__https:/www.etsi.org/committee/qkd__;!!PAKc-5URQlI!82e-rvvOohKFmTzvof5aTV8cRCSDmil9_K2MgGxhdwqtasjwkC90JlhHKoY1fGRmnomVsC_TPulxKWkGQp9kfVEGWRZo$>. This could be used to define a high-level architecture by defining the elements of a shared control plane. This can be followed by examining what what changes would be needed to the various interfaces involved in such a control plane (e.g. the control interface [https://www.etsi.org/deliver/etsi_gs/QKD/001_099/015/02.01.01_60/gs_QKD015v020101p.pdf<https://urldefense.com/v3/__https:/www.etsi.org/deliver/etsi_gs/QKD/001_099/015/02.01.01_60/gs_QKD015v020101p.pdf__;!!PAKc-5URQlI!82e-rvvOohKFmTzvof5aTV8cRCSDmil9_K2MgGxhdwqtasjwkC90JlhHKoY1fGRmnomVsC_TPulxKWkGQp9kfUEnXhAn$>] or the orchestration interface [https://www.etsi.org/deliver/etsi_gs/QKD/001_099/018/01.01.01_60/gs_QKD018v010101p.pdf<https://urldefense.com/v3/__https:/www.etsi.org/deliver/etsi_gs/QKD/001_099/018/01.01.01_60/gs_QKD018v010101p.pdf__;!!PAKc-5URQlI!82e-rvvOohKFmTzvof5aTV8cRCSDmil9_K2MgGxhdwqtasjwkC90JlhHKoY1fGRmnomVsC_TPulxKWkGQp9kfYcCw8D1$>]) in order to support entanglement based networks.



I was wondering if some people within the QIRG would like to explore this subject of a shared control plane? I’m not a control/orchestration/YANG expert so was wondering if people with that expertise are interested in the subject?



What are the QIRG’s thoughts on this? If there is interest in following this up, I’ll try and arrange a preliminary online meeting for anybody that’s interested. However, please note that it would be of great help if anybody interested would first read the two ETSI documents I linked above.



Thanks,

Wojtek

_______________________________________________
Qirg mailing list
[e-mail]<mailto:[e-mail]>
https://www.irtf.org/mailman/listinfo/qirg<https://urldefense.com/v3/__https:/www.irtf.org/mailman/listinfo/qirg__;!!PAKc-5URQlI!82e-rvvOohKFmTzvof5aTV8cRCSDmil9_K2MgGxhdwqtasjwkC90JlhHKoY1fGRmnomVsC_TPulxKWkGQp9kfTd1fPNX$>



________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
________________________________

Le informamos de que el responsable del tratamiento de sus datos es la entidad del Grupo Telefónica vinculada al remitente, con la finalidad de mantener el contacto profesional y gestionar la relación establecida con el destinatario o con la entidad a la que está vinculado. Puede contactar con el responsable del tratamiento y ejercitar sus derechos escribiendo a [e-mail]<mailto:[e-mail]>. Puede consultar información adicional sobre el tratamiento de sus datos en nuestra Política de Privacidad<https://www.telefonica.com/es/telefonica-politica-de-privacidad-de-terceros/>.

We inform you that the data controller is the Telefónica Group entity linked to the sender, for the purpose of maintaining professional contact and managing the relationship established with the recipient or with the entity to which it is linked. You may contact the data controller and exercise your rights by writing to [e-mail]<mailto:[e-mail]>. You may consult additional information on the processing of your data in our Privacy Policy<https://www.telefonica.com/en/wp-content/uploads/sites/5/2022/12/Telefonica-Third-data-subjects-Privacy-Policy.pdf>.

Informamos que o responsável pelo tratamento dos seus dados é a entidade do Grupo Telefónica vinculada ao remetente, a fim de manter o contato professional e administrar a relação estabelecida com o destinatário ou com a entidade à qual esteja vinculado. Você pode entrar em contato com o responsável do tratamento de dados e exercer os seus direitos escrevendo a [e-mail]<mailto:[e-mail]>. Você pode consultar informação adicional sobre o tratamento do seus dados na nossa Política de Privacidade<https://www.telefonica.com/es/politica-de-privacidade-de-terceiros/>.