| Quantum Internet Research Group | R. Van Meter |
| Internet-Draft | T. Matsuo |
| Intended status: Informational | Keio University |
| Expires: March 14, 2020 | September 11, 2019 |
Connection Setup in a Quantum Network
draft-van-meter-qirg-quantum-connection-setup-01
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.
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 14, 2020.
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.
Building a connection across a quantum network 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 between the two nodes than a store-and-forward network session.
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.
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.
The following terms will be used:
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 necessarily correspond to any asymmetry during the connection lifetime. Source and destination are not appropriate because:
"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.
The single-network, two-node connection setup procedure consists of three basic phases:
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 as OSPF? 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?
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.
At minimum, the PathSetupRequest message must contain:
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:
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.
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.
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.
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.
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.
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.
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 message is then iteratively returned, with each node popping its own address and forwarding to the next.
A Responder may reject a PathSetupRequest for any reason:
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.
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.
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.
This memo includes no request to IANA.
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.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [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. |
| [RFC2328] | Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998. |
| [theqi] | Kimble, J., "The Quantum Internet", Nature 453, 1023-1030, 2008. |