idnits 2.17.1 draft-dahlberg-ll-quantum-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2019) is 1872 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Quantum Internet Research Group AD. Dahlberg 3 Internet-Draft MS. Skrzypczyk 4 Intended status: Experimental SW. Wehner 5 Expires: September 12, 2019 QuTech, Delft University of Technology 6 March 11, 2019 8 The Link Layer service in a Quantum Internet 9 draft-dahlberg-ll-quantum-00 11 Abstract 13 In a classical network the link layer is responsible for transferring 14 a datagram between two nodes that are connected by a single link, 15 possibly including switches. In a quantum network however, the link 16 layer will need to provide a robust entanglement generation service 17 between two quantum nodes which are connected by a quantum link, 18 possibly including quantum repeaters. This service can be used by 19 higher layers to produce entanglement between distant nodes or to 20 perform other operations such as qubit transmission, without full 21 knowledge of the underlying hardware and its parameters. This draft 22 defines what can be expected from the service provided by a link 23 layer for a Quantum Network and defines an interface between higher 24 layers and the link layer. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 12, 2019. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Desired service . . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 4.1. Higher layers to link layer . . . . . . . . . . . . . . . 4 65 4.1.1. Header specification . . . . . . . . . . . . . . . . 4 66 4.2. Link layer to higher layers . . . . . . . . . . . . . . . 5 67 4.2.1. Header specification . . . . . . . . . . . . . . . . 6 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 70 7. Informative References . . . . . . . . . . . . . . . . . . . 10 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Introduction 75 The most important fundamental operation in a quantum network is the 76 generation of entanglement between nodes. Short-distance 77 entanglement can be used to generate long-distance entanglement with 78 the use of an operation called entanglement swap [1] (also formalised 79 in [2]). If nodes A and B share an entangled pair and similarly for 80 B and C, B can perform a so called Bell measurement [3] and send the 81 measurement outcome (2 bits) over a classical channel to A or C such 82 that in the end A and C share an entangled pair. Furthermore, long- 83 distance entanglement in turn enable long-distance qubit transmission 84 by the use of quantum teleportation [3] (also formalised in [2]). 85 Node A can teleport an unknown qubit state to B by consuming an 86 entangled pair between A and B and sending two classical bits to B. 88 Entanglement between distant nodes of up to 1.3 km have been 89 demonstrated [4], in a proof-of-principle experiment. The next step 90 towards a quantum network is to turn such an experiment to a reliable 91 service. This is the role of the link layer, which turns an ad-hoc 92 physical setup to a reliable entanglement generation service. Since 93 entanglement generation is typically a probabilistic process, one of 94 the main tasks of the link layer is to manage re-tries performed by 95 the physical layer and with high confidence provide entanglement to 96 higher layers within a requested time window. Once an entangled pair 97 has been generated, the nodes need to be able to agree on which 98 qubits are involved in which entangled pair to be able to use it, 99 thus another main task of the link layer is to provide an 100 entanglement identifier. 102 2. Scope 104 This draft is meant to define the service and interface of an link 105 layer of a quantum network. It does not present a protocol realising 106 this service. However a protocol that indeed does this have been 107 proposed by us in the paper [5]. 109 3. Desired service 111 This section definces the service that a link layer provides in a 112 quantum network. The interface and header specification is defined 113 in the next section. 115 A link layer between two nodes A and B of a quantum network must 116 provide the following features: 118 o Allow both node A and B to initialize entanglement generation. 120 o Allow the initializing node to specify a desired minimum 121 fidelity[3] and maximum waiting time. 123 o Notify both nodes of success or failure of entanglement generation 124 before the requested maximum waiting time has passed since the 125 request was initialized. 127 o If success is notified, the generated entangled pair has with high 128 confidence higher (or equal) fidelity than the desired minimum 129 fidelity. 131 o For successful request, provide an entanglement identifier to 132 allow higher layers to use identify the entangled pair in the 133 network. 135 4. Interface 137 This section describes the interface between higher layers and the 138 link layer in a quantum network, along with header specifications for 139 the type of messages. The interface consists of a single type of 140 message from the higher layers to the link layer, which is the CREATE 141 message for requesting entanglement generation. Response messages 142 from the link layer to the higher layers take either the form of an 143 ACK, an OK message or one of many error messages. The ACK is sent 144 back directly upon receiving a CREATE if the link layer supports the 145 request and contains a CREATE ID such that the higher layer can 146 associated the subsequent OK messages to the correct request. It is 147 assumed that the nodes in the network are assigned a unique ID in the 148 network, which is used in the Remote Node ID parameters of the 149 messages below. 151 4.1. Higher layers to link layer 153 The higher layers can send a CREATE message to the link layer to 154 request the generation of entanglement. Along with other parameters, 155 as specified below the higher layers can specify a minimum fidelity, 156 a maximum waiting time and the number of entangled pairs to be 157 produced. 159 4.1.1. Header specification 161 The CREATE message contains the following parameters: 163 o Remote Node ID (32 bits): Used if the node is directly connected 164 to multiple nodes. Indicates which node to generate entanglement 165 with. 167 o Minimum fidelity (16 bits): The desired minimum fidelity, between 168 0 and 1, of the generated entangled pair. A binary value encoding 169 the integer 'n' represents the fidelity 'n' divided by (2^16-1). 171 o Max Time (16 bits): The maximum time in seconds the higher layer 172 is willing to wait for the request to be fulfilled. Represented 173 as a binary16 float as specified in [6]. 175 o Purpose ID (16 bits): Allows the higher layer to tag the request 176 for a specific purpose. If the request is from an application 177 this can be thought of as a port number. The purpose ID can also 178 be used by a network layer to specify that this entanglement 179 request is part of long-distance entanglement generation over a 180 specific path. 182 o Number (16 bits): The number of entangled pairs to generate. 184 o Priority (4 bits): Can be used to indicate if this request is of 185 high priority and should ideally be fulfilled early. Higher means 186 faster service. 188 o Type of request (TPE) (1 bit): Either create and keep (K) or 189 measure directly (M), where K stores the generated entanglement in 190 memory and M measures the entanglement directly. 192 o Atomic (ATO) (1 bit): A flag that indicates that the request 193 should be satisfied as a whole, i.e. that all entangled pairs are 194 available in memory at the same time. Only valid for type K 195 requests. 197 o Consecutive (CON) (1 bit): A flag indicating that the entangled 198 pairs of the request should be generated close in time. Note that 199 this is different from the atomic flag since the entangled pairs 200 does not need to exist in memory at the same time. Also, 201 Consecutive does not mean high priority, only that when the first 202 entangled pair is generated, the subsequent ones should be 203 generated with high priority. 205 The complete header specification of the CREATE message is given in 206 Figure 1. 208 0 1 2 3 209 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Remote Node ID | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Minimum Fidelity | Max Time | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Purpose ID | Number | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Prio |T|A|C| | 218 | rity |P|T|O| Unused | 219 | |E|O|N| | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 Figure 1: CREATE message header format 224 4.2. Link layer to higher layers 226 When receiving a CREATE message from higher layers the link layer 227 will directly respond and notify the higher layer whether requests 228 will be scheduled for generation. If so the link layer responds with 229 an ACK containing a CREATE ID. The higher layer can use this CREATE 230 ID together with the ID of the requesting node to associate OK 231 messages it receives from the link layer to the correct request. 232 Note that the ID of the requesting node is needed since the ACK is 233 returned directly and the CREATE ID is thus not unique for requests 234 from different nodes. If the link layer does not support the given 235 request an error message is instead returned. 237 When a request is satisfied an OK message is sent to the higher 238 layer. The OK message contains different fields depending on whether 239 the request was of type K or M. For K the OK contains a logical 240 qubit identifier (LQID) such that the higher layer can know which 241 qubit holds the generated entanglement. For M the OK contains the 242 basis which the qubit was measured and the measurement outcome. 244 Both during and after an entanglement generation, the link layer can 245 return error messages to the higher layers, as further described 246 below. For example if something happens to the qubit or another 247 error occurs such that the entanglement is not valid anymore, the 248 link layer can issue an ERR_EXPIRE message. 250 4.2.1. Header specification 252 To distinguish the different types of messages that the link layer 253 can return to the higher layer, the first part of the header is a 4 254 bit field which specifies the type of message using the following 255 mapping: 257 o 0001: ACK 259 o 0010: Type K OK 261 o 0011: Type M OK 263 o 0100: ERR 265 The complete header specification for these four types of messages 266 are shown below in Figure 2 to Figure 5. 268 The ACK message contains the following parameters: 270 o Create ID (16 bits): A Create ID that the higher layer can use to 271 associate subsequent OK messages to the request. 273 0 1 2 3 274 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Type | Create ID | Unused | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Figure 2: ACK message header format 281 The type K OK message contains the following parameters: 283 o Create ID (16 bits): Must be the same Create ID that was given in 284 the ACK of the corresponding request. 286 o Logical Qubit ID (LQID) (4 bits): A logical ID of the qubit which 287 is part of the entangled pair. 289 o Directionality flag (D) (1 bit): Specifies if the request came 290 from this node (D=0) or from the remote node (D=1). 292 o Sequence number (16 bits): A sequence number for identifying the 293 entangled pair. It is assumed to be unique for entangled pairs 294 between the given nodes. Thus together with the IDs of the nodes, 295 one can create an entanglement identifier which is unique in the 296 network. 298 o Purpose ID (16 bits): The purpose ID of the request (only used by 299 the node which did not initiate the request) 301 o Remote Node ID (32 bits): Used if the node is directly connected 302 to multiple nodes. 304 o Goodness (16 bits): An estimate of the fidelity of the generated 305 entangled pair. Should not be seen as a guarantee. 307 o Time of Goodness (ToG) (16 bits): The time of the goodness 308 estimate. Not necessarily the time when the estimate is performed 309 but rather the time for which the estimate is for. Can be used to 310 make an updated estimate based on decoherence times of the qubits. 312 0 1 2 3 313 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Type | Create ID | LQID |D| Unused | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Sequence Number | Purpose ID | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Remote Node ID | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Goodness | Time of Goodness | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 Figure 3: Type K OK message header format 326 The type M OK message contains the following parameters: 328 o Create ID (16 bits): The same Create ID that was given in the ACK 329 of the corresponding request. 331 o Measurement outcome (M) (1 bit): The outcome of the measurement 332 performed on the entangled pair. 334 o Basis (3 bits): Which basis the entangled pair was measured in, 335 used if the basis is random. The following representation is 336 used: 338 * 000: Unused 340 * 001: Z-basis {|0>, |1>} 342 * 010: (Y-basis) Z-basis rotated by angle -pi/2 around X-axis. 344 * 100: (X-basis) Z-basis rotated by angle pi/2 around Y-axis. 346 * 101: (XZ-basis) Z-basis rotated by angle pi/4 around Y-axis. 348 * 011: (YZ-basis) Z-basis rotated by angle -pi/4 around X-axis. 350 * 110: (XY-basis) X-basis rotated by angle pi/4 around Z-axis. 352 o Directionality flag (D) (1 bit): Specifies if the request came 353 from this node (D=0) or from the remote node (D=1). 355 o Sequence number (16 bits): A sequence number for identifying the 356 entangled pair. It is assumed to be unique for entangled pairs 357 between the given nodes. Thus together with the IDs of the nodes, 358 one can create an entanglement identifier which is unique in the 359 network. 361 o Purpose ID (16 bits): The purpose ID of the request (only used by 362 the node which did not initiate the request) 364 o Remote Node ID (32 bits): Used if the node is directly connected 365 to multiple nodes. 367 o Goodness (16 bits): An estimate of the fidelity of the generated 368 entangled pair. Should not be seen as a guarantee. 370 Note: Time of Goodness is not needed here since there is no 371 decoherence on the measurement outcomes. 373 0 1 2 3 374 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Type | Create ID |M|Basis|D| Unused | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Sequence Number | Purpose ID | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Remote Node ID | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Goodness | Unused | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 Figure 4: Type M OK message header format 387 The ERR message contains the following parameters: 389 o Create ID (16 bits): The same Create ID that was given in the ACK 390 of the corresponding request. 392 o Error code (ERR) (4 bits): Specifies what error occurred. See 393 below what the error codes mean. 395 o Expire by sequence numbers (S) (1 bit): Used by ERR_EXPIRE, to 396 specify whether a range of sequence numbers should be expired 397 (S=1) or all sequence numbers associated with the given Create ID 398 and Origin Node (S=0). 400 o Sequence number low (16 bits): Used by error code ERR_EXPIRE to 401 identify a range of sequence numbers that needs to be expired. 402 Numbers above Sequence number low (inclusive) and below Sequence 403 number high (exclusive) should be expired. 405 o Sequence number high (16 bits): Used by error code ERR_EXPIRE to 406 identify a range of sequence numbers that needs to be expired. 407 Numbers above Sequence number low (inclusive) and below Sequence 408 number high (exclusive) should be expired. 410 o Origin Node (32 bits): Used if the node is directly connected to 411 multiple nodes. Needed here since Create IDs are not unique for 412 request from different nodes. 414 0 1 2 3 415 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Type | Create ID | ERR |S| Unused | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Sequence number low | Sequence number high | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Origin Node | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 Figure 5: Error message header format 426 The different error codes using in an error message are the 427 following: 429 o Error returned directly when a CREATE message is received: 431 * ERR_UNSUPP (0001): The given request is not supported. For 432 example if the minimum fidelity is not achievable or if the 433 request is of type K and the hardware cannot store 434 entanglement. 436 * ERR_CREATE (0010): The create message could not be parsed. 438 * ERR_REJECTED (0011): The request was rejected by this node 439 based on for example the Purpose ID. 441 * ERR_OTHER (0100): An unknown error occurred. 443 o Error returned after a CREATE message is received, before or after 444 an OK is returned: 446 * ERR_EXPIRE (0101): One or more already sent OK messages have 447 expired and the entangled pair is not available anymore. Can 448 either be specified as a range of sequence numbers or by a 449 create ID by using the S flag. 451 * ERR_REJECTED (0011): The request was rejected by the other node 452 based on for example the Purpose ID. 454 * ERR_TIMEOUT (0110): The request was not satisfied within the 455 requested max waiting time. 457 5. IANA Considerations 459 This memo includes no request to IANA. 461 6. Acknowledgements 463 The authors would like to acknowledge funding received the Quantum 464 Internet Alliance. 466 The authors would further like to acknowledge Wojciech Kozlowski for 467 useful feedback on this draft. 469 7. Informative References 471 [1] Briegel, H., Dur, W., Cirac, J., and P. Zoller, "Quantum 472 repeates: The Role of Imperfect Local Operations in 473 Quantum Communication", Physical Review Letters 81, 26, 474 1998, . 477 [2] Kompella, K., Aelmans, M., Wehner, S., Sirbu, C., and A. 478 Dahlberg, "Advertising Entanglement Capabilities in 479 Quantum Networks", QIRG Internet-Draft, 2018, 480 . 483 [3] Nielsen, M. and I. Chuang, "Quantum Computation and 484 Quantum Information", QIRG Internet-Draft, 2018, 485 . 487 [4] Hensen, B., Bernien, H., Dreau, A., Reiserer, A., Kalb, 488 N., Blok, M., Ruitenberg, J., Vermeulen, R., Schouten, R., 489 Abellan, C., Amaya, W., Pruneri, V., Mitchell, M., 490 Markham, M., Twitchen, D., Elkouss, D., Wehner, S., 491 Taminiau, T., and R. Hanson, "Loophole-free Bell 492 inequality violation using electron spins separated by 1.3 493 kilometres", Nature 526, 682-686, 2015, 494 . 496 [5] Dahlberg, A., Skrzypczyk, M., Coopmans, T., Wubben, L., 497 Rozpedek, F., Pompili, M., Stolk, A., Pawelczak, P., 498 Knegjens, R., de Oliveira Filho, J., Hanson, R., and S. 499 Wehner, "A Link Layer Protocol for Quantum Networks", 500 arXiv pre-print (in preparation) arXiv:1903.XXXXX, 2019, 501 . 503 [6] IEEE, "754-1985 - IEEE Standard for Binary Floating-Point 504 Arithmetic", IEEE standard 10.1109/IEEESTD.1985.82928, 505 1990, . 507 Authors' Addresses 509 Axel Dahlberg 510 QuTech, Delft University of Technology 511 Lorentzweg 1 512 Delft 2628 CJ 513 Netherlands 515 Phone: +31 (0)65 8966821 516 Email: e.a.dahlberg@tudelft.nl 518 Matthew Skrzypczyk 519 QuTech, Delft University of Technology 520 Lorentzweg 1 521 Delft 2628 CJ 522 Netherlands 524 Email: m.d.skrzypczyk@student.tudelft.nl 525 Stephanie Wehner 526 QuTech, Delft University of Technology 527 Lorentzweg 1 528 Delft 2628 CJ 529 Netherlands