idnits 2.17.1 draft-dahlberg-ll-quantum-03.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 (October 10, 2019) is 1653 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, Ed. 5 Expires: April 12, 2020 QuTech, Delft University of Technology 6 October 10, 2019 8 The Link Layer service in a Quantum Internet 9 draft-dahlberg-ll-quantum-03 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 This service can be used by higher layers to produce entanglement 19 between distant nodes or to perform other operations such as qubit 20 transmission, without full knowledge of the underlying hardware and 21 its parameters. This draft defines what can be expected from the 22 service provided by a link layer for a Quantum Network and defines an 23 interface between higher layers and the link layer. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 12, 2020. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Desired service . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4.1. Higher layers to link layer . . . . . . . . . . . . . . . 4 64 4.1.1. Header specification . . . . . . . . . . . . . . . . 4 65 4.2. Link layer to higher layers . . . . . . . . . . . . . . . 7 66 4.2.1. Header specification . . . . . . . . . . . . . . . . 8 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 69 7. Informative References . . . . . . . . . . . . . . . . . . . 13 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 72 1. Introduction 74 The most important fundamental operation in a quantum network is the 75 generation of entanglement between nodes. Short-distance 76 entanglement can be used to generate long-distance entanglement with 77 the use of an operation called entanglement swap [1] (also formalised 78 in [2]). If nodes A and B share an entangled pair and similarly for 79 B and C, B can perform a so called Bell measurement [3] and send the 80 measurement outcome (2 bits) over a classical channel to A or C such 81 that in the end A and C share an entangled pair. Furthermore, long- 82 distance entanglement does in turn enable long-distance qubit 83 transmission by the use of quantum teleportation [3] (also formalised 84 in [2]). Node A can teleport an unknown qubit state to B by 85 consuming an entangled pair between A and B and sending two classical 86 bits to B. For an overview of quantum networking and its 87 applications we refer to [5]. 89 Long lived entanglement between distant nodes capable of storing such 90 entanglement has been demonstrated over a distance of up to 1.3 km 91 [4], in a proof-of-principle experiment. This entanglement was also 92 heralded, that is, there exits a so-called heralding signal that 93 indicates success in entanglement production without consuming such 94 entanglement. Short lived and non-heralded entanglement has been 95 observed from a satellite over a distance of 1200 km [6] in a proof 96 of principle experiment. The next step towards a quantum network is 97 to turn ad-hoc experiments that produce entanglement into a reliable 98 service. This is the role of the link layer, which turns an ad-hoc 99 physical setup to a reliable entanglement generation service. 100 Reliable here means that the higher layers can (unless a timeout or 101 other critical failures occur) rely in deterministic entanglement 102 production. In particular, this means that since the underlying 103 physical process is often probabilistic but entanglement generation 104 can be confirmed using the heralding signal, one of the main tasks of 105 the link layer is to manage re-tries in producing entanglement at the 106 the physical layer. Once an entangled pair has been generated, the 107 nodes need to be able to agree on which qubits are involved in which 108 entangled pair in order to use it, thus another main task of the link 109 layer is to provide an entanglement identifier. 111 2. Scope 113 This draft is meant to define the service and interface of an link 114 layer of a quantum network. Further considerations that motivate 115 this definition can be found in [7]. It does not present a protocol 116 realising this service. However a protocol that indeed does this 117 have been proposed in [7], together with more details on use cases 118 and design decisions in forming a quantum network stack. 120 3. Desired service 122 This section definces the service that a link layer provides in a 123 quantum network. The interface and header specification is defined 124 in the next section. 126 A link layer between two nodes A and B of a quantum network must 127 provide the following minimal features (see [7] for an extended 128 feature set): 130 o Allow both node A and B to initialize entanglement generation. 132 o Allow the initializing node to specify a desired minimum 133 fidelity[3] and maximum waiting time. 135 o Notify both nodes of success or failure of entanglement generation 136 before the requested maximum waiting time has passed since the 137 request was initialized. 139 o If success is notified, the generated entangled pair has with high 140 confidence higher (or equal) fidelity than the desired minimum 141 fidelity. 143 o For a successful request, provide an entanglement identifier to 144 allow higher layers to use identify the entangled pair in the 145 network without the need for further communication. 147 4. Interface 149 This section describes the interface between higher layers and the 150 link layer in a quantum network, along with header specifications for 151 the type of messages. The interface consists of a single type of 152 message from the higher layers to the link layer, which is the CREATE 153 message for requesting entanglement generation. Response messages 154 from the link layer to the higher layers take either the form of an 155 ACK, an OK message or one of many error messages. The ACK is sent 156 back directly upon receiving a CREATE if the link layer supports the 157 request and contains a CREATE ID such that the higher layer can 158 associated the subsequent OK messages to the correct request. It is 159 assumed that the nodes in the network are assigned a unique ID in the 160 network, which is used in the Remote Node ID parameters of the 161 messages below. 163 4.1. Higher layers to link layer 165 The higher layers can send a CREATE message to the link layer to 166 request the generation of entanglement. Along with other parameters, 167 as specified below the higher layers can specify a minimum fidelity, 168 a maximum waiting time and the number of entangled pairs to be 169 produced. 171 4.1.1. Header specification 173 The CREATE message contains the following parameters: 175 o Remote Node ID (32 bits): Used if the node is directly connected 176 to multiple nodes. Indicates which node to generate entanglement 177 with. 179 o Minimum fidelity (16 bits): The desired minimum fidelity, between 180 0 and 1, of the generated entangled pair. A binary value encoding 181 the integer 'n' represents the fidelity 'n' divided by (2^16-1). 183 o Time Unit (TU) (2 bits): The time units used for specifying Max 184 Time, where (00, 01, 10) each indicate (micro-seconds, 185 milliseconds, seconds) respectively and 11 is unused. 187 o Max Time (14 bits): The maximum time in the time units specified 188 above that the higher layer is willing to wait for the request to 189 be fulfilled. A binary value encoding the integer 'n' 190 representing the time in the specified time units. 192 o Purpose ID (16 bits): Allows the higher layer to tag the request 193 for a specific purpose. If the request is from an application 194 this can be thought of as a port number. The purpose ID can also 195 be used by a network layer to specify that this entanglement 196 request is part of long-distance entanglement generation over a 197 specific path. 199 o Number (16 bits): The number of entangled pairs to generate. 201 o Priority (3 bits): Can be used to indicate if this request is of 202 high priority and should ideally be fulfilled early. Higher means 203 faster service. 205 o Type of request (TPE) (1 bit): Either create and keep (K) or 206 measure directly (M), where K stores the generated entanglement in 207 memory and M measures the entanglement directly. 209 o Atomic (ATO) (1 bit): A flag that indicates that the request 210 should be satisfied as a whole without interuption by other 211 requests. 213 o Consecutive (CON) (1 bit): A flag indicating an OK is returned for 214 each pair made for a request. Otherwise, an OK is sent only when 215 the entire request is completed (more common in application use 216 cases). For K type requests, this means all pair should be in 217 memory at the same time. 219 o Random basis choice for measure directly 221 * (RL) (2 bits): Choose to measure the local qubit randomly in 222 either 224 * (RR) (2 bits): Choose to measure the remote qubit randomly in 225 either 227 Using the following encoding: 229 * 00: No random choice 231 * 01: X or Z basis (BB84) 233 * 10: X, Y or Z basis (six state) 235 * 11: CHSH rotated bases, Z basis rotated by angles +/- pi/4 236 around Y axis. 238 o Probability distributions used to sample random basis for measure 239 directly: 241 * (PL1) (8 bits): Parameter for local probability distribution 242 used to sample basis if RL is not 00 244 * (PL2) (8 bits): Parameter for local probability distribution 245 used to sample basis if RL is not 00 247 * (PR1) (8 bits): Parameter for remote probability distribution 248 used to sample basis if RR is not 00 250 * (PR2) (8 bits): Parameter for remote probability distribution 251 used to sample basis if RR is not 00 253 Each value is seen as the integer representing of the binary 254 value. Probability distributions are used as follows 256 * If the specified random basis has 2 elements then the 257 distribution obeys the probabilities (PL(R)1 / 255, 1 - PL(R)1 258 / 255) 260 * If the specified random basis has 3 elements then the 261 distribution obeys the probabilities (PL(R)1 / 255, PL(R)2 / 262 255, 1 - PL(R)1 / 255 - PL(R)2 / 255) 264 o Rotation of measurement basis in the case of M types of requests 265 for both the local and remote measurement. Three rotations from 266 the defaults Z basis are performed, first a rotation around the 267 X-axis (ROTX1L(R)), then a rotation around the Y-axis (ROTYL(R)) 268 and finally a rotation again around the X-axis. Note that 269 arbitrary rotations can be composed as these three rotations, see 270 . If all three fields 271 are 00000000, the qubits are measured in the Z basis. If RL(R) is 272 not 00, these three fields (ROTX1L(R), ROTYL(R) and ROTX2L(R)) are 273 ignored. 275 * Measurement rotation around X for local (remote) node 276 (ROTX1L(R)) (8 bits): Measurement to be performed in the case 277 of M types of request. Default is Z measurement. Specified 278 measurement to be rotated around the X axis by angle of 2 279 pi/256 * ROTX1 281 * Measurement rotation around Y for local (remote) node 282 (ROTYL(R)) (8 bits): Measurement to be performed in the case of 283 M types of request. Default is Z measurement. Specified 284 measurement to be rotated around the Y axis by an angle of 2 285 pi/256 * ROTY 287 * Measurement rotation around X for local (remote) node 288 (ROTX2L(R)) (8 bits): Measurement to be performed in the case 289 of M types of request. Default is Z measurement. Specified 290 measurement to be rotated around the X axis by an angle of 2 291 pi/256 * ROTX2 293 The complete header specification of the CREATE message is given in 294 Figure 1. 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Remote Node ID | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Minimum Fidelity |TU | Max Time | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Purpose ID | Number | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 |Prio |T|A|C| | | | | | 306 |rity |P|T|O|RL |RR | reserved | PL1 | PL2 | 307 | |E|O|N| | | | | | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | | | | | 310 | PR1 | PR2 | ROTX1L | ROTXYL | 311 | | | | | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | | | | | 314 | ROTX2L | ROTX1R | ROTYR | ROTX2R | 315 | | | | | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 Figure 1: CREATE message header format 320 4.2. Link layer to higher layers 322 When receiving a CREATE message from higher layers the link layer 323 will directly respond and notify the higher layer whether requests 324 will be scheduled for generation. If so the link layer responds with 325 an ACK containing a CREATE ID. The higher layer may choose to use 326 this CREATE ID together with the ID of the requesting node to 327 associate OK messages it receives from the link layer to the correct 328 request. Note that the ID of the requesting node is needed since the 329 ACK is returned directly and the CREATE ID is thus not unique for 330 requests from different nodes. If the link layer does not support 331 the given request an error message is instead returned. 333 When a request is satisfied an OK message is sent to the higher 334 layer. The OK message contains different fields depending on whether 335 the request was of type K (keep) or M (measure directly). For K the 336 OK contains a logical qubit identifier (LQID) such that the higher 337 layer can know which logical qubit holds the generated entanglement. 338 For M the OK contains the basis which the qubit was measured and the 339 measurement outcome. 341 Both during and after entanglement generation, the link layer can 342 return error messages to the higher layers, as further described 343 below. For example if something happens to the qubit or another 344 error occurs such that the entanglement is not valid anymore, the 345 link layer can issue an ERR_EXPIRE message. 347 4.2.1. Header specification 349 To distinguish the different types of messages that the link layer 350 can return to the higher layer, the first part of the header is a 4 351 bit field which specifies the type of message using the following 352 mapping: 354 o 0001: ACK 356 o 0010: Type K OK 358 o 0011: Type M OK 360 o 0100: ERR 362 The complete header specification for these four types of messages 363 are shown below in Figure 2 to Figure 5. 365 The ACK message contains the following parameters: 367 o Create ID (16 bits): A Create ID that the higher layer can use to 368 associate subsequent OK messages to the request. 370 0 1 2 3 371 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 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Type | Create ID | Unused | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 Figure 2: ACK message header format 378 The type K OK message contains the following parameters: 380 o Create ID (16 bits): Must be the same Create ID that was given in 381 the ACK of the corresponding request. 383 o Logical Qubit ID (LQID) (4 bits): A logical ID of the qubit which 384 is part of the entangled pair. 386 o Directionality flag (D) (1 bit): Specifies if the request came 387 from this node (D=0) or from the remote node (D=1). 389 o Sequence number (16 bits): A sequence number for identifying the 390 entangled pair. It is assumed to be unique for entangled pairs 391 between the given nodes. Thus together with the IDs of the nodes 392 between which the entanglement is produced, one can create an 393 entanglement identifier which is unique in the network. 395 o Purpose ID (16 bits): The purpose ID of the request (only used by 396 the node which did not initiate the request) 398 o Remote Node ID (32 bits): Used if the node is directly connected 399 to multiple nodes. 401 o Goodness (16 bits): An estimate of the fidelity of the generated 402 entangled pair. Should not be seen as a guarantee. 404 o Time of Goodness (ToG) (16 bits): The time of the goodness 405 estimate. Not necessarily the time when the estimate is performed 406 but rather the time for which the estimate is for. Can be used to 407 make an updated estimate based on decoherence times of the qubits. 409 0 1 2 3 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Type | Create ID | LQID |D| Unused | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Sequence Number | Purpose ID | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Remote Node ID | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Goodness | Time of Goodness | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 Figure 3: Type K OK message header format 423 The type M OK message contains the following parameters: 425 o Create ID (16 bits): The same Create ID that was given in the ACK 426 of the corresponding request. 428 o Measurement outcome (M) (1 bit): The outcome of the measurement 429 performed on the entangled pair. 431 o Basis (3 bits): Which basis the entangled pair was measured in, 432 used if the basis is random, i.e. if RBC is not 00 in the CREATE. 433 The following representation is used: 435 * 000: Z-basis 437 * 001: X-basis 439 * 010: Y-basis 441 * 011: Z-basis rotated by angle pi/4 around Y-axis 443 * 100: Z-basis rotated by angle -pi/4 around Y-axis 445 * 101: Unused 447 * 110: Unused 449 * 111: Unused 451 o Directionality flag (D) (1 bit): Specifies if the request came 452 from this node (D=0) or from the remote node (D=1). 454 o Sequence number (16 bits): A sequence number for identifying the 455 entangled pair. It is assumed to be unique for entangled pairs 456 between the given nodes. Thus together with the IDs of the nodes, 457 one can create an entanglement identifier which is unique in the 458 network. 460 o Purpose ID (16 bits): The purpose ID of the request (only used by 461 the node which did not initiate the request) 463 o Remote Node ID (32 bits): Used if the node is directly connected 464 to multiple nodes. 466 o Goodness (16 bits): An estimate of the fidelity of the generated 467 entangled pair. Should not be seen as a guarantee. 469 Note: Time of Goodness is not needed here since there is no 470 decoherence on the measurement outcomes. 472 0 1 2 3 473 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 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Type | Create ID |M|D|Basis| Unused | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Sequence Number | Purpose ID | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Remote Node ID | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Goodness | Unused | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 Figure 4: Type M OK message header format 486 The ERR message contains the following parameters: 488 o Create ID (16 bits): The same Create ID that was given in the ACK 489 of the corresponding request. 491 o Error code (ERR) (4 bits): Specifies what error occurred. See 492 below what the error codes mean. 494 o Expire by sequence numbers (S) (1 bit): Used by ERR_EXPIRE, to 495 specify whether a range of sequence numbers should be expired 496 (S=1) or all sequence numbers associated with the given Create ID 497 and Origin Node (S=0). 499 o Sequence number low (16 bits): Used by error code ERR_EXPIRE to 500 identify a range of sequence numbers that needs to be expired. 501 Numbers above Sequence number low (inclusive) and below Sequence 502 number high (exclusive) should be expired. 504 o Sequence number high (16 bits): Used by error code ERR_EXPIRE to 505 identify a range of sequence numbers that needs to be expired. 506 Numbers above Sequence number low (inclusive) and below Sequence 507 number high (exclusive) should be expired. 509 o Origin Node (32 bits): Used if the node is directly connected to 510 multiple nodes. Needed here since Create IDs are not unique for 511 request from different nodes. 513 0 1 2 3 514 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 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Type | Create ID | ERR |S| Unused | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Sequence number low | Sequence number high | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Origin Node | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 Figure 5: Error message header format 525 The different error codes using in an error message are the 526 following: 528 o Error returned directly when a CREATE message is received: 530 * ERR_UNSUPP (0001): The given request is not supported. For 531 example if the minimum fidelity is not achievable or if the 532 request is of type K and the hardware cannot store 533 entanglement. 535 * ERR_CREATE (0010): The create message could not be parsed. 537 * ERR_REJECTED (0011): The request was rejected by this node 538 based on for example the Purpose ID. 540 * ERR_OTHER (0100): An unknown error occurred. 542 o Error returned after a CREATE message is received, before or after 543 an OK is returned: 545 * ERR_EXPIRE (0101): One or more already sent OK messages have 546 expired and the entangled pair is not available anymore. Can 547 either be specified as a range of sequence numbers or by a 548 create ID by using the S flag. 550 * ERR_REJECTED (0011): The request was rejected by the other node 551 based on for example the Purpose ID. 553 * ERR_TIMEOUT (0110): The request was not satisfied within the 554 requested max waiting time. 556 5. IANA Considerations 558 This memo includes no request to IANA. 560 6. Acknowledgements 562 The authors would like to acknowledge funding received from the EU 563 Flagship on Quantum Technologies, Quantum Internet Alliance. 565 The authors would further like to acknowledge Tim Coopmans, Leon 566 Wubben, Filip Rozpedek, Matteo Pompili, Arian Stolk, Przemyslaw 567 Pawelczak, Robert Knegjens, Julio de Oliveria Filho, Sidney Cadot, 568 Joris van Rantwijk and Ronald Hanson for inputs and discusssion and 569 Wojciech Kozlowski for useful feedback on this draft. 571 7. Informative References 573 [1] Briegel, H., Dur, W., Cirac, J., and P. Zoller, "Quantum 574 repeates: The Role of Imperfect Local Operations in 575 Quantum Communication", Physical Review Letters 81, 26, 576 1998, . 579 [2] Kompella, K., Aelmans, M., Wehner, S., Sirbu, C., and A. 580 Dahlberg, "Advertising Entanglement Capabilities in 581 Quantum Networks", QIRG Internet-Draft, 2018, 582 . 585 [3] Nielsen, M. and I. Chuang, "Quantum Computation and 586 Quantum Information", Book Cambridge University Press, 587 2010, . 589 [4] Hensen, B., Bernien, H., Dreau, A., Reiserer, A., Kalb, 590 N., Blok, M., Ruitenberg, J., Vermeulen, R., Schouten, R., 591 Abellan, C., Amaya, W., Pruneri, V., Mitchell, M., 592 Markham, M., Twitchen, D., Elkouss, D., Wehner, S., 593 Taminiau, T., and R. Hanson, "Loophole-free Bell 594 inequality violation using electron spins separated by 1.3 595 kilometres", Nature 526, 682-686, 2015, 596 . 598 [5] Wehner, S., Elkouss, D., and R. Hanson, "Quantum internet: 599 A vision for the road ahead", Science 362, 6412, 2018, 600 . 603 [6] Yin, J., Cao, Y., Li, Y., Liao, S., Zhang, L., Ren, J., 604 Cai, W., Liu, W., Li, B., Dai, H., Li, G., Lu, Q., Gong, 605 Y., Xu, Y., Li, S., Li, F., Yin, Y., Jiang, Z., Li, M., 606 Jia, J., Ren, G., He, D., Zhou, Y., Zhang, X., Wang, N., 607 Chang, X., Zhu, Z., Liu, N., Chen, Y., Lu, C., Shu, R., 608 Peng, C., Wang, J., and J. Pan, "Satellite-based 609 entanglement distribution over 1200 kilometers", 610 Science 356, 6343, 2017, 611 . 613 [7] Dahlberg, A., Skrzypczyk, M., Coopmans, T., Wubben, L., 614 Rozpedek, F., Pompili, M., Stolk, A., Pawelczak, P., 615 Knegjens, R., de Oliveira Filho, J., Hanson, R., and S. 616 Wehner, "A Link Layer Protocol for Quantum Networks", 617 arXiv pre-print arXiv:1903.09778, 2019, 618 . 620 Authors' Addresses 622 Axel Dahlberg 623 QuTech, Delft University of Technology 624 Lorentzweg 1 625 Delft 2628 CJ 626 Netherlands 628 Phone: +31 (0)65 8966821 629 Email: e.a.dahlberg@tudelft.nl 631 Matthew Skrzypczyk 632 QuTech, Delft University of Technology 633 Lorentzweg 1 634 Delft 2628 CJ 635 Netherlands 637 Email: m.d.skrzypczyk@student.tudelft.nl 639 Stephanie Wehner (editor) 640 QuTech, Delft University of Technology 641 Lorentzweg 1 642 Delft 2628 CJ 643 Netherlands 645 Email: s.d.c.wehner@tudelft.nl