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

I think you don’t need any of these mechanisms. If you look at the follownig topologies, all you need is for the the two QRs to talk to each other. They are nothing more than two hosts on an IP network connected via two CRs:

QR —— CR ——- CR —— QR

It is overkill to use RSVP and SR. They are protocols to route packets. If you use SR, you don’t need to construct a path between two QRs. All the QRs need to do is talk to each other. And you can pair up QRs with an app level path mechanism.

Dino

> On Nov 20, 2019, at 3:57 PM, Gelard Patrick <Patrick.Gelard@cnes.fr> wrote:
> 
> Hi dino,
>  
> In the text.
>  
> /Patrick
>  
> De : Dino Farinacci <farinacci@gmail.com> 
> Envoyé : mercredi 20 novembre 2019 04:12
> À : Gelard Patrick <Patrick.Gelard@cnes.fr>
> Cc : qirg@irtf.org; Frédéric Grosshans <frederic.grosshans@lip6.fr>; Rodney Van Meter <rdv=40sfc.wide.ad.jp@dmarc.ietf.org>
> Objet : 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. 
> [PG]Yes, This is what I mention when I write “RSVP is not a routing protocol. It must be integrated with routing”.  Just as for the point to point where a path must first be established. Just as for the establishment of quantum network connection as recalled in Rodney's presentation : Stages of the Problem!•Need to select a path (routing) https://arxiv.org/1206.5655
>  
> Note that the key issues of Inserv and RSVP is scaling.
> For point-to-point, there is also a scaling problem for its use in traffic engineering of the MPLS protocol (RSVP-TE : describes the use of standard RSVP [RFC2205] to  establish Label Switched Paths (LSPs)). Moreover, concerning the traffic engineering of MPLS, the per-connection traffic steering model of MPLS-TE does not easily exploit the load balancing offered by Equal Cost MultiPath (ECMP) routing in plain IP networks. In addition to other problems, this led IETF (SPRING) to define the concept of “segment Routing” (SR :  https://tools.ietf.org/html/rfc8402 ) ;  A concept that can be useful in establishing the path selecting quantum repeaters.
>  
> The Segment Routing offers an innovative and simple approach to enable traffic engineering. Additional information is simply placed in the packets that will condition their processing: a list of segments is added in each datagram and defines the network path that must be used. Segment Routing thus offers a very simple option for the implementation of traffic engineering without the need for additional states on the equipment, which allows to add a large number of rules without overloading the routers and complicating the infrastructure operation. The SR architecture can leverage both distributed and centralized network control paradigms to provide efficient network solutions, and thus in a centralized network control the programmability from controllers, which is a prerequisite for SDN infrastructures.
>  
> Good entry point for SR : “Segment Routing: a Comprehensive Survey of Research Activities, Standardization Efforts and Implementation Results” https://arxiv.org/abs/1904.03471 
>   
>  
> 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. 
> [PG]CR could be in path of the control plan of quantum network, but not in the data plane (i.e quantum channel). It should be noted that can use also quantum channel to encode classical information (bits. For example dense coding) and thus to transport the control plan
>  
> 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