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

["Diego R. Lopez" <[e-mail]>]

Hi,

Just a reflection on the last statement made by Patrick, in the hope we continue the convergence path we seem to have initiated during the meeting yesterday

Patrick said:
[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

And I’d like to propose we talk about:

  *   A control plane, probably qualifying it as “quantum control plane”, as it is essentially not different from a classical control plane, with the difference of the plane being controlled
And

  *   A quantum plane, that is the equivalent to a classical data plane. I think the differences here are big enough to use a different denomination.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/

e-mail: [e-mail]<mailto:[e-mail]>
Tel:         [phone]
Mobile:  [phone]
----------------------------------

On 20/11/2019, 15:58, "Qirg on behalf of Gelard Patrick" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:

Hi dino,

In the text.

/Patrick

De : Dino Farinacci <[e-mail]>
Envoyé : mercredi 20 novembre 2019 04:12
À : Gelard Patrick <[e-mail]>
Cc : [e-mail]; Frédéric Grosshans <[e-mail]>; Rodney Van Meter <rdv=[e-mail]>
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<https://tools.ietf.org/html/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.

Dino



On Nov 19, 2019, at 8:40 PM, Gelard Patrick <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> De la part de Frédéric Grosshans
Envoyé : mardi 12 novembre 2019 12:50
À : Patrick Gelard <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Gelard Patrick <[e-mail]<mailto:[e-mail]>>
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<https://arxiv.org/abs/1811.05445%5d,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

[e-mail]<mailto:[e-mail]>

https://www.irtf.org/mailman/listinfo/qirg
_______________________________________________
Qirg mailing list
[e-mail]<mailto:[e-mail]>
https://www.irtf.org/mailman/listinfo/qirg

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição