Internet DRAFT - draft-van-meter-qirg-quantum-connection-setup
draft-van-meter-qirg-quantum-connection-setup
Quantum Internet Research Group R. Van Meter
Internet-Draft T. Matsuo
Intended status: Informational Keio University
Expires: March 13, 2020 September 10, 2019
Connection Setup in a Quantum Network
draft-van-meter-qirg-quantum-connection-setup-01
Abstract
Near-term quantum networks will grow to form a Noisy, Intermediate-
Scale Quantum Internet (NISQI). Connection setup will require
adapting behavior along the path to the noise levels of individual
elements. In this proposal, path creation is triggered by an
application at the Initiator, information is accumulated node-by-node
on an outbound pass in a series of QCap (quantum capability) blocks,
then the RuleSets are created at the Responder. RuleSets are
installed at the individual nodes on the return pass. This document
describes the architecture of connection setup in a network. Details
of the RuleSets and QCaps, addressing architecture, link protocols,
routing, resource allocation (multiplexing), extension of this setup
procedure to an internetwork, and extension to multiparty
communications are beyond the scope of this document.
Status of This Memo
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 March 13, 2020.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
Van Meter & Matsuo Expires March 13, 2020 [Page 1]
Internet-Draft September 2019
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Concepts and Glossary . . . . . . . . . . . . . . . . . . . . 3
3. Connection Setup Phases . . . . . . . . . . . . . . . . . . . 5
3.1. Short Description of Phases . . . . . . . . . . . . . . . 5
3.2. Rationale for this Architecture . . . . . . . . . . . . . 5
4. Message Contents and Elements . . . . . . . . . . . . . . . . 6
4.1. PathSetupRequest . . . . . . . . . . . . . . . . . . . . 6
4.2. Quantum Capabilities (QCap) . . . . . . . . . . . . . . . 7
4.3. RuleSets . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Processing the SetupRequest . . . . . . . . . . . . . . . . . 7
5.1. Initiating a Connection Setup Request . . . . . . . . . . 8
5.2. Outbound Processing . . . . . . . . . . . . . . . . . . . 8
5.3. Responder Processing . . . . . . . . . . . . . . . . . . 9
5.4. Return Processing . . . . . . . . . . . . . . . . . . . . 9
6. Rejection and Robustness of the Setup Process . . . . . . . . 9
6.1. Rejection by a Repeater or Router . . . . . . . . . . . . 9
6.2. Rejection by a Responder . . . . . . . . . . . . . . . . 10
6.3. Robustness . . . . . . . . . . . . . . . . . . . . . . . 10
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
Building a connection across a quantum network [theqi] is a classical
task. Because of the low success probability of quantum
communication due to photon loss and the extremely high error rates
due to the fragile nature of quantum information, quantum
communication between two nodes more closely resembles a coordinated
computation distributed among the set of nodes forming the path
Van Meter & Matsuo Expires March 13, 2020 [Page 2]
Internet-Draft September 2019
between the two nodes than a store-and-forward network session
[qnetworking].
Use of the quantum network is driven by applications running at two
(or more) classical nodes. Overall behavior is similar to client-
server computing. The connection is initiated from a node similar to
client and responded to by a node similar to a server. The details
of the sending and receiving of the classical messages are not
specified in this document, but can be modeled as if being sent over
a TCP socket. Messages are assumed to be reliable and delivered in
order. These messages have no hard real time requirement, though the
subsequent data phase of the operation may.
This connection setup process must collect information about the
hardware (channels and buffer memories) to be used, because of the
heterogeneity of the underlying hardware. Loss in optical channels
naturally varies with channel length and other factors, and has a
large impact on quantum communication performance. Individual
quantum buffers holding quantum bits (qubits) will vary in quality,
as well.
1.1. Requirements Language
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 RFC 2119 [RFC2119].
2. Concepts and Glossary
The following terms will be used:
Bell pair a common form of entangled quantum state useful in
communications.
End node a quantum network node with a single interface. End nodes
may have stationary quantum memories, or may be capable only
of measuring photons; this distinction is beyond the scope of
this document.
Entanglement the condition of a group of qubits (typically two
qubits in this document) in a shared state that cannot be
described using only real, non-negative, classical
probabilities.
Entanglement Swapping executed at node B splices an entangled state
shared with node A to an entangled state shared with node C,
creating A-C entanglement and disentangling B from both
nodes.
Van Meter & Matsuo Expires March 13, 2020 [Page 3]
Internet-Draft September 2019
Fidelity a measure of the quality of a quantum state; roughly, the
probability that the system holds the desired state.
Initiator the initiator of the classical process of establishing the
connection by sending a message toward the Responder.
Purification an error detection mechanism on quantum states.
Typically, one quantum state is used to test the condition of
a second state; the first state is destroyed in the process.
If the purification fails, it is unknown whether the first or
second state was in error, and the second state is discarded
as well. If purification succeeds, our confidence in the
state is improved.
QCap an information block describing the quantum capabilities of a
particular node and link.
Qubit a quantum system with two states that can be stored in memory
or transmitted through a channel, manipulated in a
constrained set of operations, entangled with other qubits,
and measured.
Repeater a quantum network node with two interfaces, typically
sitting in the middle of a chain. Repeaters do not require
routing functionality, but otherwise have the same
capabilities as routers. As spacing between nodes may be
required to be as short as ten kilometers, depending on
technology, what would be single fiber hops in a classical
network will be a long chain of repeaters.
Responder is the classical endpoint of the connection setup process,
where the message sent by the Initiator terminates. The
Responder creates the RuleSets for all nodes in the path, and
commonly will be the smarter node.
Router a quantum network node with a more than two interfaces,
requiring routing capability.
RuleSet describes the actions that a nodes should take when certain
conditions occur. The contents of RuleSets are beyond the
scope of this document.
The terms "source" and "destination" are not appropriate at the
connection level in a quantum network, because distributed quantum
states are not necessarily used for the unidirectional transfer of
information. Therefore, we use Initiator and Responder to designate
roles in the connection setup process, but those roles do not not
Van Meter & Matsuo Expires March 13, 2020 [Page 4]
Internet-Draft September 2019
necessarily correspond to any asymmetry during the connection
lifetime. Source and destination are not appropriate because:
1. There may not even be data transferred between nodes; the
entanglement might be used for some shared operation that doesn't
involve qubits moving back and forth via teleportation. Quantum
key distribution (QKD) is an obvious example, where both ends
measure the entangled state and destroy it in order to get a
classical bit.
2. Temporally, operations may not even happen left-to-right along
the chain of repeaters, again violating the notion that data is
moving.
"Source" and "destination" may be used to describe the movement of an
individual classical message.
Links are assumed to be point-to-point. Multidrop physical layers
are possible, but quantum broadcast or multicast are not directly
possible at the physical level, and would have to be emulated.
3. Connection Setup Phases
3.1. Short Description of Phases
The single-network, two-node connection setup procedure consists of
three basic phases:
1. The outbound request is routed from Initiator to Responder using
a standard NextHop-based forwarding table, accumulating
information about the path along the way in a stack of QCaps.
2. When the request arrives at the Responder, the Responder uses
that information to create a complete RuleSet for every node.
The RuleSets are assembled into a stack with the nearest node at
the top.
3. The RuleSets are sent back along the original path, with each
node removing its RuleSet from the message (popping the stack),
then forwarding the remaining QCaps on until it returns to the
Initiator.
3.2. Rationale for this Architecture
The outbound pass collects information about the nodes and links, to
be used by the Responder to formulate the RuleSets. Why is the
information collected in this fashion rather than shared more broadly
across the network, e.g. as part of a modified routing protocol such
Van Meter & Matsuo Expires March 13, 2020 [Page 5]
Internet-Draft September 2019
as OSPF [RFC2328]? Why does a single node create the RuleSets for
all nodes, rather than allowing individual nodes to create their own
RuleSets when they see the PathSetupRequest message?
1. Because Repeaters may be spaced as closely as every 10km, a full
topology for a network listing every Repeater may be excessively
large for routing purposes, but such information is needed for
building RuleSets.
2. The information collected may be substantially larger in volume
than simple link costs.
3. The information collected and used may be too dynamic for a
routing protocol.
4. Sharing of this information can be unnecessary when routing is
driven by policy decisions rather than technical capabilities.
5. Centralization of the RuleSet creation is necessary because all
RuleSets must cooperate toward a single goal, and the correct
breakdown of responsibility cannot be determined from partial
information.
6. Centralization of RuleSet creation allows a Responder to upgrade
its policies independently and to improve the process if its
developers have found better tuning mechanisms. A distributed
mechanism would require that all nodes in the path upgrade at the
same time to avoid the creation of inconsistent policies, and
limit the ability of Responders (often service providers of some
sort) to innovate.
4. Message Contents and Elements
This section outlines the principal information to be carried in the
messages. Detailed packet formats are beyond the scope of this
document, and may vary from network to network.
4.1. PathSetupRequest
At minimum, the PathSetupRequest message must contain:
1. node addresses for the Initiator and Responder
2. the class of service requested [qiroadmap]
3. minimum performance parameters (fidelity and throughput)
Van Meter & Matsuo Expires March 13, 2020 [Page 6]
Internet-Draft September 2019
4.2. Quantum Capabilities (QCap)
A QCap (quantum capabilities) block to be added to the stack in the
PathSetupRequest message describes the functions, performance and
quality of the node and link. This may include:
1. the fidelity of Bell pairs created by the quantum channel
2. the fidelity of local operations performed by the node for
purification or entanglement swapping
3. the rate at which entanglement can be created (Bell pairs per
second)
The details of the required information may differ between networks.
A standardized form of this information for sharing between networks
will be used for internetworking operation.
4.3. RuleSets
A RuleSet block in the stack in the PathSetupResponse message
describes the rules to be executed at each node. A rule consists of
a Condition clause and an Action clause. A Condition clause lists
the existence of particular entangled states, or the reception of
particular messages. The Action clause describes the actions of
purification, entanglement swapping, or even discarding an entangled
state, as appropriate. The details are beyond the scope of this
document.
In order to implement multiplexing schemes (e.g. buffer-space
multiplexing, time-division multiplexing, or statistical
multiplexing) based on the RuleSet-based network architecture, a
RuleSet may include descriptors that define the usable resources for
each link involved in that specific connection.
If a link carries only a single connection, all resources available
may be fully assigned to that single connection to maximize the
throughput. However, a link may receive a second RuleSet generated
for a new connection. In that case, the nodes must be able to
correctly update and reassign the available resources. Further
details of the resource reservation and reclamation process are
beyond the scope of this document.
5. Processing the SetupRequest
Van Meter & Matsuo Expires March 13, 2020 [Page 7]
Internet-Draft September 2019
5.1. Initiating a Connection Setup Request
An Initiator, driven by an application request for quantum network
services between itself and the Responder, builds the
PathSetupRequest, populates the first QCap block, selects the next
hop, and sends the request. Note that there is no need for either
the Initiator or the Responder to know the entire network topology,
only be able to select a next hop appropriately. The details of the
routing are beyond the scope of this document.
5.2. Outbound Processing
Creation of the RuleSets requires knowledge of the number of nodes
involved. A quantum node adds its own address when receiving the
request packet, before sending to the next node. The stack size
indicates how many nodes are involved. Additionally, the RuleSet
creator may require information regarding links between nodes along
the path - e.g. to be used when optimizing the order of entanglement
swapping.
The pseudocode below outlines the processing on receipt of the
PathSetupRequest message.
procedure ProcessFlatPathSetupRequest(Msg)
Msg.HopStack.Push(MyHopInfo)
if (MyAddr != Msg.ConnSpec.Responder)
// Process and forward
NextQuantumHop = GetNextQuantumHop(Msg.ConnSpec.Responder)
LinkInfo = GetLinkInfo(NextQuantumHop)
Msg.HopStack.Push(LinkInfo)
Forward(NextQuantumHop,Msg)
else
// have reached the far end, need to build RuleSets
// for everybody, then return
ReturnMsg = ProcessFlatPath(Msg)
MyRuleSet = ReturnMsg.RuleSetStack.Pop()
InstallRuleSet(MyRuleSet)
NextQuantumHop = ReturnMsg.RuleSetStack.Top.Addr
Forward(NextQuantumHop,Msg)
endif
endprocedure
Note that although we use the term "NextQuantumHop" here, that refers
to a neighboring quantum node, and does not imply that the classical
node's neighbor is necessarily the same; it could, in theory, pass
through multiple nodes to get there.
Van Meter & Matsuo Expires March 13, 2020 [Page 8]
Internet-Draft September 2019
5.3. Responder Processing
The Responder accepts the final PathSetupRequest message with the
complete stack of information about node capabilities and links, and
builds a corresponding stack of RuleSets, one per node in the path.
The Responder's processing is outlined in the "then" clause of the
pseudocode above. The details of this creation process are beyond
the scope of this document, and may be kept secret from other nodes
in the path.
5.4. Return Processing
The pseudocode below outlines the processing on receipt of the
PathSetupReturn message.
procedure ProcessFlatPathSetupReturn(Msg)
MyRuleSet = ReturnMsg.RuleSetStack.Pop()
InstallRuleSet(MyRuleSet)
If (ReturnMsg.RuleSetStack.Size != 0)
NextQuantumHop = ReturnMsg.RuleSetStack.Top.Addr
Forward(NextQuantumHop,Msg)
endif
endprocedure
The RuleSetStack should only be empty after the Initiator node of the
original request removes its RuleSet, so this should be followed by
activating the connection.
6. Rejection and Robustness of the Setup Process
6.1. Rejection by a Repeater or Router
A repeater or router that receives a PathSetupRequest may reject the
request if it has no quantum communication resources available. It
should not reject the request simply because it believes the
requirements of the request (fidelity or rate) to be difficult to
fulfill; that responsibility lies with the Responder.
When a node rejects the PathSetupRequest, it shall inform the other
nodes along the portion of the path that have already received the
PathSetupRequest by creating a PathSetupResponse message with an
error code that indicates failure and sending that message to the
node on the top of the stack. As with a successful
PathSetupResponse, the list of nodes to which the message must be
sent is created as a stack. Other than the addresses and the error
code, the message may be empty; no RuleSets are required. The
Van Meter & Matsuo Expires March 13, 2020 [Page 9]
Internet-Draft September 2019
message is then iteratively returned, with each node popping its own
address and forwarding to the next.
6.2. Rejection by a Responder
A Responder may reject a PathSetupRequest for any reason:
1. As with any classical system, it may simply choose to reject the
request for any service-related reason, such as security,
licensing, etc.
2. It may determine that the request cannot be fulfilled with the
resources offered by nodes in the path.
When a node rejects the PathSetupRequest, it shall inform the other
nodes along the path by creating a PathSetupReturn message with an
error code that indicates failure and sending that message to the
node on the top of the stack. As with a successful
PathSetupResponse, the list of nodes to which the message must be
sent is created as a stack. Other than the addresses and the error
code, the message may be empty; no RuleSets are required. The
message is then iteratively returned, with each node popping its own
address and forwarding to the next.
6.3. Robustness
As the rate of connection initiation increases, competition for
resources will also increase. A soft reservation mechanism that
temporarily allocates resources in the anticipation of reception of a
RuleSet may be used, with the reservation timing out and resources
being released if no RuleSet arrives within a certain period.
Specification of this mechanism is beyond the scope of this document.
Deeper integration of routing with real-time availability of
resources is beyond the scope of this document.
7. Contributors
Besides the authors, Luciano Aparicio, Clement Durand, Dominic
Horsman, Shota Nagayama, Takahiko Satoh, Shigeya Suzuki, Amin
Taherkhani, and Joe Touch have made substantial contributions to the
network architecture and the concepts described here.
We also thank Chia-Hung Chien, Kaori Ishizaki, Bill Munro, Kae
Nemoto, Takafumi Oka, Shinnosuke Ozawa, and Thaddeus Ladd.
Comments by Wojciech Kozlowski, Gyananjay Rai and Patrick Gelard are
reflected in this draft.
Van Meter & Matsuo Expires March 13, 2020 [Page 10]
Internet-Draft September 2019
8. IANA Considerations
This memo includes no request to IANA.
9. Security Considerations
Security implications of this entire process are extensive.
To minimize the probability of tampering, each information block
added to the request on the outbound leg should be signed by the node
adding the block.
Each information block describes hardware configuration, and
therefore inherently leaks information about the network topology and
condition. This document addresses only connection setup within a
single network. Internetwork connection setup will require
mechanisms to limit the leaking of sensitive network information
across organizational boundaries.
Likewise, each RuleSet should be signed to prevent tampering during
the PathSetupResponse phase.
Both the Request and Response phase may be encrypted using
appropriate public key mechanisms.
It is also known that quantum networks may be vulnerable to attacks
not possible in classical networks. These concerns are beyond the
scope of this document.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
10.2. Informative References
[qiroadmap]
Wehner, S., Elkouss, D., and R. Hanson, "Quantum internet:
A vision for the road ahead", Science 362, 2018.
[qnetworking]
Van Meter, R., "Quantum Networking", Wiley-iSTE , 2014.
Van Meter & Matsuo Expires March 13, 2020 [Page 11]
Internet-Draft September 2019
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<https://www.rfc-editor.org/info/rfc2328>.
[theqi] Kimble, J., "The Quantum Internet", Nature 453, 1023-1030,
2008.
Authors' Addresses
Rodney Van Meter
Keio University
5322 Endo
Fujisawa, Kanagawa 252-0882
JP
Phone: +81-46-649-3529
Email: rdv@sfc.wide.ad.jp
Takaaki Matsuo
Keio University
5322 Endo
Fujisawa, Kanagawa 252-0882
JP
Phone: +81-46-649-3529
Email: kaaki@sfc.wide.ad.jp
Van Meter & Matsuo Expires March 13, 2020 [Page 12]
