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

Gelard Patrick <Patrick.Gelard@cnes.fr> Wed, 20 November 2019 07:57 UTC

Return-Path: <Patrick.Gelard@cnes.fr>
X-Original-To: qirg@ietfa.amsl.com
Delivered-To: qirg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24FDA120869 for <qirg@ietfa.amsl.com>; Tue, 19 Nov 2019 23:57:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13_mAWfna198 for <qirg@ietfa.amsl.com>; Tue, 19 Nov 2019 23:57:52 -0800 (PST)
Received: from mx2.cnes.fr (mx2.cnes.fr [194.199.174.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3866912082F for <qirg@irtf.org>; Tue, 19 Nov 2019 23:57:51 -0800 (PST)
X-IronPort-AV: E=Sophos; i="5.69,221,1571702400"; d="scan'208,217"; a="30978117"
X-IPAS-Result: A2EgAAC48NRd/wEBeAplGgEBAQEBAQEBAQMBAQEBEQEBAQICAQEBAYFtAgEBAQELAYEbgQRZE1QhEioKg2BAkRuJWJFCDwkBAQEBAQEBAQEgAQwHAQIBAYRAAheCECQ3Bg4CEAEBAQQBAQEBAQUCAQECAmmEa0wMhiYBAQEBAgEBAQoMCwpBBgUFCwIBBQECDQUQFgMEAwICAh8GCxQDDgIEDgUIE4MIgXlNAw4gD5Q1mn51gTIahB8BAwKDTQ2CJQaBNgGBZIxHgRABRoJMPoEEgRdHAQECAYFgBQcJHwKCWDKCLASQD4VHiUaOHy1BB4E8coI3hGOKHYQzdY1YA4tBinCMEIITkU0kgVgzGidMgmxQEZEKXIhPhT9EMAEBAYEdCI0CAYEOAQE
X-URL-LookUp-ScanningError: 1
From: Gelard Patrick <Patrick.Gelard@cnes.fr>
To: Dino Farinacci <farinacci@gmail.com>
CC: "qirg@irtf.org" <qirg@irtf.org>
Thread-Topic: [Qirg] Similarities between RSVP IETF (RFC 2205) protocol and connection Setup in a Quantum Network
Thread-Index: AQHVn1BO867oiez/TEey0ifZ9KNAj6eTo4aw
Date: Wed, 20 Nov 2019 07:57:47 +0000
Message-ID: <F1E8EFF81FCF1B46AA7CCA3CC4D5E18CA0592A68@TW-MBX-P03.cnesnet.ad.cnes.fr>
References: <F1E8EFF81FCF1B46AA7CCA3CC4D5E18CA0592812@TW-MBX-P03.cnesnet.ad.cnes.fr> <249DECDC-7CBF-4209-B0D7-4C1AE6BC2813@gmail.com>
In-Reply-To: <249DECDC-7CBF-4209-B0D7-4C1AE6BC2813@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tm-as-product-ver: SMEX-11.0.0.4255-8.100.1062-25054.005
x-tm-as-result: No--27.181400-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_F1E8EFF81FCF1B46AA7CCA3CC4D5E18CA0592A68TWMBXP03cnesnet_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/qirg/bZsoAOFLPHjEOAM39LK432WzDO4>
Subject: Re: [Qirg] Similarities between RSVP IETF (RFC 2205) protocol and connection Setup in a Quantum Network
X-BeenThere: qirg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Quantum Internet \(proposed\) RG" <qirg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/qirg>, <mailto:qirg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/qirg/>
List-Post: <mailto:qirg@irtf.org>
List-Help: <mailto:qirg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/qirg>, <mailto:qirg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Nov 2019 07:57:56 -0000

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<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.
[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<mailto: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<mailto: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<mailto:patrick.gelard.59@gmail.com>>; qirg@irtf.org<mailto:qirg@irtf.org>; Gelard Patrick <Patrick.Gelard@cnes.fr<mailto: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<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

Qirg@irtf.org<mailto:Qirg@irtf.org>

https://www.irtf.org/mailman/listinfo/qirg
_______________________________________________
Qirg mailing list
Qirg@irtf.org<mailto:Qirg@irtf.org>
https://www.irtf.org/mailman/listinfo/qirg