-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathdraft-kaws-qirg-advent-01.xml
975 lines (955 loc) · 36.1 KB
/
draft-kaws-qirg-advent-01.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="no"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-kaws-qirg-advent-01" ipr="trust200902">
<front>
<title abbrev='Advertising EntCap'>
Advertising Entanglement Capabilities in Quantum Networks
</title>
<author initials="K." surname="Kompella" fullname="Kireeti Kompella">
<organization>Juniper Networks, Inc.</organization>
<address>
<postal>
<street>1133 Innovation Way</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>USA</country>
</postal>
<email>kireeti.kompella@gmail.com</email>
</address>
</author>
<author initials="M." surname="Aelmans" fullname="Melchior Aelmans">
<organization>Juniper Networks, Inc.</organization>
<address>
<postal>
<street>Boeing Avenue 240</street>
<city>Schipol-Rijk</city>
<region>PZ</region>
<code>1119</code>
<country>The Netherlands</country>
</postal>
<email>maelmans@juniper.net</email>
</address>
</author>
<author initials="S." surname="Wehner" fullname="Stephanie Wehner">
<organization>QuTech</organization>
<address>
<postal>
<street>Van der Waalsweg 122</street>
<city>Delft</city>
<region>LC</region>
<code>2611</code>
<country>The Netherlands</country>
</postal>
<email>s.d.c.wehner@tudelft.nl</email>
</address>
</author>
<author initials="C." surname="Sirbu" fullname="Cristian Sirbu">
<organization>Redbit Networks</organization>
<address>
<postal>
<street></street>
<city>Dublin</city>
<region></region>
<code></code>
<country>Republic of Ireland</country>
</postal>
<email>cristian@redbit.network</email>
</address>
</author>
<author initials="A." surname="Dahlberg" fullname="Axel Dahlberg">
<organization>QuTech</organization>
<address>
<postal>
<street>Van der Waalsweg 122</street>
<city>Delft</city>
<region>LC</region>
<code>2611</code>
<country>The Netherlands</country>
</postal>
<email>E.A.Dahlberg@tudelft.nl</email>
</address>
</author>
<date/>
<area>Routing</area>
<workgroup>QIRG</workgroup>
<keyword>Quantum Internet</keyword>
<keyword>EPR pair</keyword>
<keyword>entanglement</keyword>
<keyword>fidelity</keyword>
<keyword>multi-hop entangled pair</keyword>
<abstract>
<t>
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.
</t>
<t>
No Schrodinger’s cats were harmed in the creation of this document.
</t>
</abstract>
<note title="Requirements Language">
<t>
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 <xref target="RFC2119">RFC2119</xref>.
</t>
</note>
</front>
<middle>
<section title="Introduction" anchor='intro'>
<t>
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” <xref target='QEnt'/>, 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 <xref
target="QTel"/> and for quantum key distribution (QKD) <xref
target='QKD'/>.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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 (<xref
target='QInt'/>). Also, several pairs of imperfectly entangled
qubits can be “distilled” (<xref target='QDist'/>) to fewer but
“better entangled” qubits.
</t>
<t>
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 (<xref target='NVD'/>, <xref
target='NVDD'/>). Logically, a qubit can be classified as a
“communication qubit”, a “traveling qubit” or a “storage qubit”.
</t>
<t>
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.
</t>
<section title='Definitions and Notation'>
<t>
The following terms are used in this document:
<list style="hanging">
<t hangText='Quantum link:'>
A quantum link is a connection transporting traveling
qubits, typically photons. This could be a physical link,
or by means of teleportation over pre-established entanglement amongst distant network nodes.
Such pre-shared entanglement effectively forms a shortcut - a virtual quantum link -
which can be used exactly once.
This document does not describe the usage of these links itself.
</t>
<t hangText='Classical link:'>
A classical link is a connection transporting packets.
This could be a physical or virtual link carried over a (MPLS) network. The proposed extensions in
this document use these links to exchange capabilities.
</t>
<t hangText="Controllable Quantum Node (CQN):">
A controllable quantum node is a quantum device consisting
of at least one qubit, capable of performing (a subset of)
the following operations described in detail below:
storing qubits for some amount of time, performing quantum
operations such as entanglement distillation and
entanglement swapping, and producing entanglement between
the nodes and traveling qubits. The latter are generally
realized using photons over fibers or through free space.
</t>
<t>
The term controllable refers to the fact that external
control in software is capable of selecting the desired
operations and qubits to use. Such nodes can be quantum
repeaters that allow choices of operations to be made, as
well as quantum end nodes capable of executing complex
application protocols <xref target='QKD'/>. Quantum
repeaters that merely allow timing control, such as
automatic entanglement swapping whenever qubits arrive in
a specific timing interval, will not be referred to as
CQN. Such automated repeaters can be seen as lying at the
quantum physical layer and do not enter routing or other
decision making, apart from being switched on or off, and
hence are not relevant to advertisement protocols like the
ones considered here.
</t>
<t hangText="Quantum end node (QEN):">
In this document, a quantum end node <xref target='QKD'/>
is one of a pair of quantum nodes forming a entanglement
via a sequence of zero or more CQNs. Quantum end nodes
typically run a higher-layer quantum application such as
QKD.
</t>
<t hangText="Entangled Pair (EP):">
An entangled pair is a special state of two qubits, known
as an EPR pair <xref target='QEnt'/>. An entangled pair
of qubits c@A and c@B is denoted [[c@A, c@B]].
</t>
<t>
The process of entangling two particles c@A and c@B is
denoted as follows:
<figure>
<artwork align='left'>
ent(c@A, c@B) -> [[c@A, c@B]]
</artwork>
</figure>
ent(c@A, c@B) may take time T and succeed with probability
P, and yield an entangled pair [[c@A, c@B]] of fidelity F.
</t>
<t hangText='Fidelity:'>
A measure of the quality of the entanglement of an EP
<xref target="QFid">QFid</xref>). Fidelity lies in the interval [0,
1] where a higher value indicates better quality; usable
fidelity values lie in the half-open interval (0.5, 1].
</t>
<t hangText="Communication qubit:">
A qubit is called a communication qubit if it is possible
to produce entanglement between this qubit and a traveling
photon. This can be done by emission from the quantum
node, that is, entanglement is produced between the qubit
and the photon which is emitted from the quantum
node. This process has been demonstrated in a number of
physical systems that can be used as quantum nodes such as
NV in diamond (<xref target='NVD'/>, <xref
target='NVDD'/>), Ion Traps (<xref target='IonTrap'/>) and
Neutral Atoms (<xref target='NAtom'/>). An example of a
communication qubit is the electron spin of the NV in
diamond system (<xref target='NVC'/>). Entanglement
between a communication qubit and traveling photons can
also be produced by absorption. Examples include atomic
ensemble memories (<xref target='QAEM'/>).
</t>
<t>
A communication qubit c at CQN A is denoted by c@A, or
simply c (if the node A is understood).
</t>
<t hangText='Storage qubit:'>
A qubit is called a storage qubit if the node has the
capability to use this qubit as a (temporary) quantum
memory, but the qubit cannot serve as a communication
qubit. To make storage qubits useful a node is required to
possess the ability to transfer the state of a
communication qubit to a storage qubit. An example of a
storage qubit is the nuclear spin in the NV in diamond
system <xref target='NVD'/>.
</t>
<t>
A storage qubit s at node B is denoted s@B.
</t>
<t hangText='Swap:'>
Two qubits located in the same CQN can interchange states
(<xref target='QDist'/>). For example, the states of a
communication qubit and a storage qubit at A can be
swapped as follows:
<figure>
<artwork align='left'>
swap(c@A, s@A)
</artwork>
</figure>
If c@A was entangled with c@B, the result is that s@A is
now entangled with c@B.
</t>
<t hangText='Distillation:'>
Distillation is the process of turning a large number of
weakly entangled states into a smaller number of highly
entangled states (<xref target='QDist'/>).
</t>
<t>
For example, EPs [[c1@A, c1@B]] and [[c2@A, c2@B]] of
fidelities F1 and F2 respectively may be distilled as
follows:
<figure>
<artwork align='left'>
dist([[c1@A, c1@B]], [[c2@A, c2@B]]) -> [[c3@A, c3@B]]
</artwork>
</figure>
</t>
<t>
If distillation is successful, the fidelity F3 of [[c3@A,
c3@B]] will be higher than F1 and F2.
</t>
<t hangText='Entanglement Swap:'>
Given two EPs [[c@A, c1@B]] and [[c2@B, c@C]], one can perform
an entanglement swap:
<figure>
<artwork align='left'>
entSwap([[c@A, c1@B]], [[c2@B, c@C]]) -> [[c@A, c@C]]
</artwork>
</figure>
to create a new EP between c@A and c@C. This is how
"multihop" EPs are created from a sequence of "single-hop" EPs.
</t>
<t>
The swap operation can also be used within a CQN. A
possible use case is when there aren't enough
communication qubits to create the needed EPs. If, in the
above example, B doesn't have two communication qubits c1
and c2, the following can be done:
<figure>
<artwork align='left'>
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
</artwork>
</figure>
</t>
</list>
</t>
</section>
</section>
<section title="Motivation">
<t>
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.
<figure>
<artwork align='center'>
X - Y - Z
. .
A B A, B: QEN
. .
U --- V X, Y, Z, U, V: CQNs
</artwork>
</figure>
</t>
<t>
From A's point of view, here are a number of questions:
<list style='numbers'>
<t>
Is B reachable from A via quantum links that allow EP creation?
</t>
<t>
If so, along what sequence(s) of quantum nodes?
</t>
<t>
Can each pair of adjacent CQNs in this sequence form EPs? If
so, how long will it take, and what fidelity can be
expected?
</t>
<t>
If each pair of adjacent CQNs successfully forms EPs of
sufficient fidelity, can these be swapped to form a multihop
EP between A and B?
</t>
<t>
If a multihop EP between A and B were to be formed, would it
be of good enough fidelity, or should a second multihop EP
be formed and the two EPs distilled into one high fidelity
EP? How many times should this process be repeated?
</t>
<t>
If the overall answer is Yes, should A proceed via sequence
A, X, Y, Z, B, or sequence A, U, V, B?
</t>
</list>
</t>
<t>
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.
</t>
</section>
<section title="Theory of Operation">
<t>
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 <xref target='NVD'/>,
<xref target='NVDD'/>, <xref target='IonTrap'/>, <xref
target='QAEM'/>). 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 (<xref target='NVD'/>), and Ion
Traps (<xref target='IonTrap'/>). The largest distance for
producing long-lived entanglement is presently 1.3kms (<xref
target='NVDD'/>). 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.
</t>
<t>
<figure>
<artwork align='center'>
+----------+ +----------+
| | c-chan +------------+ c-chan | |
| Control- | <-------> | Heralding | <-------> | Control-|
| lable | | Station | | lable |
| Quantum | *~~~~~~~> | | <~~~~~~~* | Quantum |
| Node | q-chan +------------+ q-chan | Node |
| A | | B |
| | <----------------------------------> | |
+----------+ classical network control plane +----------+
</artwork>
</figure>
</t>
<t>
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.
</t>
<section title="Multihop Entanglement">
<t>
<figure>
<artwork>
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)...]
</artwork>
</figure>
</t>
<t>
In the figure above, an example request for an entangled pair
between nodes A and B will be affected by the following
properties:
<list style='symbols'>
<t>
A chosen combination of F(idelity) and t(ime) duration to
produce an entanglement at the respective Fidelity. These
parameters roughly equate to the quality of the link, the
accuracy with which the nodes can use the link, and the
delay in classical networking.
</t>
<t>
The actual capability of nodes A and B to make use of the
communication qubits.
</t>
</list>
</t>
<t>
A new EP creation between CQNs B and C will similarly be
affected by the same parameters as above.
<figure>
<artwork>
resulting entanglement
*~~~~~~~~~~~~~~~~~~~~~~~~~~~~* *~~~~~~~~~~~~~~~~~~~~~~~~~~~~*
+-+ +-+ +-+
|A+----------------------------+B+----------------------------+C|
+-+ +-+ B-C Link properties +-+
[(F1,t1), (F2,t2)]
</artwork>
</figure>
</t>
<t>
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:
<figure>
<artwork>
*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*
+-+ +-+ +-+
|A+----------------------------+B+----------------------------+C|
+-+ +-+ +-+
Node B entanglement swap operation
</artwork>
</figure>
</t>
</section>
<section title='Distillation'>
<t>
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:
<list style='numbers'>
<t>
A and B look at the distillation schemes that both
advertise in common.
</t>
<t>
If there is none in common, stop. Distillation is not
possible.
</t>
<t>
If there is a non-trivial subset in common, the first
scheme in the node with the lower router ID is to be used
by A and B.
</t>
</list>
</t>
<t>
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.
<figure>
<artwork>
2:1 distillation (S,t,p)
*~~~~~~~~~~~~~~~~~~~~~~~~~~~~*
*~~~~~~~~~~~~~~~~~~~~~~~~~~~~*
+-+ +-+ +-+
|A+----------------------------+B+----------------------------+C|
+-+ A-B Link properties +-+ +-+
[(F1,t1), (F2,t2)]
</artwork>
</figure>
</t>
</section>
<section title='Node Properties'>
<t>
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:
<list style='numbers'>
<t>
Number of communication qubits. The number of
communication qubits determines the number of entangled
pairs that the node can produce simultaneously.
</t>
<t>
Number of storage qubits
</t>
<t>
Possible operations, along with their execution time and
probability of success:
<list style='numbers'>
<t>
Swap between communication and storage qubits
</t>
<t>
Entanglement swap
</t>
<t>
List of supported distillation schemes (in order of
preference).
</t>
</list>
</t>
</list>
</t>
<t>
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.
</t>
</section>
<section title='Link Properties'>
<t>
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.
</t>
</section>
</section>
<section title='The (Ab)use of Protocols'>
<t>
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.
</t>
<section title='A Brief Primer on Link-state Protocols'>
<t>
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.
</t>
<t>
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.
</t>
<t>
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).
</t>
<t>
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".
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
<xref target='RFC1195'/> has examples of "standard" LSAs for
routing; <xref target='RFC5305'/> has the so-called Traffic
Engineering LSAs.
</t>
</section>
<section title='Node Properties'>
<t>
Here, we give a protocol-independent description of quantum
node properties; later documents will specify the encoding
specifically for IS-IS and OSPF.
</t>
<t>
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.
</t>
<t>
The following node properties are added to the appropriate LSA:
<figure>
<artwork align='center'>
<Qubit-TLV><NCQ><NSQ>
<CS-Swap><Prob><ExecTime>
<Ent-Swap><Prob><ExecTime>
<Measure><Prob><ExecTime>
<NDistSch><DistScheme1><DistScheme2>
</artwork>
</figure>
</t>
</section>
<section title='Link Properties'>
<t>
Only one link property is listed. It gives the time-fidelity
tradeoffs of an entanglement operation as a list:
<figure>
<artwork align='center'>
<N-Ent-TO><time1><fid1><time2><fid2>...
</artwork>
</figure>
This is interpreted as follows: an entanglement operation may
be initiated between nodes v and w over link (v, w). Depending
on how fast one wants to complete (time-i), the list gives the
corresponding fidelity of the resulting entanglement (fid-i).
time-i is given in nanoseconds; fid-i as a number between
0 and 999999. THe denominator is 1000000.
</t>
<t>
Note that this link property is symmetric, as entanglement is
initiated simultaneously at v and w.
</t>
</section>
</section>
<section title='Security Considerations' anchor='sec-con'>
<t>
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.
</t>
</section>
<section title='Acknowledgments'>
<t>
The authors would like to thank the following people for their
contributions and support to this document: Vesna Manojlovic
(RIPE NCC) and Axel Dahlberg (QuTech). Kompella would also like
to thank Bruno Rijsman for encouraging him to learn about
Quantum Computing and Networking.
</t>
<t>
Also:
<figure>
<artwork align='left'>
_,'| _.-''``-...___..--';)
/_ \'. __..-' , ,--...--'''
<\ .`--''' ` /'
`-';' ; ; ;
__...--'' ___...--_..' .;.'
(,__....----''' (,..--''
</artwork>
</figure>
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
There are no requests as yet to IANA for this document.
</t>
</section>
</middle>
<back>
<references title='Normative References'>
<?rfc include='reference.RFC.1195'?>
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.3630'?>
<?rfc include='reference.RFC.5305'?>
<?rfc include='reference.RFC.5329'?>
<?rfc include='reference.RFC.5786'?>
</references>
<references title='Informative References'>
<reference anchor="qubit"
target="https://en.wikipedia.org/wiki/Qubit">
<front>
<title>Qubit</title>
<author/>
<date/>
</front>
</reference>
<reference anchor="QEnt"
target="https://en.wikipedia.org/wiki/Quantum_entanglement">
<front>
<title>Quantum Entanglement</title>
<author/>
<date/>
</front>
</reference>
<reference anchor="QNet"
target="https://en.wikipedia.org/wiki/Quantum_network">
<front>
<title>Quantum Network</title>
<author/>
<date/>
</front>
</reference>
<reference anchor="QTel"
target="https://en.wikipedia.org/wiki/Quantum_teleportation">
<front>
<title>Quantum Teleportation</title>
<author/>
<date/>
</front>
</reference>
<reference anchor="QFid"
target="https://en.wikipedia.org/wiki/Fidelity_of_quantum_states">
<front>
<title>Quantum Fidelity</title>
<author/>
<date/>
</front>
</reference>
<reference anchor="QInt">
<front>
<title>Quantum internet: A vision for the road ahead</title>
<author initials='S' surname='Wehner'/>
<author initials='D' surname='Elkouss'/>
<author initials='R' surname='Hanson'/>
<date year='2018'/>
</front>
<seriesInfo name='Science' value='362, 6412'/>
</reference>
<reference anchor="QDist"
target="https://arxiv.org/abs/1803.10111">
<front>
<title>Optimizing practical entanglement distillation</title>
<author initials='F' surname='Rozpedek' fullname='Filip Rozpedek'/>
<author initials='T' surname='Schiet' fullname='Thomas Schiet'/>
<author initials='L' surname='Thinh' fullname='Le Phuc Thinh'/>
<author initials='D' surname='Elkouss' fullname='David Elkouss'/>
<author initials='A' surname='Doherty' fullname='Andrew C. Doherty'/>
<author initials='S' surname='Wehner' fullname='Stephanie Wehner'/>
<date year="2018"/>
</front>
<seriesInfo name='Phys. Rev. A' value='97, 062333'/>
</reference>
<reference anchor="QKD"
target="https://en.wikipedia.org/wiki/Quantum_key_distribution">
<front>
<title>Quantum Key Distribution</title>
<author/>
<date/>
</front>
</reference>
<reference anchor="NVC"
target="https://en.wikipedia.org/wiki/Nitrogen-vacancy_center">
<front>
<title>Nitrogen-vacancy center</title>
<author/>
<date/>
</front>
</reference>
<reference anchor="NVD">
<front>
<title>
Deterministic delivery of remote entanglement on a quantum network
</title>
<author initials='P.C' surname="Humphreys" fullname='P. C. Humphreys et al.'/>
<date year='2018'/>
</front>
<seriesInfo name="Nature" value="558"/>
</reference>
<reference anchor="NVDD">
<front>
<title>
Loophole-free Bell inequality violation using electron spins
separated by 1.3 kilometres
</title>
<author initials='B' surname="Hensen"/>
<author surname='others'/>
<date year='2015'/>
</front>
<seriesInfo name="Nature" value="526"/>
</reference>
<reference anchor="IonTrap">
<front>
<title>
Modular entanglement of atomic qubits using photons and phonons
</title>
<author initials='D' surname="Hucul"/>
<author surname='others'/>
<date year='2015'/>
</front>
<seriesInfo name="Nature Physics" value="11(1)"/>
</reference>
<reference anchor="NAtom">
<front>
<title>
Efficient Teleportation Between Remote Single-Atom Quantum Memories
</title>
<author initials='C' surname="Noelleke"/>
<author surname='others'/>
<date year='2013'/>
</front>
<seriesInfo name="Physical Review Letters" value="110, 140403"/>
</reference>
<reference anchor="QAEM">
<front>
<title>
Quantum repeaters based on atomic ensembles and linear optics
</title>
<author initials='N' surname="Sangouard"/>
<author surname='others'/>
<date year='2011'/>
</front>
<seriesInfo name="Reviews of Modern Physics" value="83, 33"/>
</reference>
</references>
</back>
</rfc>