QIRG | K. Kompella |
Internet-Draft | M. Aelmans |
Intended status: Standards Track | Juniper Networks, Inc. |
Expires: September 28, 2019 | S. Wehner |
QuTech | |
C. Sirbu | |
Redbit Networks | |
A. Dahlberg | |
QuTech | |
March 27, 2019 |
Advertising Entanglement Capabilities in Quantum Networks
draft-kaws-qirg-advent-03
This document describes the use of link-state routing protocols on classical links in Quantum Networks. It contains proposals for additions to the IS-IS and OSPF protocols in order for them to transport relevant information for a Quantum Network, specifically, for the creation and manipulation of entangled pairs. The document will describe some of the necessary attributes and some suggestions of how this information may be used.
No Schrodinger’s cats were harmed in the creation of this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 28, 2019.
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Quantum networking is an emerging field using the strange (even counterintuitive) properties of quantum mechanics to bring new, useful capabilities to computing and networking. One of these is “entanglement” [8], where the state of a group of particles must be described as a unit -- it cannot be decomposed to the state of each particle independently. Entangled pairs (often called EPR pairs, abbreviated here as EP) of particles can be used for quantum teleportation [10] and for quantum key distribution (QKD) [14].
A Quantum Network consists of quantum nodes and links. Here, we will be concerned with controllable quantum nodes (CQN) that allow control decisions. We posit a classical network parallel to the quantum network, with classical nodes (CN) and links. A classical node is colocated with a quantum node; a classical link may be a fiber or wavelength parallel to the corresponding quantum link. The existence of such a classical link is required by most quantum methods to create EPs deterministically or in a heralded fashion, where the creation of EPs is conditioned on a specific signal. To make useful decisions, it is desirable to augment this data to describe the capabilities and states of quantum nodes and links. At current time there is a need for classical links besides quantum links. In the future this might change into a situation where classical links will perhaps become obsolete.
This document proposes to carry entanglement capability data as Type Length Values (TLVs) over IS-IS or OSPF link-state advertisements over the corresponding classical network. A subset of the CQNs may run quantum applications such as QKD; these nodes may want to initiate multihop EPs.
Once an EP is created, the state of one particle (“quantum bit” or qubit) of an EP can be transferred to another qubit within the same QN by a process known as swapping or a SWAP gate ([12]). Also, several pairs of imperfectly entangled qubits can be “distilled” ([13]) to fewer but “better entangled” qubits.
Long distance entanglement can be produced from piecewise short distance entanglement: Given an EP between CQN A and CQN B, and another EP between CQN B and CQN C, one can create an EP between CQN A and CQN C by a process known as an “entanglement swap”. These operations can be used to manipulate EPs to improve their lifetimes or their quality, or to create multihop EPs. Physically, qubits can be realized in many ways. For example, they can be represented by the energy levels of Nitrogen Vacancy (NV) Centers in diamond ([16], [17]). Logically, a qubit can be classified as a “communication qubit”, a “traveling qubit” or a “storage qubit”.
This document primarily discusses the exchange of quantum capabilities over a classical network. Some illustrative examples of how these capabilities can be used in a quantum network may be given, but this document should not be considered authoritative on these procedures.
ent(c@A, c@B) -> [[c@A, c@B]]
swap(c@A, s@A)
dist([[c1@A, c1@B]], [[c2@A, c2@B]]) -> [[c3@A, c3@B]]
entSwap([[c@A, c1@B]], [[c2@B, c@C]]) -> [[c@A, c@C]]
ent(c@A, c@B) -> [[c@A, c@B]] # entangle swap(c@B, s@B) -> [[c@A, s@B]] # swap EP to storage qubit ent(c@B, c@C) -> [[c@B, c@C]] # use freed up qubit c@B entSwap(c@A, c@B) -> [[s@B, c@C]] # create multihop EP
The following terms are used in this document:
X - Y - Z . . A B A, B: QEN . . U --- V X, Y, Z, U, V: CQNs
Consider the following (very simple) quantum network consisting of QENs A and B, and CQNs X, Y, Z, U, V. The goal is to create an EP between qubits at A and at B, perhaps for the high-level task of QKD between A and B.
From A's point of view, here are a number of questions:
This document aims to provide all CQNs in a quantum network with the information they need to answer such questions, and to create EPs at their desired fidelity and speed.
A CQN contains one or more communication qubits and one or more storage qubits. Many proposals exist for producing EPs between remote quantum nodes (see for example [16], [17], [18], [20]). Abstractly, these result in the generation of EPs with fidelity F after an expected time t. To give an example, we describe the generation of EPs that has been implemented in NV in diamond ([16]), and Ion Traps ([18]). The largest distance for producing long-lived entanglement is presently 1.3kms ([17]). To entangle a pair of communication qubits, the QNs send carefully timed photons towards the HS. If the process is successful, HS sends an OK message to both QNs.
+----------+ +----------+ | | c-chan +------------+ c-chan | | | Control- | <-------> | Heralding | <-------> | Control-| | lable | | Station | | lable | | Quantum | *~~~~~~~> | | <~~~~~~~* | Quantum | | Node | q-chan +------------+ q-chan | Node | | A | | B | | | <----------------------------------> | | +----------+ classical network control plane +----------+
The classical network control plane is of particular interest here as it would be used by the proposed protocol to advertise and exchange information about the capabilities of the CQNs to generate entanglement. This classical channel exists between all CQNs and is shared with other application specific control and data plane traffic.
resulting entanglement *~~~~~~~~~~~~~~~~~~~~~~~~~~~~* +-+ +-+ +-+ |A+----------------------------+B+----------------------------+C| +-+ A-B Link properties +-+ +-+ [(F1,t1), (F2,t2)] Node B properties: - Number of Communication Qubits - Number of Storage Qubits Node capabilities (operations): - Swap comm <-> storage - Entanglement swap - [(Distillation scheme, time)...]
In the figure above, an example request for an entangled pair between nodes A and B will be affected by the following properties:
resulting entanglement *~~~~~~~~~~~~~~~~~~~~~~~~~~~~* *~~~~~~~~~~~~~~~~~~~~~~~~~~~~* +-+ +-+ +-+ |A+----------------------------+B+----------------------------+C| +-+ +-+ B-C Link properties +-+ [(F1,t1), (F2,t2)]
A new EP creation between CQNs B and C will similarly be affected by the same parameters as above.
*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* +-+ +-+ +-+ |A+----------------------------+B+----------------------------+C| +-+ +-+ +-+ Node B entanglement swap operation
And finally, with an entanglement swap operation at node B (which is a node specific capability and has a specific duration) we end up with an A-C EP:
If a pair of CQNs A and B share a number of EPs of insufficient quality, they may be combined into a single EP of higher quality by distillation. To do so, these CQNs need to agree on which distillation scheme to use before distillation can proceed. This does not necessarily need to be via communication between A and B, if one agrees upon a deterministic procedure of selecting one. This document suggests the following procedure:
2:1 distillation (S,t,p) *~~~~~~~~~~~~~~~~~~~~~~~~~~~~* *~~~~~~~~~~~~~~~~~~~~~~~~~~~~* +-+ +-+ +-+ |A+----------------------------+B+----------------------------+C| +-+ A-B Link properties +-+ +-+ [(F1,t1), (F2,t2)]
Given a chosen distillation scheme (S,t,p), an additional time delay will be added for the actual operation: For a 2:1 distillation scheme between nodes A and B, 2 EPs need to be produced followed by an operation on A and B that produces 1 EP. This operation will take time some expected time t, and succeed with probability p.
We are interested in exposing the properties of CQNs (including QENs) to allow sophisticated decision making, for example in the creation of entanglement. These properties include:
Note that several other parameters can be advertised, such as the T1 and T2 times for a qubit’s decoherence. These are omitted for now, instead just giving the decay of the fidelity of an EP. If deemed useful, T1 and T2 times can additionally be advertised.
A list of (Fn,tn) pairs describing the tradeoffs of a possible entanglement produced by two nodes (the ends of said link): tn is the time to produce an entangled pair with fidelity Fn.
The routing protocols IS-IS and/or OSPF could be used in order to advertise entanglement capabilities. This section describes the additional data fields needed in order to facilitate the objective.
This document suggests the use of a link-state protocol to distribute the capabilities of CQNs to create entanglement. This section offers a short introduction to link-state protocols for those not familiar with them.
Consider a directed graph G=(V, E) with vertices (nodes) V and edges (links) E. Consider also G'=(V', E'); there is a 1-1 mapping from V' to V and from E' to E such that e1' = (v1', v2') is in E' iff e1 = (v1, v2) is in E and v1' maps to v1 and v2' maps to v2. G' represents the quantum network; V' represents the set of CQNs, and E' the set of quantum links between pairs of CQNs; G represents a classical network parallel to G'; that is, each CQN v' has a corresponding classical node v. v plays a dual role: it is the control node for v', and proxies on behalf of v' in the link-state protocol.
The basic objective of a link-state protocol is to "flood" properties of nodes and (directed) links to all nodes in the network. This is accomplished by means of "link-state advertisements" (LSAs) that each node originates and sends to its immediate neighbors. The neighbors in turn send received LSAs to their own neighbors; this process repeats until every node receives every LSA (hence the term "flooding"). The focus of LSAs is the link properties (hence _link-state_ advertisements), although node properties are also advertised. There are mechanisms to prevent looping of LSAs, and for reliable flooding. There is also a sequence number by which a more recent update of an LSA can be identified as such, and a mechanism for "aging out" LSAs belonging to nodes no longer in the network. In what follows, quantum node and link properties are added to the link-state advertisements of the corresponding classical node. Note that link properties need not be symmetric; that is, the link properties of (v, w) need not be the same as those of (w, v).
The net result of flooding is that every node has the same picture of the network (modulo LSAs in flight); in particular, each node knows the overall topology and connectivity of the network, and can use this information to make decisions. In a classical network, such a decision could be to compute a shortest path; for the quantum network, it could be choosing a feasible path (i.e., sequence of CQNs) for a multihop entanglement. Note that a node doesn't really know when it has complete and up-to-date information about the network; LSA updates may be originated at any time. Usually, this is okay: for example, if a node v learns enough of the network to have a path to another node w, it can compute a multihop entanglement to w. Subsequent updates may provide a more optimal (or higher probability) entanglement path. There are heuristics one can apply to guess that the link-state database (LSDB) (i.e., the union of all LSAs) is complete-ish; however, as nodes (and links) can fail or disconnect, there really is no such thing as "the full LSDB".
Each node v is identified by a "router ID" (an IP address uniquely allocated to v), denoted by rid(v). A link L = (v, w) is identified by (rid(v), i) where i is an index allocated by v for L unique for each link emanating from v. (L may also be identified by IP addresses, but we'll ignore that for now.) It is generally expected that a directed link (v, w) is matched by a link (w, v); if not, (v, w) is ignored from subsequent consideration; in particular, no link properties are advertised for this link by v. Note that a pair of nodes may have multiple links between them; for simplicity, the notation will not be extended to indicate this. We'll assume rid(v') = rid(v) and the index allocated to a quantum link e' is the same as that of the corresponding classical link e.
Let v, w be a pair of neighboring nodes, and let L1 = (v, w) and L2 = (w, v) in E be directed links in opposite directions between v and w with identifiers (rid(v), i1) and (rid(w), i2) respectively (where i1 is the index allocated for L1 by v, and similarly for i2)). As a first step in running a link-state protocol, v runs a "hello protocol" all its links; in particular, over L1. Similarly, w will run the hello protocol over L2. The hello protocol serves to exchange the indices i1 and i2, and thus identify (rid(v), i1) as the reverse link of (rid(w), i2). This allows both v and w to correlate the link properties of L1 and L2. If the hello protocol fails between v and w, neither node includes link properties for the link in their LSAs.
Once the hello protocol has been run on all links, v starts the process of generating and sending its own LSA over all its links, and of receiving the current LSDB from its neighbors. Note that an LSA originated by v must propagate unchanged across the network; only v is allowed to change it (and such a change must be accompanied by updating the LSA's sequence number). Such an update is triggered by a new link coming up, an existing link going down, or a node or link property changing.
IS-IS and OSPF are in principle similar, although the details of the protocol mechanisms and encodings vary. In both protocols, a Type-Length-Value (TLV) is used to encode most node and link properties. In IS-IS, TLVs are used for all properties, and a single type of LSA is used; in OSPF, there are several types of LSAs, and many (but not all) properties are encoded as TLVs.
[1] has examples of "standard" LSAs for routing; [4] has the so-called Traffic Engineering LSAs.
Here, we give a protocol-independent description of quantum node properties; later documents will specify the encoding specifically for IS-IS and OSPF.
Note that the following list of node properties is a strawman; all details are subject to change, and other properties may be added as needed.
<Qubit-TLV><NCQ><NSQ> <CS-Swap><Prob><ExecTime> <Ent-Swap><Prob><ExecTime> <Measure><Prob><ExecTime> <NDistSch><DistScheme1><DistScheme2>
The following node properties are added to the appropriate LSA:
<N-Ent-TO><time1><fid1><time2><fid2>...
Only one link property is listed. It gives the time-fidelity tradeoffs of an entanglement operation as a list:
Note that this link property is symmetric, as entanglement is initiated simultaneously at v and w.
It is not anticipated that adding these extensions to IS-IS and OSPF will present new security hazards to those protocols. Since however a common application of entangled pairs is for security purposes (such as QKD), it is worth investigating whether this application places a higher burden of security on the underlying protocols.
The authors would like to thank the following people for their contributions and support to this document: Vesna Manojlovic, Marcello Caleffi and Rodney Van Meter. Kompella would also like to thank Bruno Rijsman for encouraging him to learn about Quantum Computing and Networking.
_,'| _.-''``-...___..--';) /_ \'. __..-' , ,--...--''' <\ .`--''' ` /' `-';' ; ; ; __...--'' ___...--_..' .;.' (,__....----''' (,..--''
Also:
It could be worth investigating the use of a distance-vector routing protocol to limit flooding.
There are no requests as yet to IANA for this document.
[1] | Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10.17487/RFC1195, December 1990. |
[2] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
[3] | Katz, D., Kompella, K. and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003. |
[4] | Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008. |
[5] | Ishiguro, K., Manral, V., Davey, A. and A. Lindem, "Traffic Engineering Extensions to OSPF Version 3", RFC 5329, DOI 10.17487/RFC5329, September 2008. |
[6] | Aggarwal, R. and K. Kompella, "Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions", RFC 5786, DOI 10.17487/RFC5786, March 2010. |