Session Date/Time: 21 Jul 2026 12:00
[00:00:24] Wojciech Kozlowski: Okay. It's 2PM, so I will start on the clock. For those of you still not on Meetecho, please use the QR code to join or use the one that's at the entrance because I'm gonna start sharing slides in a moment. So while we wait for people to filter in, I'm gonna just show the standard note wall in the meantime. As usual reminder, this session is being recorded. Just wanna point out that since not so long ago, there's an IRTF code of conduct in addition to the IETF code of conduct and anti harassment procedures, all of which also apply to ROTF anyway. And the usual reminder that as a research group and the IRTF, we do not do standards. This is all about fostering research collaborations and conversations. Those again, one more reminder. That'd be the last one. If you're not still not signed up into Meeteco, please do so. You can do that from the agenda view. And, okay, let's get started. So welcome to the Quantum Internet Research Group meeting. Oh, I should have changed from Shenzhen to Vienna. Apologies for that. It's clear evidence I keep reusing the slides. Today, we actually have quite a packed agenda, so I'm gonna try and keep this short. I'm only gonna spend try to spend max five minutes on the initial at initial TVA. Then we have discussions about three drafts, two presentations, one about emulate infrastructure, one about the on QKD applications, and there's gonna be also one about standardization in the Euro QCI. Whilst we're not as our TF is not a standards body, we're next to the IETF, and Europe is very active in the Euro QCI. So I thought it'd be interesting to at least see what's going on in Europe and the European meeting. So, yeah, that's the agenda. Brief update on the status of the draft. Actually, we're the research groups tend to have quite a lot of about how they work, presentations or drafts. I think we're actually quite active on drafts, with two that are published, one that's currently actively adopted, and actually six individual drafts that are non expired, which is quite a lot. And three of them will be discussed today. So with that said, yeah, we can start, but I haven't seen our first speaker. Is Sarah available online or in the room?
[00:04:20] Rodney Van Meter: I was just looking at the list of participants. I don't see her logged in.
[00:04:24] Wojciech Kozlowski: Yeah. Yeah. Yeah.
[00:04:26] Rodney Van Meter: It's either was it going to be her or Marcello who are giving the talk today? Sarah.
[00:04:32] Wojciech Kozlowski: Okay. Well, then I assume she will be late. So we're gonna I'm gonna, in that case, swap one of the slots, and I will ask actually, no. No. No. Diego. Diego, you'll you'll stay stay where you are. It'll be held it's better actually if I just get Gadasi to come up now so that I can still have I have the times locked who goes when, and it helps me keep track of the time. So, Gadasi, you come up, and here's your pointer. I'm gonna show your slides.
[00:05:01] Gadasi: Great. That it's my first IITF, and I'm the first speaker.
[00:05:06] Wojciech Kozlowski: Good. And I'll set you a timer. Let me find it again. And
[00:05:13] Rodney Van Meter: you'll have to speak closer to the mic than you did just a minute ago for those of us online.
[00:05:17] Gadasi: Can you hear me now properly? Yep.
[00:05:20] Rodney Van Meter: Perfect. Yeah. So it's pretty good. Maintain exactly that, and you're good.
[00:05:23] Gadasi: Okay. Yeah. Thank you, everybody. So I'm here because I wanna talk about what can we do with quantum networks, so about applications of quantum networks.
[00:05:35] Wojciech Kozlowski: Oh, sorry. Yes. I have to. Yes. Try now.
[00:05:42] Gadasi: Yep. So when I discuss quantum networks, I'm referring to this network stage, like in any of these node capabilities defined at network stage based on the functionality. It's also recorded in RFC 9,583. So in Europe, we have two larger scale projects, one of them for the now quantum networks that we can commercially available that perform quantum key distribution. It's part of this Euro QCI. We will discuss about standardizations, processes there that are funded by the European Union. And at SURF, we participate with co founding of QDNL as well. And then, like I said in RFC ninety five eighty three, if you want more details, like, they discussed this having repeaters so we can do long distances, being able to generate entanglement. And the Quantum Internet Research Group here, I think, assumes quantum networks while we are on the entanglement stage. And then the holy grail is these, like, quantum computers connected through entangled links. And the Quantum Internet Alliance is another largest deployment in Europe that focuses on building this, like, small scale prototype, but entangled network. But what I want to get the outcomes or what we are learning from this KIA, like the Quantum Internet Alliance, is that the entanglement networks are a bit further away in the future. Like, we are not talking about five years, maybe not even ten. So I think there is value in looking at the infrastructure that we are building today and seeing if there is something else that we can do other than quantum key distribution with these, like, adapted QKD networks before we go to the memory stage of the networks, which is quite far. And so I will call this, like, between having QKD boxes and not having networks like the near term or the now infrastructure. You probably know already, but what is happening on the boxes we can buy mostly is that there is two parties that hold some secret bit strings that they locally compute, like, with some randomness. Then they encode this information like a bit string in a basis. Both of them are bit strings in a photon, and they send it through a quantum channel that then afterwards gets measured with respect to another secret bit string. And both, like, the input and the basis of one party is kept private, and the other party keeps their basis chosen private, and the outcomes when they measure the state also private. And then the QKD box is not only doing the quantum part of it, of creating photons and measuring, it's also doing classical post processing of these bit strings. So they share bits of pieces of these private bit strings, and the outcome is that you have two shared classical secret key that you can use for further cryptographic applications. This is there is no entanglement here, but it's still a quantum network. Instead of based on entanglement, it's based on the no cloning property, which is also explained in the RFC ninety five eighty three. Entanglement will be the same, only that the source is separated from the participating parties, and this source sends two photons that are entangled from the source, and the parties both measure, and they have some secret classical bit strings that they share to generate the secret, like, key for QKD. But the question is, so if these boxes, like, they don't have to do everything. They don't have to do both, like, the creating the photons and measuring and doing the whole post processing. That's just a classical task. Like, if we could do a different classical processing of these bit strings, could we have other applications? And then is it worth it to look at this using the current infrastructure and the current technology to build something else? What is there to gain? So I went of what I could find, conferences where people present in quantum communication tasks. And I try to find the ones that do not require memories. And I put it all online in GitLab. There is a page you can look, and it's differentiated on the type of hardware that they require. Of course, a lot of these works are theoretical, so they don't go extensively into the hardware. They might say it's QKD type. What that is, it's not super clear. But at least there is a document where we can start working on. These are all the primitives. There is a lot of them. Some of them, the POC, it's proof of concept. It means that you can talk about it, but it's not really a use case or an application until we have memories. It's more like an idea. And we have BB84, which is the most available one. If we had entanglement, some of them have multiple links. That means that maybe if we have different hardware, we have better properties. But we could still do it with a simple BB84 hardware, which is the simplest thing, creating photons. And modified QKD is when it's not super clear how much modification you need. But the website looks like Lik. I tried to define everything in layman terms. So at least what the concept is is readable and understandable for the general audience, I hope. Then there is some reference to the literature. There is the classical state of the art for Compare. So if you also know more about the classical state of the art, that would be great. You can make a push on GitLab or write me an email. There is the quantum advantage. It's also described clearly because sometimes it's difficult to really understand, is it worth it to use quantum? I mean, this quantum advantage doesn't tell you the cost of doing the operations. It's not, like, clear if it's worth it, but at least if we ignore the cost, is it worth it? And then the hardware requirements. I'm not a physicist, so maybe that's with the weakest point of this work. And then there is a table where everything is summarized. That's also nice if you just want to have a quick look. So from this website, what I found from the conferences and the literature that I could find, what I found the most interesting applications is these coordination games, Byzantine Agreement. I think it's also mentioned in the RFC 90 five-eighty three, randomized elections. And maybe with using quantum communications, you have most robustness or some sort of privacy in your coordination games. Like, you don't know what local values you are bringing to an averaging or something like that. There is some primitives that are novel that are not possible to do with classical communication. But we can do it when you have quantum networks, like position verification. So I think these ones are particularly interesting to look at. And then from SURF perspective, because we are like a national research and education network, what we find, or I find interesting, is these multi party computing environments where so I will it's like enhancing distributed computation using quantum networks. So I will explain a little bit more about that now. What is multi party computing? For who don't know, it's parties wanting to jointly compute a function without having to send their data to a different party. So maybe you don't yeah, your data is very private. You don't want to send it. You could encrypt it, but it would be extremely costly to take your whole data set, encrypt it, and send it to a third party. Like, we can do this with homomorphic encryption, but Okay. Let's see if we add a bit of communication between the parties. Can we reduce the cost and make it perform better? That's the idea. And also, maybe you don't trust the particular implementation that other parties are doing. Like, there is an open source software, and each person implements it the way they want. That's the idea. So we can do this classically, of course. But it's based on oblivious transfer, which is a building block that I will explain, that requires public key infrastructure. And as you might know already, public key infrastructure is threatened by quantum computers. We have post quantum cryptography. It's a way of solving it. But why multi party computing is interesting is because if you have a quantum communication, you can replace the public infrastructure for quantum communication. Of course, replacing and security with quantum, as we know now, it's not so simple because we do need to understand what is security for your photons instead of your computational cryptography. But The other reason why this is interesting is because if these parties, other than having quantum communication channels, they also have quantum computers, then we can perform jointly or distribute quantum operations. So it's an interesting application to see in the near term, like what are the benefits, what are the bottlenecks, the challenges, to then swap the nodes by quantum computers. And we already learned a lot, and we are ready for that phase. So it bridges the current technology with the future internet gap. In particular, how it bridges is what you need to perform a quantum multi party computing with quantum communication is the parties just need to be able to do this, like create a photon with secret information, measure the photon with secret information. And then the post processing classical part, what they do is they do oblivious transfer, like this building block I mentioned. I can say it's cryptographic term. I will explain it. You can read further. Like, there is two parties. Left, right.
[00:15:39] Wojciech Kozlowski: You have to be by the microphone on the one.
[00:15:40] Gadasi: Yeah, sorry. Left, right, Alice, Bob. So one of the parties, the sender
[00:15:45] Wojciech Kozlowski: There's a laser pointer in the thing.
[00:15:48] Gadasi: So one of the parties has a couple of messages, bit strings, and the other party chooses which message they want to read. So imagine one party holds a data set and the other party says, I want to read message number three. And then that party will only read the message they chose, but the sender will not know which one was chosen. So imagine that the query itself is sensitive. Like, I want to know patient, like Alice's data. And not only the data is sensitive, also, like the patient you are choosing itself is sensitive. So oblivious transfer is a way, assuming public key infrastructure, classically, of being able to perform this task. But with quantum communication, we can do it without public key infrastructure, with the caveats of security of quantum communication, of course. And that would be like the part where you generate a different key than for quantum key distribution. And afterwards, in time, the parties choose a function they want to compute, and they do a purely classical task on top of it. So we have the quantum part, the classical processing part, and a later stage where they choose the function. And as I said, if we swap the nodes for quantum computers, we can also do this where the function they choose is a quantum operation distributedly and securely. Okay, another task we can do, like the novel position verification task I mentioned. This one is that you want to prove that the message originates from a location. So usually, classically, how you would do is you would find where someone is using GNSS, like GPS or something, or sending radio wave signals, but all of them are threatened. Like, they can be jammed, spoofed, etcetera. And all of these are actually classical attacks. So the task or the application of proving that I'm in a certain location is not possible to do securely only using classical communication. But it is possible using quantum communication with, actually, this case, you also don't necessarily need entanglement. In all of these applications, entanglement, because you don't have to trust the source that's generating the photons, having an entanglement network gives you more security guarantees. You can do device independent QKD and stuff like that. But it's not essential for starting to learn how to use them and what can they do, or to understand the applications. And I think knowing what we want to do with these networks will help us in thinking about how we want to build them as well. Yeah, Okay. So it's the same, photons and then classical processing. So the conclusions of this talk is I would like to be in next step in the infrastructure that we have when we have access to the classical post processing. I would like to understand exactly what sort of hardware, what advantages it gives us, and if it's worth to consider quantum alternatives based on these advantages. Would like to understand the noise and performance trade offs of these protocols. A lot of it is unexplored. It's very theoretical. And also, I guess we will talk a bit later in the standardization. But what does it mean? It looks to me like most of the applications of quantum networks are in the security domain. But what does it mean to have security with quantum communication? I think we have to put effort on that as well. So if any of these applications, they are readable by a general audience, calls your attention, you know about it, drop an email in the email list. And that's Questions?
[00:19:51] Wojciech Kozlowski: Great. Thank you. As a reminder, please raise your hand using the MeetEco app to ask questions so that we can do go ahead, Rodney.
[00:20:05] Rodney Van Meter: Hi. So thanks for the presentation. Just as a speaking as a as an individual here. So big picture question, how much does this need to be divided into global global tasks, metro area tasks, campus tasks, data center tasks?
[00:20:33] Gadasi: I don't know exactly what's the role of data center or something. Like what I can say is that without repeaters, we cannot do long distance. So nothing above 100 kilometers. Like, cannot think I mean, we can think about applications, but our security has to be in this range of 100 kilometers. And also given the development and the speed of development, I think it makes sense to look if there is use cases in this 100 kilometer range. So depending on how small your country is, I don't know. Mine is 300
[00:21:08] Rodney Van Meter: in diameter.
[00:21:12] Gadasi: I don't know if that answers your question.
[00:21:16] Rodney Van Meter: Good enough for now. Thanks.
[00:21:18] Wojciech Kozlowski: Thanks, Rod. David?
[00:21:21] Dave Plonka: Hi. I'm Dave Plonka. I'm with WiskNet. Yeah. Oh. We're keeping it simple. So WSNET is one of the 40 research and education networks in The States, and I specifically came to the session today because of your talk, because it was compelling, presumably, to a lay person that didn't know this. What I see happening with The US research and education networks is they're super interested in quantum, because it's been a long time since people from outside the community asked something new of us, instead of providing research and education connectivity to the schools and nonprofits. And to to the degree that, for instance, my boss is in a four day meeting, I believe, in Oklahoma this week about quantum networking, and we're seeing some of our peer institutions build these out. And I think a lot of them as network operators like me are lay people or the general audience you're talking about that don't have any idea what can be done with this. I came here, and this isn't a criticism at all, it's more of my humility, I don't I didn't even know what quantum memory was, or I don't know what you're waiting for. So if you want this to be approachable to a general audience, that's the part that is a little bit off right now, is you're you're saying we're waiting for something that's five or ten years out, but the layperson doesn't understand what that is. And then maybe this is just then I just wanted to say an invitation to you. There is an audience paying a lot of attention to this in research education networks, presumably all over the world. I know The US ones. So if there's a subset of these that that that you could aim towards that audience or come or or have people come to our events, we we meet multiple times a year there, that would be really interesting. Like, I I I'll keep digesting this, but I don't know yet what should I be telling US RNA networks that serve k twelves and higher eds. What is this thing offering in the last five years? Does that make sense?
[00:23:06] Gadasi: Yeah. It makes sense. And I was also hired in my national research and education network one year ago, and I don't think it was very clear what quantum could bring. And this was an effort of mapping this advantage. But it's true that a lot of it so my conclusion in this, for example, was that a lot of it has to do with security. And security is very difficult for networks to even and also because the level of security that it offers, like what does it mean for something to be information theoretically secure instead of computationally based on public like, it's not super clear what is the advantage, is my answer. But maybe from all this process, what we saw is that this using computing facilities that can be distributed is what resonates most with us, because then you can do quantum computations in a distributed matter securely using quantum. But adding a layer of security on classical tasks and classical communication, that's a bit more unclear if it's really adding security or not. So we can continue discussing on that. The memory, I can shortly say what it means is to be able to hold a qubit without it disappearing from your hands. Currently, we cannot do that for a time span enough to be able to operate on it. Or to be able to make very long distances over 100 kilometers, you also need to be able to hold your qubit for a little bit. We cannot do that. That's what I mean. Our use cases or applications in the next five years have to be in this 100 kilometer distance scenario. For us, that is possible because our data centers and computing centers are not so far. For, like, large scale institutions, I don't know if that's enough.
[00:24:52] Diego Lopez: Yeah.
[00:24:54] Wojciech Kozlowski: Dave and Diego, I think I need to give you one minute for your both questions so you share between them.
[00:24:59] Rodney Van Meter: I'll I'll try to make it really quick. So in the classical domain, these algorithms that you show are computationally limited and not bandwidth limited of the channel that's used to do the communication. Now we know today the the quantum channels are fairly severely bandwidth limited. So it's just a suggestion is it would be good to understand and and tell people just how much bandwidth the quantum channel has to have before it's not the bottleneck for the underlying computation. Thanks.
[00:25:29] Gadasi: It's a a good question, and that's why I add in the conclusions that we would like to understand a bit more the trade offs between security and performance because it is clearly it's not clear from the literature yet. Yep.
[00:25:42] Diego Lopez: Very, very fast. Two two reflections. One, ITS is a rat hole. I totally agree with that. It's something that the idea that we are we have quantum and is information theoretically secure, well, on the paper. Does it? The the the other thing is that this phrase that you highlighted about having more access to the QKD devices. I from some time, I have been trying to well, I have been advocating for understanding QKD devices as as synchronizes synchronized sources of beats of random beats, which is not a queue. A key is something that we can use in other ways. And probably it's mom the moment of starting thinking about how we could be could build some kind of standard or at least open inter interfaces to that. That's something just as a reflection, if somebody wants to to start thinking, forgetting about the key there because it's something that is a little bit misleading, I would say.
[00:26:42] Gadasi: Yep. I agree. Like, I would like to continue talking to them.
[00:26:46] Wojciech Kozlowski: Thanks, Grazi. That's about time for your presentation. Very good. Thank you. And, Diego, you're next.
[00:27:12] Diego Lopez: So this is more as a typical ITF style report on how we are progressing with with the draft that we started some time ago on on proposing a a general architecture framework, not precisely oriented only to quantum communications, but trying to find a way in which we could integrate quantum communications in something that should be a little bit bigger, that is not a quantum Internet, but a quantum enabled Internet. How we play with the different resources. On the one hand, the physical ones that are required for connectivity, etcetera. And on the other hand, the concepts that are important for providing a service. Service that can be consumed by classical classical applications or consumed by whatever it has to do with distributed quantum quantum computations or whatever. The idea, it was it was not to define a protocol. This is not a research this is a research group, not a standards group, but to lay the foundations for analyzing this and trying to identify which are the useful abstractions that we do could use and provide a set of common common common ground to discuss about the different proposals, etcetera. For sure, the idea was to to leverage the experience that we have gained with QKD deployment. QKD deployments are limited, etcetera, but that now they include the number of nodes and they include a number that I used to to show when I when I introduced what we we have deployed in in Madrid. I used to introduce that when you see a box that say, QKD, whatever, then you have the complexity that that that has in optical switching, managing the channel, the the different bands, and doing the whole thing will expand to to something that is quite complicated. And for sure, based on on on SDN, and we were based on a on an architecture that was is the result of our of another research group that is called that we call CLASS. And as I said, this is about identifying abstractions and identifying address addresses or how we can address things, which are the things that make sense to address. Because probably the the usual idea of the end layers, name it four, five, seven, and a layered approach is probably a little bit limited to include this idea that we have to to balance in things. The as I said, the the draft was presented some time ago, was adopted by the by the QRG some time ago. We have gone through several iterations. Well, in some cases, long discussions on to to enhance it. We believe that this close to be as ready as a research result in ITF can be. It's not let me say, it's not something that is solid and everything is clear and is ready for for interoperability. And the recently, what we have done oh, I forgot. We have the most important thing at the beginning is that well, those do you familiar with you see you you will see another name among the authors that is that I don't think is here because I only know him by by email. He he came with a very interesting approaches so we we decided to include it as as an additional author. And we what we have done is addressing enhancing the service view. Let me assist. The goal of this is precisely reasoning about how we can provide services in in the Internet that that are enhanced by the use of of quantum technologies. And, well, we we have been playing with this idea, in particular with this mapping mechanisms that that we we have added and and that we will discuss in a moment. And then something something that we promised that we wanted to do from the it was to analyze a set of existing proposals and trying to map those existing proposals into the framework and say, well, look. This that has been proposed here maps very well in the quantum fabric stratum or this other has to do with how the physical stratum deals with the with the service stratum, etcetera. Make trending make analysis, and we have selected a number of those of those papers, basically, because they are they are papers, research papers derived from what's the especially the the RFCs that has been already published by the by the QRG mentioned as the main references, and we have selected a few of them. Probably, the list is not first, it's not exhaustive. It's not intended to be exhaustive. For sure, Maybe that we have forgotten some of them, some of the important one. Well, I I was about to let the to give you a a lesson of Spanish about the different the two a couple of the variables we have. Do know that we have set and start and it's not the same? It's Said is something permanent. A start is something that is temporary, but it's gonna be too long. And what is and this is dedicated only for the Spanish speakers here. So it's it's it's what you can that's probably not everything is there, but at least there are those those that we believe are relevant and can be used as a as a reference examples because what we do what we want to do is precisely to illustrate, well, look, the framework is for this. We we have applied these in these papers available now. We believe that this will happen and provide a methodology because what we want is that this will become a base for further experimentation by whatever the means that are available. So the new things that we have included, basically, is this I call it keys, but I don't know if you call it quiz or whatever. That's I I I will if there is some native English speaker, our our remote co chair, or you, David. How do you pronounce it? Q UI. You don't. Simply. Okay? Well, then it's a key, and that's all. And, well, the the basic is that originally in the in the document, we introduced the concept of a of a service unit. Service unit is the unit of service that is consumed by the application. Whether it's a set of entangled states, it's a it's a chain of reads that can be used for for building a key or for or for doing anything else. And and, well, the idea is that this is what in telco terms is very, very use very commonly referred as a user facing because it's the user of the network is consuming it. The what we have added is precisely a resource facing abstraction that is how you represent this how you can represent this in the lower layers. In in the in the elements that are providing you helping you in building the service. And that's is why we came with this this this key, this quantum unit interface. No. The the I is for quantum unit. Identifier. Identifier. Thank you. That is domain scoped. It's not associated to a it's not globally unique while a service unit is intended to be globally unique because it has to connect two entities in the network or two entities that are using the network to be more precise. But it's it's something that is domain scoped and is associated to a particular. It's how a service unit is translated. The idea is that a service unit is, by definition, is unique and global. And it connects a service unit may be associated with several keys in a space or time. And this is important because it is true that the recordings and the fidelity, etcetera, the ideas that you you have to keep you may need to keep several of these keys supporting a particular service unit because you would need to regenerate them or or re re reestablish the entanglement or use several of them in parallel. And this the real the idea is that the mapping is is one too many in general in this case. The the the mapping is in the if you for those of you who have read the the document, it should be clear that this is the mapping happens in the interface between the service stratum and the quantum fabric stratum is what they and and at the control planes, which are the ones that are that are defining those elements. And our plans are these mapping internally, mapping the the key to the particular physical resource, whatever it is should happen at the in the in the within the Quantum Fabric stratum within the between the control and the resource plane. Normally, should be, and this is something that, Gracias was mentioning precisely that everything is limited in time, which is something that we cannot do. And probably we will ever do to have a fully permanent something that we can consider fully permanent like we have with a bit. Bit moves from from here to there. It's stored in a memory. Stored in a disk. It's there forever. But with with with quantum information units, very likely, we will have to. To to have this, we can improve or we will improve hopefully, not surely. We will improve. Let's be optimistic. We will improve the time the the the lifetime of this quantum quantum information units, but it will be limited, and we will have to play with the idea of the life cycle, the freshness, the fidelity, how much we can expect that we'll keep the state, etcetera. And then the the supporting rebinding is essential. This is something that we we need to do. This is one of the main experiments we are planning. The support of of rebinding the ideas that you can reassociate it. And this is something that, well, during some meetings these days, we have collected a few of the ideas that they want at least to sketch in the in the document as a, let me say, as a way of continue of of continuing research in the future. And apart from that, we have added a couple of concepts that we believe is important to build the whole the to to finish the whole picture. One is is about which are the quality of service parameters that are relevant. That at the end is something that is important what you are defining this this service unit and how this can be mapped from from the from the service unit to the to the keys. And second, which is something that is Garcia was mentioning as well is that the connection with the with the classical functions. How do you need classical functions or we need classical functions because we are classical by definition, and we need those classical function to not only because we humans behave in a in a in a different plane, but as well be an equally important because the rest of the Internet is classical. And let me insist. We are talking about how we extend the capabilities of the Internet using quantum mechanisms. And then there is a there there is a list of functions and and this idea that, well, is is about applying these principles to what is usually known as operations and management. Finally, the the final thing that we are doing is this reference mapping. There is an analysis of a number. If I remember, what is around 10 references or so that we are mentioning the others. And that we are what we're doing is trying to identify well, identifying the categories and trying to comment the proposal that appear here, how would fit in the framework, and identify some research items that that could be interesting in the in the future. And, well, they're group grouped in these in these four categories, physical foundation and repeater technology, architecture and protocols, service instructions, and security. Again, not QKD security. It's a security of the of the of the mechanisms that are in use there. And for each reference, we are making an analysis of how it fits, consideration of how they can work with other pieces in the in the framework, and some well, we we we propose potential experimentation paths on this. Well, just to just to finish, we we believe that the document is close to be I mean, to be what the what the document coming from outside from our research group is. Exploring it it intends to explore architectures more than than protocols and even the the basis for this. So it's right to provide dissemination and especially what we're trying to identify as a set of research topics and provide a common a common framework and even terminology to be talking about what we're doing. And our idea is to try to move this to to last call. But before but but after we prepare another version that would basically, for sure, anything that we get here will be addressed, I hope. And then is a is a enhanced discussion on synthetic environments. This is something that will be presented by Blanca later on, I guess, after after this one. That setting and identifying some of the problems that we that she will be introducing and identifying it in more detail. And as far as I can tell, I have finished.
[00:41:41] Wojciech Kozlowski: Thank you. Great. Questions? And please queue up as usual for questions. Rod, go ahead.
[00:41:52] Rodney Van Meter: Hi, Diego. Good. It's glad I'm glad to see so much work, on the, draft. I will say as not really exactly chair, but at least as a pseudo official position. I'm looking at the diff between the o two draft and the o one draft, and 13 pages have been added between the two drafts. So with that much growth in it, I think it's really pretty unlikely that that it's it's ready to go to last call the way it is. I will try to get you more detailed comments on it as soon as I can. Sorry. I'm behind on getting that done. And the one specific comment on the on the content is one I've been asking for basically since draft one. It still talks in in one or two places about forwarding of IP packets, and I think forwarding is the wrong term for for the current generations of repeater networks we're talking about building.
[00:42:51] Diego Lopez: So would you suggest another term that is more adequate? No. I mean, forwarding if if forwarding is mentioned, it should have been disappear. For the last we we made a a review precisely to avoid the time forwarding. If it's if it's still there, we should go for it and, I mean, chase the forwarding mentions and and change them because it was intention. This is a this intentional the the change the change was intentional some time ago. In the previous version, the forwarding appeared a couple of times. Yes.
[00:43:25] Rodney Van Meter: Yeah. It's actually mentioned a bunch of times in, but most of them, it's just talking about the the the traditional classical
[00:43:31] Diego Lopez: Mhmm.
[00:43:32] Rodney Van Meter: Control forwarding plane separation. And so that's fine. But there's at least one place where it talks about the quantum forwarding plane that that we brought that we need to to take a look at and see if we're okay with that.
[00:43:44] Diego Lopez: K. No. No. Definitely. We we will have to to have a a final a final clean cleansing of the of the forwarding stuff.
[00:43:53] Rodney Van Meter: I'll get you more comments on on the full 13 pages as soon as I can.
[00:43:57] Diego Lopez: Please. Please. And the and the idea, seriously, Rodney, the the idea was precisely to ask for the last call once we address the comments. That's that's the idea.
[00:44:08] Rodney Van Meter: Fair fair enough. Good. Good.
[00:44:10] Wojciech Kozlowski: And before you go, there's a question online. And can you also raise your hand on the device? Do you have a question?
[00:44:18] Attendee: Yes. So I I only understand the section five three four, quantum QoS parameters. And I hope you can classify those parameters to specify which one are the constraints on the topology and which ones per request parameter. Because I suppose some of the parameters would be for each request.
[00:44:45] Diego Lopez: So but but the and the I think that we could do that. But if you if you could share you could share with us on the list the the the criteria you would follow, we we can we can discuss about this and how how to address this. I
[00:45:05] Wojciech Kozlowski: I'm
[00:45:05] Diego Lopez: I'm not saying that's that is it's something it's something we didn't think about, but this would be doable. And I and I think that's well, they have to identify what which criteria we we should apply. If you can share some ideas with us, it will be most most welcome.
[00:45:22] Attendee: I'm also not sure, but I hope it's
[00:45:25] Diego Lopez: it's Okay. Okay. Well, so so we will we will give it a couple of of thoughts to see if we can we can classify this.
[00:45:34] Attendee: Yeah. Because there are too many of them right now. It's hard to understand, especially when I implement simulators.
[00:45:43] Diego Lopez: Mhmm.
[00:45:45] Wojciech Kozlowski: Right. Thanks. One last question. And whilst that question is being asked, I'm gonna start a poll about who has read the draft or large chunks of it. So whilst listening, please also try have a look at the poll on the Meteko app.
[00:45:56] Blanca / Deborah Brungard: Deborah Brungard, speaking more in my liaison role, fine to you. Diego, the you mentioned optical transport networks, OTN, as the in IT, that's a very specific
[00:46:10] Diego Lopez: Mhmm.
[00:46:10] Blanca / Deborah Brungard: Restricted meaning and it includes right? It's a digital format, optical signals. So I think for this, you wanna open it up more. You wanna just say optical networks because PON is being considered also. Right?
[00:46:23] Rodney Van Meter: Yeah.
[00:46:23] Blanca / Deborah Brungard: So I think just make a more generic term.
[00:46:26] Diego Lopez: Okay. Okay. The the point is that so, you know, we one of of the things that at least in my company we have kept is the the idea that if we want this to happen, we have to have ever a quantum enabled Internet? We need to share the infrastructure one way or another because otherwise, it's gonna be not sustainable in terms of of of economic terms. Yeah. Yeah. Sure. Sure. That's it. That's it. Yeah. Yeah. Thank you.
[00:46:57] Wojciech Kozlowski: Great. Thanks, Diego. Hands up.
[00:47:00] Diego Lopez: Well, then then I will say that I I read the.
[00:47:04] Wojciech Kozlowski: Okay. Thanks, Diego. Okay. We're moving on to the next presentation by Blanca. Okay. Wait. I need to start your timer, but you can start talking. You have ten minutes, though.
[00:47:29] Blanca / Deborah Brungard: Yeah. Sure. Go ahead. I'll be fast. I don't know if
[00:47:35] Wojciech Kozlowski: Oh, yeah. Yeah. Yeah. There you go.
[00:47:41] Blanca / Deborah Brungard: Okay. I'm not seeing there, but maybe I can do it
[00:47:45] Wojciech Kozlowski: without poll.
[00:47:46] Diego Lopez: The poll?
[00:47:48] Blanca / Deborah Brungard: Can't do it without seeing here.
[00:47:50] Wojciech Kozlowski: Oh, wait. Because the poll takes over the screen. I'm gonna have to terminate. Okay. Go ahead.
[00:47:54] Blanca / Deborah Brungard: Perfect. Hi, everyone. My name is Blanca. I'm a call for the draft I was talking about earlier. And today, I'm gonna be insisting a bit in the synthetic environment idea and how it is useful for this kind of research. So let me get with QKD first because it's our most mature quantum technology. I know some of us are a little bit tired about talking every time about QKD. But, actually, we know Qkd works, but we don't know how to work with it. So we have a kind of maybe national scale networks, but they are not really, like, dense network, dense enough to to bring service to to the people and to operate with them. Basically, because we have a problem with interoperability, devices are vendor specific. And as my colleagues were saying, as Cassie was saying at the beginning, they sell you, like, a black box that you plug, and then you cannot do anything with that box other than request keys. But then those black boxes doesn't work with other black boxes you can get, and you have that kind of problem. Also, we have the problem that the key generation capacity is variable and limited, so we have to work with that. And we still don't know how to actually put those boxes in our current network infrastructure. So at the end, we have like this isolated island of quantum safe production, but we don't know how to work with them. So what we came up with that I don't have a reference yet for this work that is going on, but it's a technology agnostic framework that basically what you do is you deploy a a controller and you see you tell them, I have a island here using this technology. I have an island here that uses a different technology. And using emulated nodes, it builds up emulated quantum safe bridges. So I deploy an emulated node in an island and emulated node in the other island, and then we can connect those isolated island. I have no time to explain what QDITO is. I I feel like I repeat myself a lot with QDITO, but it's an emulation platform that is open access and allows you to talk to classical machines as you would with QKD hardware. So it follows a standardized API, and they perform and we model how QKD exchange work. And, at the end, we transform a classical device to a QKD node. And with this, we have been able to connect different island using PQC devices, using different, QKD technology ones. Some of them uses prepare a measurement, protocols. Some of them use an entanglement. Yeah. And we build this first in our university, and now we are connecting with other universities in Spain that uses other QKT devices, other PKC devices, and other implementation of key managers. That is also a problem because we still don't have any standard for that. So we are trying to to make everything works, and we have done it. We're preparing a publication on that. So maybe I can share with you, hopefully, soon.
[00:51:31] Gadasi: And
[00:51:33] Blanca / Deborah Brungard: broaden the the scope, as you see, is kind of have a kind of nature, so it's evolving to adopt a general entanglement networks formed. And what we're doing is we are not emulating the QKD exchange, but we are emulating the photon exchange, the photon entanglement chain. And then we are emulating how it's safe in a quantum memory that we don't yet have, but we are modeling it. And we are you have a reference there, a paper we present on a conference. Actually, it's a little bit outdated because we have been really, really exploring exploring this this way, and we have been making progress. And we are already doing some experiments on the evolution. And now we are working with Xiang, but maybe some of you remember him from another ITF. He came here and talked about quantum position verification and and his work on this, and we are working with the with with his team to implement these QPV protocols using classical machines on our platforms. We are also looking into how monitor entanglement networks, what do you need to know about the links on the on the operation in the network to monitor fidelity and and entanglement quality. And, also, we are looking at combinations of entanglement verification selection that is basically optimizing your verification protocol to a certain characteristics of your links and swapping amplification to get the best fidelity we want depending on the network. We are doing that kind of stuff, and we hope that these kind of platforms and these kind of synthetic environments help us resolve or at least address some questions that are open. So for example, following with the terms in the draft, what information must each stratum expose? So how quantum fabric which information should quantum fabric stratum expose to the control stratum of the service stratum? What is needed to control the the hardware? How should quantum resources be represented? How different owners of different domains should tag? Because maybe I don't want to expose all the information of my network to you, but I want to talk with you. So how many information do we need to share? How should failures be presented? Which elements of the network should be warned? And most importantly, I think the last one, how can we validate the architectural design choices? So there are a lot of proposals that we address in the in the draft that has been presented. How we know which one is the best solution for which cases? So these kind of environments let you build these architectures in a distributed manner, in a more real manner. So you have classical things, classical elements, quantum modeling elements, and this let you build elements and see, okay. Maybe this works for this case, but this architecture is not fit enough for other things. So I'm seeing the clock in yellow, so I'm gonna stop. So if any of got a question, we can also talk outside the session. And that's all for me today.
[00:55:13] Wojciech Kozlowski: You. Thank
[00:55:17] Gadasi: Thank you. You for the presentation. Amazing. And so what can I exactly simulate with this QDITO thing? Like, for example, the oblivious transfer, is it more like larger scale network interactions?
[00:55:27] Blanca / Deborah Brungard: Or Right now, QDITO, from the QR, you can see that, is actually, get a built emulated platform. So, basically, you can put anything protocol. Actually, it's cool because QDITO is really, really flexible. So QDITO has a module that act like a pro a QGated protocol. Right now, we have two different implementations, one for e ninety one and one for b b 84. We use NetSuite, our simulation platform, but you can put whatever you want there. So you don't need to use NetSuite. You maybe just want to use something that exchange a key through a socket. And then, QDITO, what this does for you is that it gives you an interface to talk to your classical computer as it would with with with QKD notes. The evolutionary QDITO the evolution of QDITO, right now, we have, like, an API that has different functions. We have share share entanglement with, and then you put a note, swap these two these two entangled photons, and then you can have a swap perform operations. And we are seeing also is the the time to see what we need from a quantum network for us to do so we can build this API to get every instruction we need to build the application. So right now, we are in this stage. We have, like, an API with several functions, but we are still looking what we need to to get.
[00:57:07] Wojciech Kozlowski: Great. I actually, that's the only question we have time for, so thank you very much. And now it's Sarah. Are you online?
[00:57:21] Sara Mansouri: Yes. I'm here.
[00:57:22] Wojciech Kozlowski: Good. Are you able to request? Yes. And I grant this.
[00:57:29] Gadasi: Okay.
[00:57:36] Sara Mansouri: Okay. So sorry for this sliding modification of the agenda. I had Internet connection problem, and now I'm connected with my phone. So I hope that everything should go fine. So the scope of my presentation is with the community about the the the the modification we did we implemented in the new version of our draft, which is called the draft-cacciapuoti-qirg-quantum-native-architecture and philosophy for the quantum Internet. We started from the RFC nine three forty as a baseline, which established the initial architectural foundation for the quantum internet. But in this RFC, the the the the role of a distinct distinct quantum control plan was upside scope. And but, actually, the the the the the the the the the new findings in the architecture and literature connected to the quantum Internet domain I'd like that indeed this question is useful to address most because the entanglement, which is the building block of the quantum internet, it's a it's a it's a communication resource as properties with no counterpart in the classical network. So the problem is how should entanglement be orchestrated? Being entanglement a stateful resource from a networking perspective. So in this draft, we try to reply to this to this question by arguing that beside a classical control plan, we need to scale some quantum obstruction within the control itself to be able to to track and to manage in a scalable way entanglement. So the the the the first version, zero zero, we put the basis of this architecture by presenting its foundation, including the separation between the control and the data plan, the control obstruction, the con the quantum control obstruction, which is the quantum addressing, and the generalized quantum forwarding obstruction. Then in the new version zero one, thanks to the contribution of two additional author, which are Amar and Joaquin, which I don't know if they are participating. We somehow strength the flexibility of the framework because we added some section about the possibility of the framework to not be binded to a single routing model or to a repeater regeneration, then we also added some consideration about multi domain routing. And we also try to clarify some concept thanks to the interaction on the mailing list. So broadly, the the the draft is organized at at at at an architectural level in this way. So we started from the properties of entanglement to justify why this architecture why we have these consequences at the architectural level. And in particular, why explicit decoupling between the control and data plan is necessary, but it's not sufficient for scalability. So we need to augment the control plan with quantum obstruction, the quantum addressing. I will talk later with more detail. And this calls also for a generalization of the concept of forwarding, and then we spend some section about this the flexibility. So this draft should be read as an architectural draft, not that we prescribe some implementation part. In fact, in title, we also highlighted term philosophy because I think that also many concepts are also related to your own philosophy about the the the evolution of this this network. So starting from the the properties of the entanglement to justify these architectural consequences, We know that entanglement is is a nonlocal nature, meaning that local operation affect shared correlations among remote nodes is volatile because it decoherence and also it's deflected upon use use. And overall, from a networking perspective, it's a stateful resource because to utilize entanglement, nodes need to retain information about the state of the resource, at least the fidelity, the the the the coherence left time, the ownership, meaning that the nodes identifiers that share this correlation. And it's also important for Glide that entanglement activate its own concept of connectivity, Meaning that once entanglement is shared, we have this entanglement graph that can diverge from the physical graph. So this means that the entanglement relationship cannot be captured only by the classical concept of topological neighborhood. So the network must reason not only over the physical graph, but also on these dynamics activated by entanglement. In particular, to utilize entanglement, we need the two ingredient. We need persistent state awareness, meaning that we we we need to to track this descriptor of the entanglement that I mentioned briefly before. And also the the operation that you need to perform on entanglement needs to be coordinated. This means that an explicit orchestration mechanism are required to manage this entanglement resource. In other words, the network cannot be blind to the entanglement state because entanglement is it's resource utilized for activating distributed functionality. So according to these properties, we first need so to explicit the couple control from data. So and so we have a quantum data plan and a quantum control plan. The data plan execute a quantum operation Instead, the control plan orchestrate entanglement resource. But I'll talk this this explicit decoupling is necessary. We have to consider that when we refer in the draft as a quantum control plan, we are not saying that the classical control plan disappear. Because as we know, for finalizing quantum protocol in general for the functioning of a quantum network, we need classical signaling, classical coordination. So the the the classical control plan is still necessary, but the the the point addressed in the draft is that it's not sufficient alone. And the draft is concentrated on the quantum part of this control plan, which orchestrate entanglement states by supporting the functionality like monitoring, reconfiguration, false policies. And instead then we have the quantum data plan, which carriers and manipulates resource by supporting primitives like elementary link level entanglement generation, purification, swapping, and and so on. We need this separation because as I said, as a consequences of the entanglement properties, in this way, the control plan can keep this resource state visible and usable with by not mixing control with operational with operational logic. But why then we focus in the draft on the the the need of scaling the quantumness, meaning quantum principle and phenomena also in the control plan? I mentioned it briefly first that we have a physical graph, which is relatively stable, and it's utilized, for example, for establishing the the the the what is feasible for generating the link level entanglement, for example. But then once the entanglement is shared, we have also this entanglement graph. And this graph does not follow it's not a constraint to follow the the the topology. So topological information. So this means that notes that are remote in the physical graph can be neighborhood in the entanglement graph. And this means that if we utilize only a classical control that is grounded in topological driven abstraction like EP like addressing, then we are not able to capture this entanglement relationship. And we face scalability due to the the communication overhead and the latency the latency constraint. This motivated us to say that indeed two each node needs two identifier, but with different roles. One is a classical identifiers, and the other one is a quantum identifiers. The classical identifier needs to capture the free the the physical graph. Instead, the quantum identify are allowed the the quantum control plan to operate on set of nodes by exploiting quantum state representation. And so align the quantum control plan decision to the resource relationship. So in other words, this quantum addressing is the control abstraction, which is utilized by the control plan to to makes entanglement aware decision. So if we utilize this dual dressing framework, the control plan can, at the same time, reasoning over the physical graph for determining, for example, where elemental link level entanglement generation is feasible or and they are, of course, relatively stable compared to instead to the entanglement dynamics. And then we can also represent the currently available entanglement resource, the ones that can be exploited for activating distributed network functionalities. And this call this call, so as mentioned at the at the beginning for generalized concept of forwarding. And these terms should be intended not literally, but analogically because in this case, we don't have the matching forward logic that we have in the classical in a classical network. But with this term, generalized quantum forwarding, we intend the decision of the structure, which through local manipulation of entanglement resource under control guidance support the establishment, the extension, or the transformation of the entanglement resources through a communication objective that could be, for example, end to end entanglement distribution
[01:11:28] Attendee: and so on.
[01:11:32] Sara Mansouri: The the last part of the draft instead, I said, focus on the flexibility of this framework by spending some consideration about the fact that the framework is not binded to a routing model, can be proactive, reactive, but it's not even binded to a repeater generation because the repeater is intended as a network functionalities and not as a network entity. And so in this way, you can modify. You can make the quantum data plan operation mechanism evolve according to the generation, but the logic is is the same. And with this same approach, again, stemming from some discussion through the main release, we also spent some consideration about the possibility to adapt the framework in a multi domain view. Although, we don't know yet how this network will scale. But if we put ourself in the same con in the same scenario over the classical Internet, not today, not tomorrow, Then this by allowing the federation of the entanglement defined controller, which is the logical entity utilized by the quantum control plan in a similar way to the DSDN controller, you can exploiting this federation, you can activate this exchange across domains. Okay. Maybe I'm out of time. So these are the summary of the the principle introduced within the the the draft. We use the the terms quantum native to say that the quantum mechanics principle and phenomena should be exploited not only in the message, let's say, delivered by the network, but also in the functioning, in the way in which the network function itself. And we received main interesting feedback for the the second the second version of the draft mainly by Rod. I know that he's doesn't like the forwarding terms. He also suggested something some other interesting suggestion, let's say, that are actually guiding us to towards the the the third version of the draft. So version zero two, we want to give a more clear definition about some some concept. Then we want also to clarify some control boundaries, meaning that we wanted to highlight how classical signaling supports quantum data plan operation. And so from a functional point of view, it can be embraced within the quantum data plan. We should add some references and so on. Let me just one minute because I asked the chair to spend just one minute on this network simulator, which is a module of n s three available on App Store, not because it's part of the draft, but because it was designed by taking into account these architectural tenants. And if you are interested, I would be happy to describe with more detail in another meeting. And that's it. Thank you. I'm open for comments.
[01:15:31] Wojciech Kozlowski: Thank you, Sarah. And questions, Lan? As a reminder, please raise your hand. We have two minutes, so maybe one more question after Rod. Rod, go ahead.
[01:15:43] Rodney Van Meter: Hi. Thanks for the update on on the draft. Particularly, wanna ask about the quantum addressing. Is the point of the the quantum addressing, are you trying to create multiparty states between more than two entangled states that that span more than two nodes, or is the idea to still have two party communication but with the with the with the the ultimate addressee not not yet identified?
[01:16:18] Sara Mansouri: I think that it can be both, meaning that it's not an identifier like the classical address. It is utilized by the control plan to reason not only on a single node, but since you can exploit quantum superposition, you can reason over a set of nodes, a set of paths, or even a set of domains. And for example, by using this quantum addressing, we may we design a routing protocol, which is compact, meaning that we can assure sublinear routing sites by exploiting these, let's say, compact way offered by the quantum mechanic to represent information. So it's not devoted to a pair based or multipartite. It's a way to let the control plan to reason about set of nodes, of parts in a more efficient way and to speak, let's say, in a in a broader way, the same language of entanglement so that the decision can be entanglement aware.
[01:17:45] Rodney Van Meter: Okay. I've read some of your older papers on that. I think I'm gonna have to go back and reread them because I definitely don't feel like I understand this part yet.
[01:17:54] Wojciech Kozlowski: Yeah. Let's continue this discussion Either on the mailing list because we're out of time for this. Thank you, Sarah. We have to move on to the next speaker.
[01:18:02] Sara Mansouri: Bye. Thank you.
[01:18:09] Wojciech Kozlowski: Okay. The next speaker is Christophe. Are you hi, Christophe. Are you able to request slides and present?
[01:18:18] Mitel Misra: Yes. I will do.
[01:18:19] Wojciech Kozlowski: So for context, I asked Christophe to speak to tell us about Euro QCI standardization. He'll briefly explain what Euro QCI is. It's so that we have awareness of what's going on in Europe and in other fields a bit outside of our domain. So with that, go ahead, Christoph. I'll put on a timer. You have twenty minutes.
[01:18:37] Christoph Pacher: Thanks a lot. Thanks a lot. My name is Christoph Stryx. I'm a senior senior scientist in the quantum cell cryptography group at the Austria Institute of Technology. I wanna thank the chairs, for the for the invitation, and I'll present my view on EuroQCI standardization here. So in 2020 in 2019, the European Commission said the future will be will be quantum. And they are putting it on the website to say, okay. Here's the, EU countries plan an ultra secure communication network. And when you dig deeper, there at the digital assembly, there were seven EU countries, particularly Belgium, Germany, Italy, Luxembourg, Malta, Netherlands, and Spain. They signed a declaration to explore over the next time a bit on how a so called quantum communication infrastructure across UBERT can work within the next ten years and so on. So this this idea should be developed. Particularly, it was interesting because they wanted to integrate quantum technologies into con communication infrastructure with two elements. There is an earth based component, but also in the space based components, particularly also for cross border levels. So here, this one communication infrastructure should help Europe to secure, yeah, the critical infrastructure and the encryption systems and so on against several threats, so against the several use cases and so on, particularly for data centers and long term privacy and the government data. And the ultimate plan is that's a long term plan. The vision of that is essentially and that's why we could be an interesting to the session here. It's that this could be the backbone of the Europe's quantum Internet. Okay? So connecting quantum computer simulated sensors and so via wireless networks and secure distribution of resources all over Europe. And they said then, as a first service, they want to deploy a new within a new infrastructure should be based on quantum key distribution. So the current status here is that, so it's abbreviated Euro QCI, European quantum communication infrastructure. Current status is that all 27 member states work together with the European Space Agency to design and the European Commission to design, develop, and deploy the Euro QCI. It will be under the umbrella now of the Iris Square. The Iris Square program, which will be an EU based space based secure communication system, and it would particularly safeguard the data and critical infrastructure based on the quantum quantum based system. And there were also some projects and quantum technology flagships, particularly the Open QKD project. What's already and he's already finished the project and so on. And and the current the current status here is that we are in the next phase of projects, which are the so called CEF projects connecting the member states together and the the infrastructure together. Yeah? What you see here is there's a project they recently granted. They, of course, they are subject to the grant agreement signatures. But what you see here particularly are terrestrial components that are linked. There are submarine enabled cross border quantum interconnections. There are particularly interesting when you look deeper here, are the OGSs, yes, the optical ground stations, which are quite some of those planned in Europe. And all these projects together, they form particularly yes, connecting and further enhancing the Euro QCI. This come came with a particular type of co funding, so the member states has to con had to contribute or contribute as well, about 19 projects, 25 member states covered with the total investment roughly 200,000,000, and the grants roughly 100,000,000. And particularly here, this self digital funding will increase, as already said, the sensitive communication, between the public authorities, authorities, research entities, critical infrastructure in the member states, and particularly also boost Europe's capabilities to develop this quantum secure optical telecommunication networks and the critical security critical infrastructure and also to enable a large market uptake. Yeah? So pro promote quantum based secure networks and also to enable this large market uptake. And because this to leverage also this market uptake, there's one particular assets which could be exploited, and this is standardization. And now I'm coming more or less to the main theme of the talk that there was a call for proposals, which was opened in July last year. It's roughly one year ago. It was closed in October, I think, on the support of standardization for the zero QCI. It's a so called CSA, yeah, coordination and support action. And there were particularly type of funding dedicated to this. So what is the expected topic outcome here that there needs to be a set of standards defined for the QKD components and systems? The standard should be in the for interoperable systems and application, particularly also to the entire network and multiple networks, particularly specific requirements, benchmarking test metrics and so on. These are required for QKD purposes. Also, the formalized assessment on the acceptance of QKD protocols here, particularly security, proofs play a huge role. And the contribution to the technology autonomous European QCI ecosystem. On the topic objectives here that this standardization support coordination and support action should essentially support an operational EuroQCI infrastructure with dedicated QKD and quantum cryptography services. And there's particularly need to intensify the standardization efforts at all levels, yeah, while QKD products are already available. You can buy them. You can buy the the components. They are made available also by industry, but for the market, and it's more available for market early adopters and innovators, but still, there's a need to attend intensify the standardization efforts. This ranges from QQD component, systems application to network capabilities and so on, particularly also for, and this is also the vision here at for future quantum networks to enable the the integration of the quantum devices there, and particularly also to build a solid industrial base for future quantum networks and particularly future certification. So for the topic scope here, there was foreseen an overview of QKD standardization activities currently going on, but also standardization of QKD components. And this is ranges, as I said, on on on all levels, yeah, from single photon sources, entangled band based sources, QKD transmitters, receivers, and so on. This goes also to over benchmarking, metrics, calibration, operational environments, monitoring, and so on. Moreover, the standardization of multiplexing of quantum signals is is is in scope. And standardization of software hardware interfaces, particularly on key so called key management systems. Key management system play a particularly interesting important role, for connecting all the, let's say, domains, and networks, beyond only the QKD components. And moreover, we have to look at the entire network and with well, entire network and multiple networks connecting those. Also, that is particularly routing, control, management capabilities, so on, and particularly based on on software defined networks systems and cross border connections. Also, there is foreseen standardization efforts on hybridization schemes for combined QKD and PQC. This is particularly interesting as the QKD components must be integrated in classical infrastructure, and here, PQC became clearer and clearer that PQC can play a large role there helping to secure those systems. And also, lastly, the scope on evaluation and certification of QQD protocols was particularly important. A rigorous assessment, particularly, as I said, the security proofs here and the acceleration on the work of certification and also the strengthening of the collaboration efforts here between the national authorities and relevant initiatives and also evaluation laboratories. The awarded CSA, was Harmonic QCI. It's awarded, with the full title harmonizing the standardization activities for Euro QCI. It's a project and coordination and support action, which will run for thirty six months. Unfortunately, I cannot give you too much details on that, so I will have one slide on on the main goals. But please bear with us for a bit of time when the project will be officially kicked off so we can have more information available. And we, yeah, want to, of course, provide this information as soon as possible. So what is the main goal of Harmonic QCI? It's to facilitate intensified standardization efforts at all levels for an operation. At Euro QCI, we want to get this into operation. And particularly, we have three main pillars we we look at, and this is first the integration into the telecommunication networks. This we foresee particularly of high interest. This will be also including space segments, but also terrestrial and so on. Then there will be the integration into the security protocols. This will be cybersecurity, more or less. For example, also the the combination as an additional layer to BQC, for example, or to other security measures. And the last one is the the standardization on the QKT components and systems itself, particularly also looking into future networks, as efficient. So the takeaways and the KPIs, we have the European communication infrastructure. It enables secure high secure communication all over the EU, including the overseas territory. This is planned currently carried out with the particularly funding from the European Commission and project in several and all in several EU member states to work on this together with also with the European Space Agency. There were standards, will be highly relevant for the operational Euro QCI, particularly on the on the on on the key performance indicators here. We want to increase the number of new new stakeholders involved in standardization bodies. This will be a strong KPI, particularly also to increase the number of proposed draft standards. You know? So, of course, we are aware of that. The project which will run thirty six months, it's not that long. Standards take a long time. That's why we also do not expect to have a lot of ready final standards at the end, but at least we want to push high on this KPI. And the project will particularly facilitate, intensify these efforts at all levels, particularly dedicated to Euro QCI, yeah, and range we have planned several activities, as I said. Please bear with us a bit until the projects officially kicked off. And with that, I'm ready for this overview on your QCI. Thank you.
[01:31:00] Wojciech Kozlowski: Thank you very much, Christoph. Are there any questions from the room? I actually have a question, so I'm gonna put myself in the queue. One thing that I didn't see in your talk, but I'd be interested in is, like, which standard development organization bodies are you looking? Because also because you which ones are active in which field? And especially the ones that you mentioned for future compatibility of the components, that'd be interesting to hear. Which bodies are you looking at?
[01:31:32] Christoph Pacher: So, particularly, Etsy has a strong record of standardization efforts on QKD. So Etsy will be particularly also in focus here. We've also put focus on Sense and Eleg and JTC 22 working group four, which deals particularly on the communication aspects, but we do not exclude other activities there as well. So as the project develops, we expect that we will see and further explore possibilities in that direction. And the second question was on the components?
[01:32:19] Wojciech Kozlowski: Yeah. It was it was related in a sense what which I guess, which bodies were you looking at standardizing those components? But I guess it's part of your the answer you gave already so far.
[01:32:28] Christoph Pacher: Yes. Right. So, yeah, on the components, that's that's that's current view. Yeah. But, of course, we want to support the activities on on any aspects and, yeah, and consensus based with no it's a long term effort and consensus based effort, open effort, and, yeah, we support anything that we can to boost the operational your QCI. Yeah. Yeah. Thank you.
[01:32:54] Wojciech Kozlowski: Thanks. There is a Ben Roberts in the queue.
[01:33:02] Ben Roberts: Yeah. Hi. I found that last point about aiming to create a quantum infrastructure spanning the EU and its overseas territories. So I think the overseas territories are very long distances, islands and things. That's bringing a whole bunch of new technology challenges to add, you know, long subsea cable quantum communications. So just wondering how how that's in decision to work. Thanks.
[01:33:28] Christoph Pacher: So I I was I was presenting my view, of course. The what is currently foreseen from my point point of view is that if you spend long territories, you use it by satellite based communication. So there will be satellite aspect on the on the URKCI, particularly in addition to the terrestrial space. Yeah. Mhmm.
[01:33:53] Wojciech Kozlowski: And, actually, to answer that, can you show your map of the connections and draw I guess, point out that how many of those are actually optical ground stations?
[01:34:02] Christoph Pacher: Indeed. Yeah. So let me
[01:34:04] Mitel Misra: go let me go back.
[01:34:09] Christoph Pacher: Exactly. They're kind of kind of lot or not that few optical ground stations planned, yes, indeed.
[01:34:20] Wojciech Kozlowski: This is available online if you Google for, like, your QCI stuff. So Rodney.
[01:34:33] Rodney Van Meter: Yes. Just on this slide, the the slides that are uploaded in into the data tracker in PDF don't show this because the because the next step of the overlay, covers it. So And it be helpful if you if you upload reuploaded the the PDF with every stage as a separate page of the PDF.
[01:34:56] Christoph Pacher: Yeah. I I I thought I did it. I I when you check version zero one, I think it might be also already available. Thank you.
[01:35:06] Rodney Van Meter: Yeah. I'm definitely looking at zero zero. Let me see. Is there a zero one? There is a zero one. How nice. I will I will use that one. I don't know how I wound up with the 001. Alright. Let's see. So I put in the chat just a comment. More more for sort of everybody. But, Christophe, I don't know in particular if you have travel plans or not. But I triple e quantum week is in Toronto in mid September, and there is a day long workshop on Thursday of Quantum Week on international standards, being organized by some people I know. But I I've been sort of peripherally communicating with them, but I'm not one of the organizers of that workshop. It's on quantum computing as well as on quantum communications. So the a little less folk focused on just the communications, but worth attending. We went last year, and it was very, very good.
[01:36:06] Christoph Pacher: Ah, very interesting. Thank you. Yeah.
[01:36:11] Wojciech Kozlowski: K. Any last question? No? Okay then. Thanks a lot, Christoph. This has been a very useful overview. Just again, we don't understand this, but it's good to know what's going on in the space. So this has been very useful, and maybe we hope to see you around in the ecosystem. Thanks a lot. Moving on to our last talk, it is let me just cancel timer. The speaker is because there's two. It's Nevan or Mitil. Are you online? Yes. Hi. Can one of you will need to request to share the slides and find your slide deck?
[01:37:01] Nevan: I I I I can do it. Request slides.
[01:37:06] Christoph Pacher: Yeah. Okay.
[01:37:17] Mitel Misra: Okay.
[01:37:18] Wojciech Kozlowski: But you have twenty minutes. Go ahead.
[01:37:20] Nevan: Alright. Hello, everyone. My name is Navan.
[01:37:24] Mitel Misra: And, I'm, we're both
[01:37:31] Wojciech Kozlowski: Mitel, we cannot hear you very well.
[01:37:36] Mitel Misra: It
[01:37:38] Wojciech Kozlowski: it it starts speaking, and then there's an interruption. See if I can fix that.
[01:37:46] Mitel Misra: Hold on.
[01:37:53] Wojciech Kozlowski: Can you just try saying something?
[01:37:55] Mitel Misra: Yep. Hello?
[01:37:57] Wojciech Kozlowski: That actually seemed to work.
[01:37:59] Mitel Misra: Okay. I I guess. Okay. Yeah.
[01:38:03] Wojciech Kozlowski: It seems okay now. Just go ahead.
[01:38:05] Mitel Misra: Right. So I'm I'm Ethel Misra, and we're both students at the University of Pennsylvania, part of the Phong group.
[01:38:14] Nevan: So, yes, today, we're gonna be presenting, our protocol that we've presented previously, quantum datagram control our quantum datagram control protocol, and just present some updates that we've done since last time. Okay. So first, as a review of what we've previously worked on. So when sending quantum information across IP networks, quantum information can't be cloned. So the metadata that we send in front of it, the quantum datagram, is sent using UDP. As a result of this, each metadata component that we build in in our quantum datagrams is built using TLV or type length value packets. And so, for each, metadata component needed, like a time of origin or polarization correction, which we'll talk about later, we design a TLV packet. We build a TLV packet for before sending the QDCP and the quantum information. And we've done experiments already, demonstrating this hybrid quantum classical packet routing on commercial fibers using photonic chips that we've built.
[01:39:31] Mitel Misra: So to give an update, we've actually, started an implementation of, this draft-zhu-qirg-qdcp, on a Linux server, to build and send QDCPackets on an Arduino to our, hardware or, optical hardware, which will then send the quantum information as well. So, currently, it's all user space using a command line interface. And then there's currently, we have multiple ways to transfer, but, like Niven said, the main way will be with UDP. And then we have set up currently one the receiving node and one router that we'll talk about later. To show some updates on the actual packet structure, so we've wrapped our QDCP packet in the standard UDP header as well as with an I p v four header, which has our source and destination address, which is how the routing will be done. Previously, we had suggested using a road m port ID as one of our TLD fields. We have now replaced that with instead having all the destination information in the IP header. But the, yeah, the rest of the standard UDP header and the QDCP packet header along with the TLV payloads remains mostly unchanged. Yeah. And to, as a case example of this dynamic IP routing, we mentioned a similar scheme, last presentation, but, this time, we've, implemented with a couple of, notable changes. So instead of using wavelength division separations with ROADM switches, now we'll use, currently, we have an IP and an Arduino setup to do the switch where we separate the signals in time, the signals being the quantum packet payload in front, and then the quantum information sent after. And to route using the IP header, we have the host PC or Linux server using slip to assign IPs to both the host and the Arduino gateway as well as a range of destination IPs that you, that routes through the draft-zhu-qirg-qdcp destination IP range, through the slip interface, allowing UDP packets to be addressed to individual draft-zhu-qirg-qdcp nodes that we, set up that can be forwarded through the Arduino gateway.
[01:42:23] Nevan: And here are some results from that exact test that we showed in the previous slide. So we set up two different IP destinations, one with, like, a longer fiber cable than the other. And when measuring coincidence count rate between the, source and the destination between these two IP destinations. The one with the longer, IP route, the 10.o..o.one, had a longer time delay as a result of the longer fiber cable. And the other IP destination, the coincidence count rate was lower because, because the, there was less time delay because it was a shorter fiber. And then
[01:43:15] Mitel Misra: So moving on to updates to TLVs. Our most notable change is the way we're handling polarization correction. So this, correction is due to the problem that long distance fibers can change light polarization. So our solution was to use classical light to identify this change and correct for it. And, we specify what sort of polarization to expect with our draft-zhu-qirg-qdcp, with the protocol. And this is sent in three important bits of information, the polarization, the duration, how long this polarization will last for, and the arrival time, how long after the packet is sent that depolarization will arrive. And this allows for our receiving node or whatever is the receiver, right, to correct for any changes made, any any change in polarization due to the fiber. We've the the major I'm sorry. Yeah. The main change is instead of having that this timing information is especially important now because instead of having the packet, originally meant to be sent at the same time as our information, we have more of a time delay, and we need to account for that by adding these extra value fields of duration and arrival time.
[01:44:41] Nevan: And then, lastly, we wanted to show, some we're how we're testing our q d three protocol, and applying it to time synchronization. So, essentially, sending these sending quantum information across IP networks and then using this to calculate what the time delay is between, two different, channels. So in this plot in this graph here, we measure coincidence count rate, across multiple different bins of of, sorry, of, time delays. And then we can measure, the correlation or, like, when the max, when this most significant time delay is. And we're working on developing, or implementing an algorithm that we can use on top of our existing protocol, which will calculate the delay and help synchronize clocks across distributed computers. Thank you.
[01:45:56] Wojciech Kozlowski: Alright. Thank you for your presentations. Are there any questions from the room? I actually have one also. Need further questions. How do you I don't know. Maybe you said it and I missed it or it's somewhere in the draft. How do you manage because your classical header goes separate from the optical signal. How do you manage the timing relative to both? Because at least in a classical network, they're like one unit that kind of goes in a chunk. But in a quantum packet, as you presented with a classical header and a quantum signal, they're two separate things. How do you manage the timing between them and so that the action specified in the header applies to the optical signal?
[01:46:42] Mitel Misra: Yeah. So the sending of information is all handled by the same chip. So it itself has the time it's it's the packet itself is sent at once with the packet and the quantum information. So both of those are kind of sent together with the timing delay that we specify from the the sender.
[01:47:09] Wojciech Kozlowski: But doesn't but then what about the processing delay of the intermediate devices where it has to decode the header, decide what to do with the header, and then how do you manage that?
[01:47:19] Mitel Misra: So at, each, our our current router that we have right now, we have the quantum and classical information kind of on the same we we have it on the same route, and we take a little bit of that light to separate that to our our current this is our current, workaround. We have a little bit of that light, separated from, the fiber, and that goes to our Arduino for processing. Mhmm. So, currently, we have a bit of a delay, or we have a a substantial delay between our quantum or between our draft-zhu-qirg-qdcp header and our quantum information. That is that processing time to account for that processing time. And then while the Arduino then processes that and app applies a switch, the quantum payload is consumed, and the and for quantum information can go through the switch. This is a bit of a limitation, though, as we have to send now multiple packets to achieve the routing if there are multiple routers to be interacted with. But, yeah, I hope
[01:48:37] Wojciech Kozlowski: that answers your question. Okay. Thank you. Rod, you're next.
[01:48:44] Rodney Van Meter: So there's a lot of interesting stuff in this. I'm really impressed with the level of implementation of everything. To be sort of pedantic, I've had conversations with several people going back years on on some quantum protocol stuff about what the right way is to go about actually specifying packet contents and formats and things like that. And you guys are doing fairly low level packet formats with this field is eight bits. This field is 24 bits. You've got stuff packed together trying trying to minimize things. And I'm not sure that's actually where we want to be at in terms of, flexibility on this stuff. For example, if you go to your page seven, I think it is. So you've got the yeah. This one. The position field is eight bits and duration field is 24 bits. That means we can have 256 possible polarization states, which is less than one degree if you've got 350 360 degrees. But, I mean, you know, there's some metrics. So they're three quarters of a degree or something. But the duration at 24 bits, that's sixteen million nanoseconds, which is sixteen milliseconds. And for example, in our prototype network that we've got, it takes us several seconds to actually reconfigure the network. So when we set up to run a polarization, we're actually setting it up to run for for for a long period of time, not for not for millisecond level stuff. So those are places where I where I think what you're doing is kind of premature optimization of some of the communication. Although, you know, the, I've been having these conversations in the hallways with people at IETF for a couple of years, and there is definitely not one single consensus on what the right way is to go about actually specifying a protocol and these message formats in the modern IETF. So it's just a comment. Kinda kinda keep that in mind.
[01:50:59] Nevan: What sort of,
[01:51:00] Rodney Van Meter: like And, obviously, I have to to say, by the way, you should be doing I p v six too.
[01:51:07] Nevan: Oh, wait. I I agree. No. No. No. I I agree as well. What sort of, like, other formats are there outside of, like, the TLV that we described that are worth looking into?
[01:51:20] Rodney Van Meter: Well, some people would say you should just define these as JSON values and run it run it over a higher level toolkit or something like that. Others would say you should be specifying it as GRPC or protocol buffers or or or something like that rather than hand coding raw low level packet formats. There are different opinions on what the on what the right toolkit is for constructing it, and I I can't say I I have a really strong opinion and and that my opinion is definitely the best on
[01:51:54] Nevan: Okay. Makes sense.
[01:51:58] Wojciech Kozlowski: Thanks, Rodney. There's a question from.
[01:52:02] Attendee: Well, actually, it's a follow-up. So I I come with the background of name the data networking that is in the IC and RG group. So we actually use the TRV everywhere. But our solution is you can make your TRV extensible. First is for if you say it's how long is this number, how many bytes, your your lens your lens value represents how many bytes are in the value. So suppose you you currently have 32 bits, you want to 64, you just double your lens. And then your password will understand the value has 64 bits. But the low level encoding is very useful because in quantum, you want it to very fast. You may not even want to process it with a computer. You are probably processing it with FPGA. So having a compact compact packet format allow you the FPGA to very quickly process the packet and then send to the hardware decisions.
[01:53:09] Nevan: So then, essentially, like, making the the the the size of each of these TLV component, each of the components in the TLV, like, as a argument or an input? Like, you can adjust the size.
[01:53:24] Attendee: Yes. Not necessarily in the same implementation, but the protocol wise, you can say the size of the value is determined by the lens. And in IC and IG group, there are also a few other documents saying how to have how to define the duration. But, of course, they are running at a much longer time periods than what a quantum usually does.
[01:53:52] Nevan: Okay. Thank you.
[01:53:59] Wojciech Kozlowski: Okay. Great. Any other questions? Going once, going twice, going twice. Thank you a lot, Nevan and Mikhail. Thanks for the presentation. Was very interesting. We can also continue the discussion on the mailing list. Good. Okay. So that's basically it for today. So we'll continue all the discussions on the mailing list for what especially about the multi plane architecture draft and any other drafts ongoing. Other contributions, obviously, are welcome, and there can be there are various discussions that sometimes happen. Anything else you wanna say, Rodney?
[01:54:43] Rodney Van Meter: Yeah. Speaking as an individual and author of a couple of the drafts that that that that didn't go get on to today's agenda, just since there's a couple of minutes, an update on those. There's no update on those. We we have not we've not made progress on those. The the the student who was working on them is off at at an internship in in a company. And the the the the other faculty member and I who are putting this together, Mikhail, the he and I are busy with the with the
[01:55:18] Wojciech Kozlowski: Your connection.
[01:55:19] Rodney Van Meter: But interrupted. Sorry. What's that?
[01:55:23] Wojciech Kozlowski: Your connection is very interrupted. I didn't hear at all what you just said. So
[01:55:28] Rodney Van Meter: How far back?
[01:55:29] Wojciech Kozlowski: After the student went on the internship.
[01:55:33] Rodney Van Meter: Oh, so student went on the internship, but Mikhail and I are were still considered the drafts to be to be active work. So so we're not dropping it, and we expect to have updates over the next, couple of months. K. I do personally, I don't know if I will be in San Francisco, and so Wojtek and I have not yet talked about whether or we'll do be doing a meeting in San Francisco. But those of you who aren't looking at your email, Jay just sent around email a little while ago saying next March has been scheduled for Kuala Lumpur, and I certainly intend to be there. So we'll see you either in San Francisco or in KL.
[01:56:09] Wojciech Kozlowski: Great. Awesome. Thanks, Rod. And thanks everybody and all the presenters today. I hope to see you around. See you on the mailing list. Bye.
[01:56:21] Rodney Van Meter: See you all around. Thanks, Wojtek. Good job running that all alone.
[01:56:27] Wojciech Kozlowski: Yeah. Thanks. We should actually finally have a job there. It's been a while. Yep. Alright. See you. Bye.
[01:56:36] Rodney Van Meter: Diego, good to see you.
[01:56:41] Wojciech Kozlowski: K.
[01:56:48] Diego Lopez: Rodney, can you hear me?
[01:56:51] Wojciech Kozlowski: This is Diego.
[01:56:52] Diego Lopez: Can you hear me? No.
[01:56:53] Rodney Van Meter: Hi, Diego. How are you?
[01:56:55] Diego Lopez: Well, any anyway, I can hardly hear you. I'll I'll I'll send you an email. I wanted to ask you about the Toronto event, but I'll I'll email you. Sorry.
[01:57:05] Rodney Van Meter: Okay. Hi, y'all.