Re: [Qirg] Similarities between RSVP IETF (RFC 2205) protocol and connection Setup in a Quantum Network

Note for RSVP to work as you describe, you need a multicast source-based distribution tree set up prior to any Path message sent. 

And Path message refreshes happen to new receivers when new branches are formed on the multicast distribution tree. 

And also note that quantum repeaters are not likely to be deployed initially on the same sides of a classical channel. What I mean is you could have this topology:

QR —— CR ——- CR —— QR

where CR is a classical router and entanglement swapping happens by each QR. 

Dino

> On Nov 19, 2019, at 8:40 PM, Gelard Patrick <Patrick.Gelard@cnes.fr> wrote:
> 
> 
> Hi all,
>  
> There are similarities between  RSVP  IETF (RFC 2205) protocol and connection Setup in a Quantum Network ( https://tools.ietf.org/html/draft-van-meter-qirg-quantum-connection-setup-00 ) even if the goal isn’t the same.
>  
> - RSVP was designed independently of any network architecture offering a QoS such as IntServ for example. It is RFC 2210 that defines how to implement the Qos of the IntServ architecture using the RSVP protocol / the setup connection must also be independent of any quantum network architecture
> - Reservation at the request of the receiver like setup connection which use the recipient to establish rules and Bell pairs distribution
> - RSVP is not a routing protocol. It must be integrated with routing and admission control functions. Connection Setup also needs the support of a routing protocol to reach the receiver.
>  
>  
> <image001.jpg>
>  
> Messages :
>  
> Path: setting the path (logical state).
> Resv: reservation request.
> ResvTear: deletes the reservation status
> PathTear: clears the path state.
> ResvErr: reservation error,
> PathErr: path error.
> ResvConf: reservation confirmation.
>  
> <image004.jpg>
>  
> /Patrick
>  
> -----Message d'origine-----
> De : Qirg <qirg-bounces@irtf.org> De la part de Frédéric Grosshans
> Envoyé : mardi 12 novembre 2019 12:50
> À : Patrick Gelard <patrick.gelard.59@gmail.com>; qirg@irtf.org; Gelard Patrick <Patrick.Gelard@cnes.fr>
> Objet : Re: [Qirg] Multipatite entanglement
>  
> Hi Patrick,
>  
> Le 11/11/2019 à 09:04, Patrick Gelard a écrit :
> > Now regarding the control plan for deploying such a service, he seems
> > to me that one of the questions is: should we develop a new control
> > plan or adapt some traditional network control plans (e.g Resource
> > Reservation Protocol (RSVP) Mulicast ; SDN ; etc.) that could do the job?
> > 
> My problem with this is that I’m a physicist with a really elementary knowledge (if any!) of network protocols. For example, in the theoretician’s protocol we designed with Clément Meignant and Damian Markham, [arXiv:1811.05445 https://arxiv.org/abs/1811.05445],a key ingredient of GHZ state generation (which is a primitive for the following) is to find a subtree of the network linking the end-nodes.
> The operation on nodes of the tree are then local, and look a bit like entanglement-swapping for a repeater line, bit on a tree.
>  
> I guess the control plan would look a lot like the one for multicast, but it‘s pure speculation from me.
>  
>  
> Cheers,
>  
>         Frédéric
>  
> _______________________________________________
> Qirg mailing list
> Qirg@irtf.org
> https://www.irtf.org/mailman/listinfo/qirg
> _______________________________________________
> Qirg mailing list
> Qirg@irtf.org
> https://www.irtf.org/mailman/listinfo/qirg