[Qirg] Measurements in link layer service

[Axel Dahlberg <[e-mail]>]

First of all, thank you everybody who organised and participated in the meeting today, it was very nice :)

I would like to come back to the point that came up during the meeting regarding measurement bases specification for "measure directly" (M) type of requests to the link layer service. There were points raised that this should be higher in the stack. However, I don’t agree with this and will try to explain why I think so here. That being said, I’m very much looking forward hearing other’s thoughts and will be open to being convinced otherwise.

To start with I would again like to emphasise that the draft (https://datatracker.ietf.org/doc/draft-dahlberg-ll-quantum/) specifies a the link layer service and the vertical interface to this service. That is, the headers in the draft (which I think causes confusion and should be updated) are the vertical requests to this service and not horizontal messages in the protocol implementing this service. Thus, my claim is that the information about in what bases the nodes should measure in, in the case of measure directly entanglement generation, should be part of the vertical request/message to the link layer service. Besides this, even though this is out of the scope of this draft (since it’s only about the service), I also believe that any protocol realising this service needs to also communicate these measurement bases between the nodes. The reason for this is that the entanglement generation request is on one side (i.e. the requesting node) but both nodes need to agree on that they are going to perform measure-directly-type of entanglement generation. Furthermore, they also both need to know in which basis they should measure in before entanglement generation is started.

One might ask why include this functionality and not just have “create and keep” entanglement generation and the nodes can then measure this entanglement when it is generated. The reason is that one can in many situations have a much higher rate if the qubit is measured directly. For example, in the case of heralded entanglement generation where the nodes each have one communication qubit (for example nitrogen-vacancies in diamond), both nodes will entangle their local communication qubit with a traveling photon which is sent to a heralding station. The heralding station will interfere and measure both photons and send back the measurement outcome to the nodes. In the case of measure directly, the nodes can, directly after the photon emission but before receiving the heralding outcome, measure their local communication qubits and again start a new entanglement generation. In this way there can be multiple photons in flight to the midpoint at the same time. This is in contrast to the case of create and keep, where entanglement generation rate is, among other things, restricted by the RTT from the nodes to the midpoint.

After the meeting, me and Bruno also discussed how things would work for nodes which are not directly connected the network (i.e. connected by controllable repeaters nodes in the network), but however just want to create correlated bits for for example QKD. In the naive approach there can be create-and-keep requests to all the links in a chain connecting the two nodes, which is then subsequently measured at the end-nodes and swapped (entanglement swapping) in the intermediate nodes. However, it might be the case the end-nodes don’t have memory and thus cannot perform a create-and-keep request. In this case the link layer service we’ve proposed actually supports a third type, which is for remote state preparation (R). This remote state preparation is essentially a one-sided measure directly request, where the requesting nodes measures the entanglement but the receiving node stores it. In the current proposal the requesting node is always the one measuring the half of the entanglement. There was a discussion if it would also be useful for the requesting node to also be able to specify that it will store the qubit and the remote node will instead measure it. This might be useful but should be thought about.

Bruno also suggested that it might be useful to write down an example of how these different requests and control messages would be used in for example a scenario where two remote nodes want to for example to BB84 QKD. I think this is a good idea and could probably help clarify some points raised in the meeting.

Anyway, I hope my wall of text is somewhat comprehensible :) If you disagree or have any thoughts/questions I’m happy to hear them.

Enjoy the rest of IETF!

/Axel Dahlberg