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

Bruno Rijsman <brunorijsman@gmail.com> Thu, 28 March 2019 21:05 UTC

Return-Path: <brunorijsman@gmail.com>
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 5893712037E for <qirg@ietfa.amsl.com>; Thu, 28 Mar 2019 14:05:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 DURoUtOOIGOo for <qirg@ietfa.amsl.com>; Thu, 28 Mar 2019 14:05:35 -0700 (PDT)
Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41D3D12003F for <qirg@irtf.org>; Thu, 28 Mar 2019 14:05:35 -0700 (PDT)
Received: by mail-qt1-x844.google.com with SMTP id t28so213888qte.6 for <qirg@irtf.org>; Thu, 28 Mar 2019 14:05:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=P2YG2h4ruT+gRUhjVTTNSBz+2ktz+m3r2lZxodXjPoI=; b=HWniGa9faDNFAhuLZH6nRaoqnX2T91K0s5AC2iwW1J5AO4YgMMYsqsT6pYZIPSNEkp TEAMByqtpuR4PEF6yhzEs7up5Wlba6st7gTnbkjwdJNFOiXsRbVJdt6v6S6lr79iVyhO r6Nn7L3ZH2yef7PmVIV8ByRB/T2/JUALitpeW/1DnA3Yv8aEWetnCRH7s7hLS5nhjImv jR6xP+JUtfbMX2LJuVUIqLSMJ7mN6ukwYGTCkF8yV7XkFDmlFvYeKIJlau7THUw1tmCE hkubF6GLlSopNfacv/UkDah/O4D+0gSi7fmDXs6FFg199A+il+4+yswhgdYQEp/D/7pG mZoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=P2YG2h4ruT+gRUhjVTTNSBz+2ktz+m3r2lZxodXjPoI=; b=rQiMqhndgpgh+/E225RUEa8xN7HPeddXNlu0t0NT0U0pZhybHhZChE939nQQ3Pj9oQ lgJ6hxrXgiCWK8c6o/Kpg/mgiXdbUhm7gSUOBdF70FyfbIC4iV+8GvtcJJGyf+44qzpB L3eMMJz+1b5Yoqrd0OnCBTa5bpgunSZAb3brNrVGgqGQ2plFLJHT5DEbKEI/Hhd3F9pH S+NcTuVHUmICTKWbuI+K+IwitNOIherde9ECdOxQdVgQVFszvjUXtc1WfeWELhkRmCPr 82WCtGTNA9hzYpKA8uaSNB+ug4HcaJhHKWZnbvushTTu1U+LDAqlAH/qz+qxbOtS9mKj ITMA==
X-Gm-Message-State: APjAAAUyZm83/mvfZt+OuyaYrWkdA3xqP5hvLmnGlCfKhKRCAh8QFjvx ooDjjBJ8p5kHMI1Iv9GJV/U=
X-Google-Smtp-Source: APXvYqzdfYtyphtNoMNAsSM5diqEKd5YGzd/Ryh0AUvh1QRxGftCv+69CqSUEYwYswKtdNeU/QprnA==
X-Received: by 2002:a0c:baa0:: with SMTP id x32mr37904407qvf.79.1553807134150; Thu, 28 Mar 2019 14:05:34 -0700 (PDT)
Received: from [192.168.20.114] ([200.63.168.130]) by smtp.gmail.com with ESMTPSA id c84sm99282qke.0.2019.03.28.14.05.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Mar 2019 14:05:33 -0700 (PDT)
From: Bruno Rijsman <brunorijsman@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Message-Id: <0CEF775A-35F6-4F9A-998B-C8FEB037A985@gmail.com>
Date: Thu, 28 Mar 2019 18:05:28 -0300
Cc: qirg@irtf.org
To: 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
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/qirg/yY3VS9NiosbqbSnB8kJdjNuuLdw>
Subject: [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: Thu, 28 Mar 2019 21:05:38 -0000

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