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
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
|
<pre>Internet Engineering Task Force (IETF) E. Crabbe
Request for Comments: 8232 Oracle
Category: Standards Track I. Minei
ISSN: 2070-1721 Google, Inc.
J. Medved
Cisco Systems, Inc.
R. Varga
Pantheon Technologies SRO
X. Zhang
D. Dhody
Huawei Technologies
September 2017
<span class="h1">Optimizations of Label Switched Path State Synchronization</span>
<span class="h1">Procedures for a Stateful PCE</span>
Abstract
A stateful Path Computation Element (PCE) has access to not only the
information disseminated by the network's Interior Gateway Protocol
(IGP) but also the set of active paths and their reserved resources
for its computation. The additional Label Switched Path (LSP) state
information allows the PCE to compute constrained paths while
considering individual LSPs and their interactions. This requires a
State Synchronization mechanism between the PCE and the network, the
PCE and Path Computation Clients (PCCs), and cooperating PCEs. The
basic mechanism for State Synchronization is part of the stateful PCE
specification. This document presents motivations for optimizations
to the base State Synchronization procedure and specifies the
required Path Computation Element Communication Protocol (PCEP)
extensions.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="https://www.rfc-editor.org/info/rfc8232">https://www.rfc-editor.org/info/rfc8232</a>.
<span class="grey">Crabbe, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc8232">RFC 8232</a> Optimizations of State Synchronization September 2017</span>
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a>) 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.
<span class="grey">Crabbe, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc8232">RFC 8232</a> Optimizations of State Synchronization September 2017</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-4">4</a>
<a href="#section-1.1">1.1</a>. Requirements Language ......................................<a href="#page-4">4</a>
<a href="#section-2">2</a>. Terminology .....................................................<a href="#page-5">5</a>
<a href="#section-3">3</a>. State Synchronization Avoidance .................................<a href="#page-5">5</a>
<a href="#section-3.1">3.1</a>. Motivation .................................................<a href="#page-5">5</a>
<a href="#section-3.2">3.2</a>. State Synchronization Avoidance Procedure ..................<a href="#page-5">5</a>
<a href="#section-3.2.1">3.2.1</a>. IP Address Change during Session Re-establishment ..10
<a href="#section-3.3">3.3</a>. PCEP Extensions ...........................................<a href="#page-11">11</a>
<a href="#section-3.3.1">3.3.1</a>. LSP-DB Version Number TLV ..........................<a href="#page-11">11</a>
<a href="#section-3.3.2">3.3.2</a>. Speaker Entity Identifier TLV ......................<a href="#page-12">12</a>
<a href="#section-4">4</a>. Incremental State Synchronization ..............................<a href="#page-13">13</a>
<a href="#section-4.1">4.1</a>. Motivation ................................................<a href="#page-13">13</a>
<a href="#section-4.2">4.2</a>. Incremental Synchronization Procedure .....................<a href="#page-14">14</a>
<a href="#section-5">5</a>. PCE-Triggered Initial Synchronization ..........................<a href="#page-17">17</a>
<a href="#section-5.1">5.1</a>. Motivation ................................................<a href="#page-17">17</a>
<a href="#section-5.2">5.2</a>. PCE-Triggered Initial State Synchronization Procedure .....<a href="#page-18">18</a>
<a href="#section-6">6</a>. PCE-Triggered Resynchronization ................................<a href="#page-19">19</a>
<a href="#section-6.1">6.1</a>. Motivation ................................................<a href="#page-19">19</a>
<a href="#section-6.2">6.2</a>. PCE-Triggered State Resynchronization Procedure ...........<a href="#page-19">19</a>
<a href="#section-7">7</a>. Advertising Support of Synchronization Optimizations ...........<a href="#page-20">20</a>
<a href="#section-8">8</a>. IANA Considerations ............................................<a href="#page-21">21</a>
<a href="#section-8.1">8.1</a>. PCEP-Error Object .........................................<a href="#page-21">21</a>
<a href="#section-8.2">8.2</a>. PCEP TLV Type Indicators ..................................<a href="#page-22">22</a>
<a href="#section-8.3">8.3</a>. STATEFUL-PCE-CAPABILITY TLV ...............................<a href="#page-22">22</a>
<a href="#section-9">9</a>. Manageability Considerations ...................................<a href="#page-22">22</a>
<a href="#section-9.1">9.1</a>. Control of Function and Policy ............................<a href="#page-22">22</a>
<a href="#section-9.2">9.2</a>. Information and Data Models ...............................<a href="#page-22">22</a>
<a href="#section-9.3">9.3</a>. Liveness Detection and Monitoring .........................<a href="#page-23">23</a>
<a href="#section-9.4">9.4</a>. Verify Correct Operations .................................<a href="#page-23">23</a>
<a href="#section-9.5">9.5</a>. Requirements on Other Protocols ...........................<a href="#page-23">23</a>
<a href="#section-9.6">9.6</a>. Impact on Network Operations ..............................<a href="#page-23">23</a>
<a href="#section-10">10</a>. Security Considerations .......................................<a href="#page-23">23</a>
<a href="#section-11">11</a>. References ....................................................<a href="#page-24">24</a>
<a href="#section-11.1">11.1</a>. Normative References .....................................<a href="#page-24">24</a>
<a href="#section-11.2">11.2</a>. Informative References ...................................<a href="#page-24">24</a>
Acknowledgments ...................................................<a href="#page-25">25</a>
Contributors ......................................................<a href="#page-25">25</a>
Authors' Addresses ................................................<a href="#page-26">26</a>
<span class="grey">Crabbe, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc8232">RFC 8232</a> Optimizations of State Synchronization September 2017</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The Path Computation Element Communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Client (PCC) requests.
[<a id="ref-RFC8231">RFC8231</a>] describes a set of extensions to PCEP to provide stateful
control. A stateful PCE has access to not only the information
carried by the network's Interior Gateway Protocol (IGP) but also the
set of active paths and their reserved resources for its
computations. The additional state allows the PCE to compute
constrained paths while considering individual LSPs and their
interactions. This requires a State Synchronization mechanism
between the PCE and the network, the PCE and the PCC, and cooperating
PCEs. [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>] describes the basic mechanism for State
Synchronization. This document specifies following optimizations for
State Synchronization and the corresponding PCEP procedures and
extensions:
o State Synchronization Avoidance: To skip State Synchronization if
the state has survived and not changed during session restart.
(See <a href="#section-3">Section 3</a>.)
o Incremental State Synchronization: To do incremental (delta) State
Synchronization when possible. (See <a href="#section-4">Section 4</a>.)
o PCE-Triggered Initial Synchronization: To let PCE control the
timing of the initial State Synchronization. (See <a href="#section-5">Section 5</a>.)
o PCE-Triggered Resynchronization: To let PCE resynchronize the
state for sanity check. (See <a href="#section-6">Section 6</a>.)
Support for each of the synchronization optimization capabilities is
advertised during the PCEP initialization phase. See <a href="#section-7">Section 7</a> for
the new flags defined in this document. The handling of each flag is
described in the relevant section.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Requirements Language</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in <a href="https://www.rfc-editor.org/bcp/bcp14">BCP</a>
<a href="https://www.rfc-editor.org/bcp/bcp14">14</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] [<a href="./rfc8174" title=""Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"">RFC8174</a>] when, and only when, they appear in all
capitals, as shown here.
<span class="grey">Crabbe, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc8232">RFC 8232</a> Optimizations of State Synchronization September 2017</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
This document uses the following terms defined in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>]: PCC,
PCE, and PCEP Peer.
This document uses the following terms defined in [<a href="./rfc8051" title=""Applicability of a Stateful Path Computation Element (PCE)"">RFC8051</a>]: Stateful
PCE, Delegation, and LSP State Database (LSP-DB).
This document uses the following terms defined in [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>]:
Redelegation Timeout Interval, LSP State Report, and LSP Update
Request.
Within this document, when describing PCE-PCE communications, the
requesting PCE fills the role of a PCC as usual.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. State Synchronization Avoidance</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Motivation</span>
The purpose of State Synchronization is to provide a
checkpoint-in-time state replica of a PCC's LSP state in a stateful
PCE. State Synchronization is performed immediately after the
initialization phase [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>]. [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>] describes the basic
mechanism for State Synchronization.
State Synchronization is not always necessary following a PCEP
session restart. If the state of both PCEP peers did not change, the
synchronization phase may be skipped. This can result in significant
savings in both control-plane data exchanges and the time it takes
for the stateful PCE to become fully operational.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. State Synchronization Avoidance Procedure</span>
State Synchronization MAY be skipped following a PCEP session restart
if the state of both PCEP peers did not change during the period
prior to session re-initialization. To be able to make this
determination, state must be exchanged and maintained by both PCE and
PCC during normal operation. This is accomplished by keeping track
of the changes to the LSP-DB, using a version tracking field called
the LSP-DB Version Number.
The INCLUDE-DB-VERSION (S) bit in the STATEFUL-PCE-CAPABILITY TLV
(<a href="#section-7">Section 7</a>) is advertised on a PCEP session during session startup to
indicate that the LSP-DB Version Number is to be included when the
LSPs are reported to the PCE. The LSP-DB Version Number, carried in
LSP-DB-VERSION TLV (see <a href="#section-3.3.1">Section 3.3.1</a>), is owned by a PCC, and it
MUST be incremented by 1 for each successive change in the PCC's LSP-
DB. The LSP-DB Version Number MUST start at 1 and may wrap around.
<span class="grey">Crabbe, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc8232">RFC 8232</a> Optimizations of State Synchronization September 2017</span>
Values 0 and 0xFFFFFFFFFFFFFFFF are reserved. If either of the two
values are used during LSP State (re)Synchronization, the PCE speaker
receiving this value MUST send back a PCEP Error (PCErr) with Error-
type=20 and Error-value=6 'Received an invalid LSP-DB Version
Number', and close the PCEP session. Operations that trigger a
change to the local LSP-DB include a change in the LSP operational
state, delegation of an LSP, removal or setup of an LSP, or change in
any of the LSP attributes that would trigger a report to the PCE.
If the include LSP-DB version capability is enabled, a PCC MUST
increment its LSP-DB Version Number when the 'Redelegation Timeout
Interval' timer expires (see [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>] for the use of the
Redelegation Timeout Interval).
If both PCEP speakers set the S flag in the OPEN object's
STATEFUL-PCE-CAPABILITY TLV to 1, the PCC MUST include the LSP-DB-
VERSION TLV in each LSP object of the Path Computation LSP State
Report (PCRpt) message. If the LSP-DB-VERSION TLV is missing in a
PCRpt message, the PCE will generate an error with Error-type=6
(Mandatory Object missing) and Error-value=12 'LSP-DB-VERSION TLV
missing', and close the session. If the include LSP-DB version
capability has not been enabled on a PCEP session, the PCC SHOULD NOT
include the LSP-DB-VERSION TLV in the LSP Object, and the PCE MUST
ignore it, were it to receive one.
If a PCE's LSP-DB survived the restart of a PCEP session, the PCE
will include the LSP-DB-VERSION TLV in its OPEN object, and the TLV
will contain the last LSP-DB Version Number received on an LSP State
Report from the PCC in the previous PCEP session. If a PCC's LSP-DB
survived the restart of a PCEP session, the PCC will include the LSP-
DB-VERSION TLV in its OPEN object, and the TLV will contain the
latest LSP-DB Version Number. If a PCEP speaker's LSP-DB did not
survive the restart of a PCEP session or at startup when the database
is empty, the PCEP speaker MUST NOT include the LSP-DB-VERSION TLV in
the OPEN object.
If both PCEP speakers include the LSP-DB-VERSION TLV in the OPEN
object and the TLV values match, the PCC MAY skip State
Synchronization, and the PCE does not wait for the end-of-
synchronization marker [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>]. Otherwise, the PCC MUST perform
full State Synchronization (see [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>]) or incremental State
Synchronization (see <a href="#section-4">Section 4</a> if this capability is advertised) to
the stateful PCE. In other words, if the incremental State
Synchronization capability is not advertised by the peers, based on
the LSP-DB Version Number match, either the State Synchronization is
skipped or a full State Synchronization is performed. If the PCC
attempts to skip State Synchronization, by setting the SYNC flag to 0
and PLSP-ID to a non-zero value on the first LSP State Report from
<span class="grey">Crabbe, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc8232">RFC 8232</a> Optimizations of State Synchronization September 2017</span>
the PCC as per [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>], the PCE MUST send back a PCErr with Error-
type=20 and Error-value=2 'LSP-DB version mismatch', and close the
PCEP session.
If State Synchronization is required, then prior to completing the
initialization phase, the PCE MUST mark any LSPs in the LSP-DB that
were previously reported by the PCC as stale. When the PCC reports
an LSP during State Synchronization, if the LSP already exists in the
LSP-DB, the PCE MUST update the LSP-DB and clear the stale marker
from the LSP. When it has finished State Synchronization, the PCC
MUST immediately send an end-of-synchronization marker. The end-of-
synchronization marker is a PCRpt message with an LSP object
containing a PLSP-ID of 0 and with the SYNC flag set to 0 [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>].
The LSP-DB-VERSION TLV MUST be included in this PCRpt message. On
receiving this state report, the PCE MUST purge any LSPs from the
LSP-DB that are still marked as stale.
Note that a PCE/PCC MAY force State Synchronization by not including
the LSP-DB-VERSION TLV in its OPEN object.
Since a PCE does not make changes to the LSP-DB Version Number, a PCC
should never encounter this TLV in a message from the PCE (other than
the OPEN message). A PCC SHOULD ignore the LSP-DB-VERSION TLV, were
it to receive one from a PCE.
Figure 1 shows an example sequence where the State Synchronization is
skipped.
<span class="grey">Crabbe, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc8232">RFC 8232</a> Optimizations of State Synchronization September 2017</span>
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|--Open--, |
| DBv=42 \ ,---Open--|
| S=1 \ / DBv=42 |
| \/ S=1 |
| /\ |
| / `-------->| (OK to skip sync)
(Skip sync) |<--------` |
| . |
| . |
| . |
| |
|--PCRpt,DBv=43,SYNC=0-->| (Regular
| | LSP State Report)
|--PCRpt,DBv=44,SYNC=0-->| (Regular
| | LSP State Report)
|--PCRpt,DBv=45,SYNC=0-->|
| |
Figure 1: State Synchronization Skipped
Figure 2 shows an example sequence where the State Synchronization is
performed due to LSP-DB version mismatch during the PCEP session
setup. Note that the same State Synchronization sequence would
happen if either the PCC or the PCE would not include the LSP-DB-
VERSION TLV in their respective Open messages.
<span class="grey">Crabbe, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc8232">RFC 8232</a> Optimizations of State Synchronization September 2017</span>
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|--Open--, |
| DBv=46 \ ,---Open--|
| S=1 \ / DBv=42 |
| \/ S=1 |
| /\ |
| / `-------->| (Expect sync)
(Do sync) |<--------` |
| |
|--PCRpt,DBv=46,SYNC=1-->| (Sync start)
| . |
| . |
| . |
|--PCRpt,DBv=46,SYNC=0-->| (Sync done)
| . | (Purge LSP state
| . | if applicable)
| . |
|--PCRpt,DBv=47,SYNC=0-->| (Regular
| | LSP State Report)
|--PCRpt,DBv=48,SYNC=0-->| (Regular
| | LSP State Report)
|--PCRpt,DBv=49,SYNC=0-->|
| |
Figure 2: State Synchronization Performed
Figure 3 shows an example sequence where the State Synchronization is
skipped, but because one or both PCEP speakers set the S flag to 0,
the PCC does not send LSP-DB-VERSION TLVs in subsequent PCRpt
messages to the PCE. If the current PCEP session restarts, the PCEP
speakers will have to perform State Synchronization, since the PCE
does not know the PCC's latest LSP-DB Version Number information.
<span class="grey">Crabbe, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc8232">RFC 8232</a> Optimizations of State Synchronization September 2017</span>
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|--Open--, |
| DBv=42 \ ,---Open--|
| S=0 \ / DBv=42 |
| \/ S=0 |
| /\ |
| / `-------->| (OK to skip sync)
(Skip sync) |<--------` |
| . |
| . |
| . |
|------PCRpt,SYNC=0----->| (Regular
| | LSP State Report)
|------PCRpt,SYNC=0----->| (Regular
| | LSP State Report)
|------PCRpt,SYNC=0----->|
| |
Figure 3: State Synchronization Skipped;
No LSP-DB-VERSION TLVs Sent from the PCC
<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>. IP Address Change during Session Re-establishment</span>
There could be a case during PCEP session re-establishment when the
PCC's or PCE's IP address can change. This includes, but is not
limited to, the following cases:
o A PCC could use a physical interface IP address to connect to the
PCE. In this case, if the line card that the PCC connects from
changes, then the PCEP session goes down and comes back up again,
with a different IP address associated with a new line card.
o The PCC or PCE may move in the network, either physically or
logically, which may cause its IP address to change. For example,
the PCE may be deployed as a virtual network function (VNF), and
another virtualized instance of the PCE may be populated with the
original PCE instance's state, but it may be given a different IP
address.
To ensure that a PCEP peer can recognize a previously connected peer,
each PCEP peer includes the SPEAKER-ENTITY-ID TLV described in
<a href="#section-3.3.2">Section 3.3.2</a> in the OPEN message.
<span class="grey">Crabbe, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc8232">RFC 8232</a> Optimizations of State Synchronization September 2017</span>
This TLV is used during the State Synchronization procedure to
identify the PCEP session as a re-establishment of a previous session
that went down. Then State Synchronization optimizations such as
state sync avoidance can be applied to this session. Note that this
usage is only applicable within the State Timeout Interval [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>].
After the State Timeout Interval expires, all state associated with
the PCEP session is removed, which includes the SPEAKER-ENTITY-ID
received. Note that the PCEP session initialization [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>]
procedure remains unchanged.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. PCEP Extensions</span>
A new INCLUDE-DB-VERSION (S) bit is added in the stateful
capabilities TLV (see <a href="#section-7">Section 7</a> for details).
<span class="h4"><a class="selflink" id="section-3.3.1" href="#section-3.3.1">3.3.1</a>. LSP-DB Version Number TLV</span>
The LSP-DB Version Number (LSP-DB-VERSION) TLV is an optional TLV
that MAY be included in the OPEN object and the LSP object.
This TLV is included in the LSP object in the PCRpt message to
indicate the LSP-DB version at the PCC. This TLV SHOULD NOT be
included in other PCEP messages (Path Computation Update Request
(PCUpd), Path Computation Request (PCReq), and Path Computation Reply
(PCRep)) and MUST be ignored if received.
The format of the LSP-DB-VERSION TLV is shown in the following
figure:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=23 | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP-DB Version Number |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: LSP-DB-VERSION TLV Format
The type of the TLV is 23, and it has a fixed length of 8 octets.
The value contains a 64-bit unsigned integer, carried in network byte
order, representing the LSP-DB Version Number.
<span class="grey">Crabbe, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc8232">RFC 8232</a> Optimizations of State Synchronization September 2017</span>
<span class="h4"><a class="selflink" id="section-3.3.2" href="#section-3.3.2">3.3.2</a>. Speaker Entity Identifier TLV</span>
The Speaker Entity Identifier TLV (SPEAKER-ENTITY-ID) is an optional
TLV that MAY be included in the OPEN object when a PCEP speaker
wishes to determine if State Synchronization can be skipped when a
PCEP session is restarted. It contains a unique identifier for the
node that does not change during the lifetime of the PCEP speaker.
It identifies the PCEP speaker to its peers even if the speaker's IP
address is changed.
In case of a remote peer IP address change, a PCEP speaker would
learn the Speaker Entity Identifier on receiving the open message,
but it MAY have already sent its open message without realizing that
it is a known PCEP peer. In such a case, either a full
synchronization is done or the PCEP session is terminated. This may
be a local policy decision. The new IP address is associated with
the Speaker Entity Identifier for the future either way. In the
latter case when the PCEP session is re-established, it would be
correctly associated with the Speaker Entity Identifier and not be
considered as an unknown peer.
The format of the SPEAKER-ENTITY-ID TLV is shown in the following
figure:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=24 | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Speaker Entity Identifier //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: SPEAKER-ENTITY-ID TLV Format
The type of the TLV is 24, and it has a variable length, which MUST
be greater than 0. The value is padded to a 4-octet alignment. The
padding is not included in the Length field. The value contains the
Speaker Entity Identifier (an identifier of the PCEP speaker
transmitting this TLV). This identifier is required to be unique
within its scope of visibility, which is usually limited to a single
domain. It MAY be configured by the operator. Alternatively, it can
be derived automatically from a suitably stable unique identifier,
<span class="grey">Crabbe, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc8232">RFC 8232</a> Optimizations of State Synchronization September 2017</span>
such as a Media Access Control (MAC) address, serial number, Traffic
Engineering Router ID, or similar. In the case of inter-domain
connections, the speaker SHOULD prefix its usual identifier with the
domain identifier of its residence, such as an Autonomous System
number, an IGP area identifier, or similar to make sure it remains
unique.
The relationship between this identifier and entities in the Traffic
Engineering database is intentionally left undefined.
From a manageability point of view, a PCE or PCC implementation
SHOULD allow the operator to configure this Speaker Entity
Identifier.
If a PCEP speaker receives the SPEAKER-ENTITY-ID on a new PCEP
session, that matches with an existing alive PCEP session, the PCEP
speaker MUST send a PCErr with Error-type=20 and Error-value=7
'Received an invalid Speaker Entity Identifier', and close the PCEP
session.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Incremental State Synchronization</span>
[<a id="ref-RFC8231">RFC8231</a>] describes the LSP State Synchronization mechanism between
PCCs and stateful PCEs. During the State Synchronization, a PCC
sends the information of all its LSPs (i.e., the full LSP-DB) to the
stateful PCE. In order to reduce the State Synchronization overhead
when there is a small number of LSP state changes in the network
between the PCEP session restart, this section defines a mechanism
for incremental (Delta) LSP-DB synchronization.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Motivation</span>
According to [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>], if a PCE restarts and its LSP-DB survived,
PCCs with a mismatched LSP-DB Version Number will send all their LSPs
information (full LSP-DB) to the stateful PCE, even if only a small
number of LSPs underwent state change. It can take a long time and
consume large communication channel bandwidth.
Figure 6 shows an example of LSP State Synchronization.
<span class="grey">Crabbe, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc8232">RFC 8232</a> Optimizations of State Synchronization September 2017</span>
+-----+
| PCE |
+-----+
/
/
/
/
+------+ +------+
| PCC1 |------------| PCC2 |
+------+ +------+
| |
| |
+------+ +------+
| PCC3 |------------| PCC4 |
+------+ +------+
Figure 6: Topology Example
Assume that there are 320 LSPs in the network, with each PCC having
80 LSPs. During the time when the PCEP session is down, 20 LSPs of
each PCC (i.e., 80 LSPs in total), are changed. Hence, when the PCEP
session restarts, the stateful PCE needs to synchronize 320 LSPs with
all PCCs. But actually, 240 LSPs stay the same. If performing full
LSP State Synchronization, it can take a long time to carry out the
synchronization of all LSPs. It is especially true when only a low
bandwidth communication channel is available (e.g., in-band control
channel for optical transport networks), and there is a substantial
number of LSPs in the network. Another disadvantage of full LSP
synchronization is that it is a waste of communication bandwidth to
perform full LSP synchronization given the fact that the number of
LSP changes can be small during the time when the PCEP session is
down.
An incremental (Delta) LSP-DB State Synchronization is described in
this section, where only the LSPs that underwent state change are
synchronized between the session restart. This may include
new/modified/deleted LSPs.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Incremental Synchronization Procedure</span>
[<a id="ref-RFC8231">RFC8231</a>] describes State Synchronization and <a href="#section-3">Section 3</a> of this
document describes State Synchronization avoidance by using
LSP-DB-VERSION TLV in its OPEN object. This section extends this
idea to only synchronize the delta (changes) in case of version
mismatch.
<span class="grey">Crabbe, et al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc8232">RFC 8232</a> Optimizations of State Synchronization September 2017</span>
If both PCEP speakers include the LSP-DB-VERSION TLV in the OPEN
object and the LSP-DB-VERSION TLV values match, the PCC MAY skip
State Synchronization. Otherwise, the PCC MUST perform State
Synchronization. Incremental State Synchronization capability is
advertised on a PCEP session during session startup using the
DELTA-LSP-SYNC-CAPABILITY (D) bit in the capabilities TLV (see
<a href="#section-7">Section 7</a>). Instead of dumping full LSP-DB to the stateful PCE
again, the PCC synchronizes the delta (changes) as described in
Figure 7 when the D and S flags are set to 1 by both the PCC and PCE.
Other combinations of D and S flags set by the PCC and PCE result in
full LSP-DB synchronization procedures as described in [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>]. By
setting the D flag to zero in the OPEN message, a PCEP speaker can
skip the incremental synchronization optimization, resulting in a
full LSP-DB synchronization.
<span class="grey">Crabbe, et al. Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc8232">RFC 8232</a> Optimizations of State Synchronization September 2017</span>
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|--Open--, |
| DBv=46 \ ,---Open--|
| S=1 \ / DBv=42 |
| D=1 \/ S=1 |
| /\ D=1 |
| / \ |
| / `-------->| (Expect delta sync)
(Do sync)|<--------` | (DO NOT purge LSP
(Delta) | | state)
| |
(Delta sync starts) |--PCRpt,DBv=46,SYNC=1-->|
| . |
| . |
| . |
| . |
|--PCRpt,DBv=46,SYNC=0-->| (Sync done,
| | PLSP-ID=0)
| |
|--PCRpt,DBv=47,SYNC=0-->| (Regular
| | LSP State Report)
|--PCRpt,DBv=48,SYNC=0-->| (Regular
| | LSP State Report)
|--PCRpt,DBv=49,SYNC=0-->|
| |
Figure 7: Incremental Synchronization Procedure
As per <a href="#section-3">Section 3</a>, the LSP-DB Version Number is incremented each time
a change is made to the PCC's local LSP-DB. Each LSP is associated
with the DB version at the time of its state change. This is needed
to determine which LSP and what information needs to be synchronized
in incremental State Synchronization. The incremental state sync is
done from the last LSP-DB version received by the PCE to the latest
DB version at the PCC. Note that the LSP-DB Version Number can wrap
around, in which case the incremental state sync would also wrap till
the latest LSP-DB Version Number at the PCC.
In order to carry out incremental State Synchronization, it is not
necessary for a PCC to store a complete history of LSP-DB change for
all time, but remember the LSP state changes (including LSP
modification, setup, and deletion) that the PCE did not get to
process during the session down. Note that, a PCC would be unaware
that a particular LSP report has been processed by the PCE before the
session to the PCE went down. So a PCC implementation MAY choose to
<span class="grey">Crabbe, et al. Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc8232">RFC 8232</a> Optimizations of State Synchronization September 2017</span>
store the LSP-DB Version Number with each LSP at the time its status
changed, so that when a session is re-established, an incremental
synchronization can be attempted based on the PCE's last LSP-DB
Version Number. For an LSP that is deleted at the PCC, the PCC
implementation would need to remember the deleted LSP in some way to
make sure this could be reported as part of incremental
synchronization later. The PCC would discard this information based
on a local policy or when it determines that this information is no
longer needed with sufficient confidence. In the example shown in
Figure 7, the PCC needs to store the LSP state changes that happened
between DB Versions 43 to 46 and synchronize these changes, when
performing incremental LSP state update.
If a PCC finds out it does not have sufficient information to
complete incremental synchronization after advertising incremental
LSP State Synchronization capability, it MUST send a PCErr with
Error-type=20 and Error-value=5 'A PCC indicates to a PCE that it can
not complete the State Synchronization' (defined in [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>]), and
terminate the session. The PCC SHOULD re-establish the session with
the D bit set to 0 in the OPEN message.
The other procedures and error checks remain unchanged from the full
State Synchronization [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>].
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. PCE-Triggered Initial Synchronization</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Motivation</span>
In networks such as optical transport networks, the control channel
between network nodes can be realized through in-band overhead, thus
it has limited bandwidth. With a stateful PCE connected to the
network via one network node, it is desirable to control the timing
of PCC State Synchronization so as not to overload the low
communication channel available in the network during the initial
synchronization (be it incremental or full) when the session
restarts, when there is a comparatively large amount of control
information needing to be synchronized between the stateful PCE and
the network. The method proposed, i.e., allowing PCE to trigger the
State Synchronization, is similar to the function proposed in
<a href="#section-6">Section 6</a> but is used in different scenarios and for different
purposes.
<span class="grey">Crabbe, et al. Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc8232">RFC 8232</a> Optimizations of State Synchronization September 2017</span>
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. PCE-Triggered Initial State Synchronization Procedure</span>
Support of PCE-triggered initial State Synchronization is advertised
during session startup using the TRIGGERED-INITIAL-SYNC (F) bit in
the STATEFUL-PCE-CAPABILITY TLV (see <a href="#section-7">Section 7</a>).
In order to allow a stateful PCE to control the LSP-DB
synchronization after establishing a PCEP session, both PCEP speakers
MUST set the F bit to 1 in the OPEN message. If the LSP-DB-VERSION
TLV is included by both PCEP speakers and the TLV value matches, the
State Synchronization can be skipped as described in <a href="#section-3.2">Section 3.2</a>. If
the TLV is not included or the LSP-DB Version is mismatched, the PCE
can trigger the State Synchronization process by sending a PCUpd
message with PLSP-ID = 0 and SYNC = 1. The PCUpd message SHOULD
include an empty Explicit Route Object (ERO) (with no ERO sub-object
and object length of 4) as its intended path and SHOULD NOT include
the optional objects for its attributes for any parameter update.
The PCC MUST ignore such an update when the SYNC flag is set. If the
TRIGGERED-INITIAL-SYNC capability is not advertised by a PCE and the
PCC receives a PCUpd with the SYNC flag set to 1, the PCC MUST send a
PCErr with the SRP-ID-number of the PCUpd, Error-type=20, and
Error-value=4 'Attempt to trigger a synchronization when the PCE
triggered synchronization capability has not been advertised' (see
<a href="#section-8.1">Section 8.1</a>). If the TRIGGERED-INITIAL-SYNC capability is advertised
by a PCE and the PCC, the PCC MUST NOT trigger State Synchronization
on its own. If the PCE receives a PCRpt message before the PCE has
triggered the State Synchronization, the PCE MUST send a PCErr with
Error-type=20 and Error-value=3 'Attempt to trigger synchronization
before PCE trigger' (see <a href="#section-8.1">Section 8.1</a>).
In this way, the PCE can control the sequence of LSP synchronization
among all the PCCs that are re-establishing PCEP sessions with it.
When the capability of PCE control is enabled, only after a PCC
receives this message, it will start sending information to the PCE.
This PCE-triggering capability can be applied to both full and
incremental State Synchronization. If applied to the latter, the
PCCs only send information that PCE does not possess, which is
inferred from the LSP-DB version information exchanged in the OPEN
message (see <a href="#section-4.2">Section 4.2</a> for a detailed procedure).
Once the initial State Synchronization is triggered by the PCE, the
procedures and error checks remain unchanged [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>].
If a PCC implementation that does not implement this extension should
not receive a PCUpd message to trigger State Synchronization as per
the capability advertisement, but if it were to receive it, it will
behave as per [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>].
<span class="grey">Crabbe, et al. Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc8232">RFC 8232</a> Optimizations of State Synchronization September 2017</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. PCE-Triggered Resynchronization</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Motivation</span>
The accuracy of the computations performed by the PCE is tied to the
accuracy of the view the PCE has on the state of the LSPs.
Therefore, it can be beneficial to be able to resynchronize this
state even after the session has been established. The PCE may use
this approach to continuously sanity check its state against the
network or to recover from error conditions without having to tear
down sessions.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. PCE-Triggered State Resynchronization Procedure</span>
Support of PCE-triggered state resynchronization is advertised by
both PCEP speakers during session startup using the TRIGGERED-RESYNC
(T) bit in the STATEFUL-PCE-CAPABILITY TLV (see <a href="#section-7">Section 7</a>). The PCE
can choose to resynchronize its entire LSP-DB or a single LSP.
To trigger resynchronization for an LSP, the PCE sends a Path
Computation State Update (PCUpd) for the LSP, with the SYNC flag in
the LSP object set to 1. The PCE SHOULD NOT include any parameter
updates for the LSP, and the PCC MUST ignore such an update when the
SYNC flag is set. The PCC MUST respond with a PCRpt message with the
LSP state, SYNC flag set to 0 and MUST include the SRP-ID-number of
the PCUpd message that triggered the resynchronization. If the PCC
cannot find the LSP in its database, PCC MUST also set the R (remove)
flag [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>] in the LSP object in the PCRpt message.
The PCE can also trigger resynchronization of the entire LSP-DB. The
PCE MUST first mark all LSPs in the LSP-DB that were previously
reported by the PCC as stale, and then send a PCUpd with an LSP
object containing a PLSP-ID of 0 and with the SYNC flag set to 1.
The PCUpd message MUST include an empty ERO (with no ERO sub-object
and object length of 4) as its intended path and SHOULD NOT include
the optional objects for its attributes for any parameter update.
The PCC MUST ignore such update if the SYNC flag is set. This PCUpd
message is the trigger for the PCC to enter the synchronization phase
as described in [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>] and start sending PCRpt messages. After
the receipt of the end-of-synchronization marker, the PCE will purge
LSPs that were not refreshed. The SRP-ID-number of the PCUpd that
triggered the resynchronization SHOULD be included in each of the
PCRpt messages. If the PCC cannot resynchronize the entire LSP-DB,
the PCC MUST respond with a PCErr message with Error-type=20 and
Error-value=5 'cannot complete the State Synchronization' [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>],
and it MAY terminate the session. The PCE MUST remove the stale mark
for the LSPs that were previously reported by the PCC. Based on the
local policy, the PCE MAY reattempt synchronization at a later time.
<span class="grey">Crabbe, et al. Standards Track [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc8232">RFC 8232</a> Optimizations of State Synchronization September 2017</span>
If the TRIGGERED-RESYNC capability is not advertised by a PCE and the
PCC receives a PCUpd with the SYNC flag set to 1, it MUST send a
PCErr with the SRP-ID-number of the PCUpd, Error-type=20, and
Error-value=4 'Attempt to trigger a synchronization when the PCE
triggered synchronization capability has not been advertised' (see
<a href="#section-8.1">Section 8.1</a>).
Once the state resynchronization is triggered by the PCE, the
procedures and error checks remain unchanged from the full state
synchronization [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>]. This would also include the PCE
triggering multiple state resynchronization requests while
synchronization is in progress.
If a PCC implementation that does not implement this extension should
not receive a PCUpd message to trigger resynchronization as per the
capability advertisement, but if it were to receive it, it will
behave as per [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>].
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Advertising Support of Synchronization Optimizations</span>
Support for each of the optimizations described in this document
requires advertising the corresponding capabilities during session
establishment time.
The STATEFUL-PCE-CAPABILITY TLV is defined in [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>]. This
document defines the following new flags in the
STATEFUL-PCE-CAPABILITY TLV:
Bit Description
------------------------- ---------------------------------
30 S bit (INCLUDE-DB-VERSION)
27 D bit (DELTA-LSP-SYNC-CAPABILITY)
26 F bit (TRIGGERED-INITIAL-SYNC)
28 T bit (TRIGGERED-RESYNC)
If the S bit (INCLUDE-DB-VERSION) is set to 1 by both PCEP speakers,
the PCC will include the LSP-DB-VERSION TLV in each LSP object. See
<a href="#section-3.2">Section 3.2</a> for details.
If the D bit (DELTA-LSP-SYNC-CAPABILITY) is set to 1 by a PCEP
speaker, it indicates that the PCEP speaker allows incremental
(delta) State Synchronization. See <a href="#section-4.2">Section 4.2</a> for details.
If the F bit (TRIGGERED-INITIAL-SYNC) is set to 1 by both PCEP
speakers, the PCE SHOULD trigger initial (first) State
Synchronization. See <a href="#section-5.2">Section 5.2</a> for details.
<span class="grey">Crabbe, et al. Standards Track [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc8232">RFC 8232</a> Optimizations of State Synchronization September 2017</span>
If the T bit (TRIGGERED-RESYNC) is set to 1 by both PCEP speakers,
the PCE can trigger resynchronization of LSPs at any point in the
life of the session. See <a href="#section-6.2">Section 6.2</a> for details.
See <a href="#section-8.3">Section 8.3</a> for IANA allocations.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. IANA Considerations</span>
IANA has allocated code points for the protocol elements defined in
this document.
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. PCEP-Error Object</span>
IANA has allocated the following values in the "PCEP-ERROR Object
Error Types and Values" registry.
Error-Type Meaning Reference
------------------------------------------------------------
6 Mandatory Object missing [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>]
Error-value
12: LSP-DB-VERSION TLV missing This document
20 LSP State Synchronization Error [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>]
Error-value
2: LSP-DB version mismatch. This document
3: Attempt to trigger This document
synchronization before PCE
trigger.
4: Attempt to trigger a This document
synchronization when the
PCE triggered synchronization
capability has not been
advertised.
6: Received an invalid This document
LSP-DB Version Number.
7: Received an invalid This document
Speaker Entity Identifier.
<span class="grey">Crabbe, et al. Standards Track [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc8232">RFC 8232</a> Optimizations of State Synchronization September 2017</span>
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. PCEP TLV Type Indicators</span>
IANA has allocated the following values in the "PCEP TLV Type
Indicators" registry.
Value Meaning Reference
------------------------- ----------------- -------------
23 LSP-DB-VERSION This document
24 SPEAKER-ENTITY-ID This document
<span class="h3"><a class="selflink" id="section-8.3" href="#section-8.3">8.3</a>. STATEFUL-PCE-CAPABILITY TLV</span>
The STATEFUL-PCE-CAPABILITY TLV is defined in [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>]. The
"STATEFUL-PCE-CAPABILITY TLV Flag Field" registry has been created to
manage the flags in the TLV. IANA has allocated the following values
in this registry.
Bit Description Reference
-------------------------- -------------------------- -------------
26 TRIGGERED-INITIAL-SYNC This document
27 DELTA-LSP-SYNC-CAPABILITY This document
28 TRIGGERED-RESYNC This document
30 INCLUDE-DB-VERSION This document
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Manageability Considerations</span>
All manageability requirements and considerations listed in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>]
and [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>] apply to PCEP protocol extensions defined in this
document. In addition, requirements and considerations listed in
this section apply.
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Control of Function and Policy</span>
A PCE or PCC implementation MUST allow configuring the State
Synchronization optimization capabilities as described in this
document. The implementation SHOULD also allow the operator to
configure the Speaker Entity Identifier (<a href="#section-3.3.2">Section 3.3.2</a>). Further,
the operator SHOULD be to be allowed to trigger the resynchronization
procedures as per <a href="#section-6.2">Section 6.2</a>.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Information and Data Models</span>
An implementation SHOULD allow the operator to view the stateful
capabilities advertised by each peer and the current synchronization
status with each peer. To serve this purpose, the PCEP YANG module
[<a href="#ref-PCEP-YANG">PCEP-YANG</a>] can be extended to include advertised stateful
capabilities and synchronization status.
<span class="grey">Crabbe, et al. Standards Track [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc8232">RFC 8232</a> Optimizations of State Synchronization September 2017</span>
<span class="h3"><a class="selflink" id="section-9.3" href="#section-9.3">9.3</a>. Liveness Detection and Monitoring</span>
Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already
listed in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>].
<span class="h3"><a class="selflink" id="section-9.4" href="#section-9.4">9.4</a>. Verify Correct Operations</span>
Mechanisms defined in this document do not imply any new operation
verification requirements in addition to those already listed in
[<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>] and [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>].
<span class="h3"><a class="selflink" id="section-9.5" href="#section-9.5">9.5</a>. Requirements on Other Protocols</span>
Mechanisms defined in this document do not imply any new requirements
on other protocols.
<span class="h3"><a class="selflink" id="section-9.6" href="#section-9.6">9.6</a>. Impact on Network Operations</span>
Mechanisms defined in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>] and [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>] also apply to PCEP
extensions defined in this document.
The State Synchronization optimizations described in this document
can result in a reduction of the amount of data exchanged and the
time taken for a stateful PCE to be fully operational when a PCEP
session is re-established. The ability to trigger resynchronization
by the PCE can be utilized by the operator to sanity check its state
and recover from any mismatch in state without tearing down the
session.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Security Considerations</span>
The security considerations listed in [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>] apply to this
document as well. However, this document also introduces some new
attack vectors. An attacker could spoof the SPEAKER-ENTITY-ID and
pretend to be another PCEP speaker. An attacker may flood the PCC
with triggered resynchronization requests at a rate that exceeds the
PCC's ability to process them by either spoofing messages or
compromising the PCE itself. The PCC can respond with a PCErr
message as described in <a href="#section-6.2">Section 6.2</a> and terminate the session. Thus,
securing the PCEP session using Transport Layer Security (TLS)
[<a href="#ref-PCEPS" title=""Secure Transport for PCEP"">PCEPS</a>], as per the recommendations and best current practices in
[<a href="./rfc7525" title=""Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"">RFC7525</a>], is RECOMMENDED. An administrator could also expose the
Speaker Entity Identifier as part of the certificate, for the peer
identity verification.
<span class="grey">Crabbe, et al. Standards Track [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc8232">RFC 8232</a> Optimizations of State Synchronization September 2017</span>
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. References</span>
<span class="h3"><a class="selflink" id="section-11.1" href="#section-11.1">11.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC5440">RFC5440</a>] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", <a href="./rfc5440">RFC 5440</a>,
DOI 10.17487/RFC5440, March 2009,
<<a href="https://www.rfc-editor.org/info/rfc5440">https://www.rfc-editor.org/info/rfc5440</a>>.
[<a id="ref-RFC8174">RFC8174</a>] Leiba, B., "Ambiguity of Uppercase vs Lowercase in <a href="./rfc2119">RFC</a>
<a href="./rfc2119">2119</a> Key Words", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc8174">RFC 8174</a>, DOI 10.17487/RFC8174,
May 2017, <<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>>.
[<a id="ref-RFC8231">RFC8231</a>] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", <a href="./rfc8231">RFC 8231</a>,
DOI 10.17487/RFC8231, September 2017,
<<a href="http://www.rfc-editor.org/info/rfc8231">http://www.rfc-editor.org/info/rfc8231</a>>.
<span class="h3"><a class="selflink" id="section-11.2" href="#section-11.2">11.2</a>. Informative References</span>
[<a id="ref-PCEP-YANG">PCEP-YANG</a>]
Dhody, D., Hardwick, J., Beeram, V., and j.
jefftant@gmail.com, "A YANG Data Model for Path
Computation Element Communications Protocol (PCEP)", Work
in Progress, <a href="./draft-ietf-pce-pcep-yang-05">draft-ietf-pce-pcep-yang-05</a>, July 2017.
[<a id="ref-PCEPS">PCEPS</a>] Lopez, D., Dios, O., Wu, Q., and D. Dhody, "Secure
Transport for PCEP", Work in Progress,
<a href="./draft-ietf-pce-pceps-18">draft-ietf-pce-pceps-18</a>, September 2017.
[<a id="ref-RFC7525">RFC7525</a>] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", <a href="https://www.rfc-editor.org/bcp/bcp195">BCP 195</a>, <a href="./rfc7525">RFC 7525</a>, DOI 10.17487/RFC7525, May
2015, <<a href="https://www.rfc-editor.org/info/rfc7525">https://www.rfc-editor.org/info/rfc7525</a>>.
[<a id="ref-RFC8051">RFC8051</a>] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
Stateful Path Computation Element (PCE)", <a href="./rfc8051">RFC 8051</a>,
DOI 10.17487/RFC8051, January 2017,
<<a href="https://www.rfc-editor.org/info/rfc8051">https://www.rfc-editor.org/info/rfc8051</a>>.
<span class="grey">Crabbe, et al. Standards Track [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc8232">RFC 8232</a> Optimizations of State Synchronization September 2017</span>
Acknowledgments
We would like to thank Young Lee, Sergio Belotti, and Cyril Margaria
for their comments and discussions.
Thanks to Jonathan Hardwick for being the document shepherd and
providing comments and guidance.
Thanks to Tomonori Takeda for the Routing Area Directorate review.
Thanks to Adrian Farrel for the TSVART review and providing detailed
comments and suggestions.
Thanks to Daniel Franke for the SECDIR review.
Thanks to Alvaro Retana, Kathleen Moriarty, and Stephen Farrell for
comments during the IESG evaluation.
Thanks to Deborah Brungard for being the responsible AD and guiding
the authors as needed.
Contributors
Gang Xie
Huawei Technologies
F3-5-B R&D Center, Huawei Industrial Base, Bantian, Longgang District
Shenzhen, Guangdong, 518129
China
Email: xiegang09@huawei.com
<span class="grey">Crabbe, et al. Standards Track [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc8232">RFC 8232</a> Optimizations of State Synchronization September 2017</span>
Authors' Addresses
Edward Crabbe
Oracle
Email: edward.crabbe@gmail.com
Ina Minei
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States of America
Email: inaminei@google.com
Jan Medved
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
United States of America
Email: jmedved@cisco.com
Robert Varga
Pantheon Technologies SRO
Mlynske Nivy 56
Bratislava 821 05
Slovakia
Email: robert.varga@pantheon.tech
Xian Zhang
Huawei Technologies
F3-5-B R&D Center, Huawei Industrial Base, Bantian, Longgang District
Shenzhen, Guangdong 518129
China
Email: zhang.xian@huawei.com
Dhruv Dhody
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
Email: dhruv.ietf@gmail.com
Crabbe, et al. Standards Track [Page 26]
</pre>
|
