Re: [Qirg] Some comments on draft-kaws-qirg-advent-03; a possible path forward in QIRG using ideas based on MPLS-TE

Gelard Patrick <Patrick.Gelard@cnes.fr> Fri, 29 March 2019 17:46 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 0B2D91202AD for <qirg@ietfa.amsl.com>; Fri, 29 Mar 2019 10:46:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 9uAc-WgCJkCP for <qirg@ietfa.amsl.com>; Fri, 29 Mar 2019 10:46:47 -0700 (PDT)
Received: from mx1.cnes.fr (mx1.cnes.fr [194.199.174.200]) (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 A690B12008A for <qirg@irtf.org>; Fri, 29 Mar 2019 10:46:46 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.60,285,1549929600"; d="scan'208";a="6775121"
X-IPAS-Result: A2FNAAABWZ5c/wEBeApkHAEBAQQBAQcEAQGBUgYBAQsBgWGBBhGBKgqEBJ8LjwQUgWIFKAuESQIXhUM1CA0BAQMBAQEIAQMCAgKBBQyFTAIBAwEBIRE6CxACAQgNDQIGCw4HAgICHwYLFRACBAENBQgTgwiBXQMkqTCBLxqDawGDeQ2CGgWBCyQBgVqLboEQAUaCTD6CGkcBgR0JBBEHAQEKFj2CSzGCJgOKN4JHmA42BwKBIo5zg1lpimcDiFWLOIdLjXQBggwzGidMgmyCQIhMhQgBNnIBAY4MAQ6BH4EfAQE
X-URL-LookUp-ScanningError: 1
From: Gelard Patrick <Patrick.Gelard@cnes.fr>
To: Bruno Rijsman <brunorijsman@gmail.com>, Kireeti Kompella <kireeti.kompella@gmail.com>, Melchior Aelmans <maelmans@juniper.net>, "s.d.c.wehner@tudelft.nl" <s.d.c.wehner@tudelft.nl>, "cristian@redbit.network" <cristian@redbit.network>, "E.A.Dahlberg@tudelft.nl" <E.A.Dahlberg@tudelft.nl>
CC: "qirg@irtf.org" <qirg@irtf.org>
Thread-Topic: [Qirg] Some comments on draft-kaws-qirg-advent-03; a possible path forward in QIRG using ideas based on MPLS-TE
Thread-Index: AQHU5aoFkU+lruHwqkOjsqp5lApaZqYi3MHQ
Date: Fri, 29 Mar 2019 17:46:43 +0000
Message-ID: <F1E8EFF81FCF1B46AA7CCA3CC4D5E18CA04E2FC8@TW-MBX-P03.cnesnet.ad.cnes.fr>
References: <0CEF775A-35F6-4F9A-998B-C8FEB037A985@gmail.com>
In-Reply-To: <0CEF775A-35F6-4F9A-998B-C8FEB037A985@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-24520.001
x-tm-as-result: No--25.733400-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/qirg/TTtJEOXsdbw8ohdWt2d7y1AycwQ>
Subject: Re: [Qirg] Some comments on draft-kaws-qirg-advent-03; a possible path forward in QIRG using ideas based on MPLS-TE
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: Fri, 29 Mar 2019 17:46:51 -0000

Dear Bruno,

The analogy appears relevant. 

 >> (1) In both cases, a "path" is established a-priori, in anticipation of the future exchange of "traffic". I put traffic in quotes, because in the case of a quantum network, the "traffic" consists of consuming the Bell pairs for (e.g.) teleportation, and not actually sending more quantum photons over the optical links.

However, it seems to me that a preliminary step is required for quantum networks.  Distribute the bell pairs regularly to all the repeaters forming the quantum internet network. It is only when these quantum resources are available, that you can establish an MPLS path (label-switched path : LSP), which will propagate the entanglement.

In addition, this "quantum LSP , that is reduced to the end to end logical entanglement link,  has a limited lifetime due to quantum decoherence.

/Patrick

-----Message d'origine-----
De : Qirg <qirg-bounces@irtf.org> De la part de Bruno Rijsman
Envoyé : jeudi 28 mars 2019 22:05
À : Kireeti Kompella <kireeti.kompella@gmail.com>; Melchior Aelmans <maelmans@juniper.net>; s.d.c.wehner@tudelft.nl; cristian@redbit.network; E.A.Dahlberg@tudelft.nl
Cc : qirg@irtf.org
Objet : [Qirg] Some comments on draft-kaws-qirg-advent-03; a possible path forward in QIRG using ideas based on MPLS-TE

Dear authors of draft-kaws-qirg-advent-03,

I have reviewed your draft "Advertising Entanglement Capabilities in Quantum Networks" (draft-kaws-qirg-advent-03) and I would like to provide some feedback.

Rather than nit-picking the details of the draft, I think it would be more useful to share my views on how this fits into the bigger scheme of things and to discuss the potential for the Quantum Internet Research Group (QIRG) to pick this up and take it forward.

First some general observations. I briefly discussed these observations in the Quantum Internet hackathon at the IETF-104 in Prague, but I would like the bring this discussion into a broader forum (namely this mailing list).

In terms of the "forwarding plane", clearly the quantum internet is completely different from the classical internet. Instead of on-demand sending classical bits from A to Z (as we do in the classical internet), the quantum internet is all about a-priori establishing Bell pairs (non-classical qubits) between A and Z, which can later be consumed by quantum key distribution or which can be used for teleporting qubits with arbitrary state for distributed quantum computation etc.

But in terms of the "control-plane" requirements, I see a lot of parallels between the requirements for quantum networking and the requirements for Multi-Protocol Label Switching Traffic Engineering (MPLS-TE) in classical networking. I think that the approach that you take in your draft is very consistent with that observation.

First, let me elaborate what I mean when I say that I see a parallel between quantum networking and MPLS-TE:

If you squint your eyes hard enough, you can compare the establishment of a Label Switched Path (LSP) in MPLS-TE with establishment of Bell pair between a pair of quantum nodes:

  (1) In both cases, a "path" is established a-priori, in anticipation of the future exchange of "traffic". I put traffic in quotes, because in the case of a quantum network, the "traffic" consists of consuming the Bell pairs for (e.g.) teleportation, and not actually sending more quantum photons over the optical links.

  (2) In both cases, the path involves multiple hops: Label Switch Routers (LSRs) in the case of classical networks, and quantum repeaters in the case of quantum networks.

  (3) In both cases, the operation at each hop is a swap operation: a label swap in the case of classical networks, and an entanglement swap in the case of quantum networks. I have to admit that this parallel is a little bit cheeky, more related to a coincidental use of the same word than anything more fundamental. In the case of MPLS, the swap take place at forwarding time in the forwarding plane, whereas in the case of quantum networks the swap is an entanglement swap which takes place a-priori when the Bell pair is established end-to-end.

  (4) In both cases, the "path" is established with certain quality of service parameters. In the case of MPLS, these include things such as bandwidth and the presence of fast re-route protection. In the case of quantum networks, this includes the size of the pool of Bell pairs, and the fidelity of the Bell pairs.

  (5) In both cases, there is a "traffic engineering function: there is some scarce resource that is consumed by applications, and there is an allocation function that controls which share of that scarce resource gets assigned to each application. In the case of classical networks, that scarce resource is bandwidth, in the case of quantum networks that resource is Bell pairs.

  (6) In both cases, there is a need to distribute information about the availability of the scarce resource in the network. In the case of MPLS, we have traffic engineering extensions to Open Shortest Path First (OSPF-TE) and to Intermediate System to Intermediate System (ISIS-TE) to signal the availability of bandwidth at each node. For quantum networks we need some similar mechanism to distribute the availability of Bell pairs at each node. Just as bandwidth changes dynamically, the availability of Bell pairs changes dynamically as well due to de-coherence etc.

  (7) In both cases, there is a need to distribute information about the capabilities of the nodes in the network. In the case of MPLS, information is needed about whether or not MPLS is supported, what mode of MPLS is supported, what retention mode, etc. etc.  In the case of quantum networks, we need to know about thing just as number of communication qubits, number of storage qubits, distillation scheme etc. etc. (which is precisely the topic of your draft).

  (8) In both cases, there is a routing function to determine the optimal route for each path. In the case of MPLS, the Constrained Shortest Path First (CSPF) algorithm is used to compute a path from A to Z that meets the bandwidth requirements of the LSP while at the same time not consuming more than the remaining bandwidth at each hop on the path. In quantum networks, we need a similar routing function to compute the optimal path from A to Z with entanglement swaps at the intermediate hops in such a manner that the requirements of the end-to-end "path" (e.g. the fidelity and number of Bell pairs on A and Z) can be supported by the available capabilities and resources (local pools of Bell pairs) on the intermediate hops.

  (9) In both cases, the solution can be optimized by pro-actively monitoring the application behavior and dynamically adjusting the paths based on the observed application needs. In the case of classical MPLS networks we have auto-bandwidth, where the size of each LSP in a full edge-to-edge LSP mesh is dynamically adjusted based on the observed traffic patterns. In a quantum network, the paths (i.e. the pre-establishment of Bell pairs) could be dynamically optimized based on the actual consumption of Bell pairs by quantum applications.

If we accept the similarity between MPLS-TE and the requirements for the control plane of a quantum network, then this hints to a possible approach for designing the control plane protocols for quantum networks:

  (1) We need something similar to OSPF-TE or ISIS-TE to:

    (1a) Distribute information about the topology of the quantum network (quantum nodes and quantum links, which form a separate topology parallel to the classical topology)

    (1b) Distribute information about resource availability in the quantum network (local Bell pairs on nodes A, B, C, ..., Z) that are available for entanglement operations (either the number or the current production rate).

  (2) Some protocol (OSPF or ISIS in the proposal in this draft) to advertise the capabilities of each node (# communication qubits, # storage qubits, distillation scheme, etc.)

  (3) The equivalent of CSPF to compute the optimal path from A-Z, taking into account the path requirements (e.g. fidelity and production rate of the end-to-end qubit), the capabilities of each node, and the availability of resources on each node.

  (4) We need something similar to RSVP-TE to actually signal the quantum "path" (i.e. to establish end-to-end Bell pair on nodes A and Z).

My apologies for the long mail, but my hope is that some useful ideas about a possible path forward can be taken from it.

Personally, I am very excited about the establishment of the QIRG and I truly expect great things will come out of the collaboration between traditional network engineers and quantum internet physicists. 

— Bruno




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