Subject: [Qirg] updated I-D (-01) on connection setup

From: Rodney Van Meter <[email-masked]>
Date: Thu, 12 Sep 2019 13:43:43 +0900

If you’re on the drafts list, you probably saw about 19 hours ago that I posted an update to our draft on connection setup in quantum networks.
https://datatracker.ietf.org/doc/draft-van-meter-qirg-quantum-connection-setup/ <https://datatracker.ietf.org/doc/draft-van-meter-qirg-quantum-connection-setup/>
This is a minor update.

I went back and reread the email messages from when we posted the original in March. I think we covered most of the concerns here on the list, without needing much in the way of changes to the draft. But I clarified a few definitions in the new draft.

I think there are four things that I’d still like to do with this.  One is just writing:

1. Wojciech asked for an example of the process.  Agreed.

I think that’s an excellent idea, and would liked to have had it in the -01 draft, but didn’t get it done before -00 expired, so I went ahead and did the minor update.

There are three technical things that need to be done:

2. Align the terminology with Wojciech’s architecture document (*or vice versa*)
3. Our own thinking on where in the architecture *resource reservation* belongs is evolving; our simulator isn’t quite up to needing that yet, so we don’t have real experience with it yet, but this is an important discussion.
4. Wojciech asked if segment routing (SR) could figure into this, and I have only a dilettante’s understanding of SR, so I can’t say but would like to investigate.

Maybe we can revive the discussion of these here on the list, so that we can put out an -02 before Singapore?

—Rod

Rodney Van Meter
Professor, Faculty of Environment and Information Studies
Keio University, Japan
[email-masked]

---

From: Gelard Patrick <[email-masked]>
Date: Thu, 12 Sep 2019 08:21:21 +0000

Hi,

« Use of the quantum network is driven by applications running at two (or more) classical nodes.  Overall behavior is similar to client-server computing.  The connection is initiated from a node similar to client and responded to by a node similar to a server. »

The common need of quantum application like distributing computing,  Distributed quantum sensing (e.g Entanglement enhanced quantum sensing<https://www.researchgate.net/publication/47821472_Entanglement_enhanced_quantum_sensing> ; Distributed quantum sensing in a continuous variable entangled network<https://arxiv.org/abs/1905.09408> ; …), QKD base entanglement, … are distributed entanglement (Bell pair resource for point-to-point relationship) who is the fundamental resource for quantum-enhanced applications.

Thus the quantum-enhanced applications have to request, via classical network,  this entanglement resource  which is generated by entangled quantum light sources (e.g spontaneous parametric down conversion (SPDC)) that must be interconnect to the quantum network.

The proposed communication establishment model is more a request-reply model like RSVP for example  than a publish-subscribe model like MQTT for exemple. In a publish-subscribe model, quantum-enhanced applications will be the subscriber to entanglement resource  and the publishers will be the source of entanglement photon pair.

For the control plan of a quantum network, is a publication subscription model more appropriate than a publication subscription model to meet the needs of quantum applications which is to request/subscribe to entanglement resource    ?

/Patrick

De : Qirg <[email-masked]> De la part de Rodney Van Meter
Envoyé : jeudi 12 septembre 2019 06:44
À : [email-masked]
Cc : Rodney Van Meter <[email-masked]>; Takaaki Matsuo <[email-masked]>
Objet : [Qirg] updated I-D (-01) on connection setup

If you’re on the drafts list, you probably saw about 19 hours ago that I posted an update to our draft on connection setup in quantum networks.
https://datatracker.ietf.org/doc/draft-van-meter-qirg-quantum-connection-setup/
This is a minor update.

—Rod

Rodney Van Meter
Professor, Faculty of Environment and Information Studies
Keio University, Japan
[email-masked]<mailto:[email-masked]>