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
|
<pre>Internet Engineering Task Force (IETF) Y. Zhuang
Request for Comments: 8413 Q. Wu
Category: Informational H. Chen
ISSN: 2070-1721 Huawei
A. Farrel
Juniper Networks
July 2018
<span class="h1">Framework for Scheduled Use of Resources</span>
Abstract
Time-Scheduled (TS) reservation of Traffic Engineering (TE) resources
can be used to provide resource booking for TE Label Switched Paths
so as to better guarantee services for customers and to improve the
efficiency of network resource usage at any moment in time, including
network usage that is planned for the future. This document provides
a framework that describes and discusses the architecture for
supporting scheduled reservation of TE resources. This document does
not describe specific protocols or protocol extensions needed to
realize this service.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
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). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see <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/rfc8413">https://www.rfc-editor.org/info/rfc8413</a>.
<span class="grey">Zhuang, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc8413">RFC 8413</a> Scheduled Use of Resources July 2018</span>
Copyright Notice
Copyright (c) 2018 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.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Problem Statement . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.1">2.1</a>. Provisioning TE-LSPs and TE Resources . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.2">2.2</a>. Selecting the Path of an LSP . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.3">2.3</a>. Planning Future LSPs . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-2.4">2.4</a>. Looking at Future Demands on TE Resources . . . . . . . . <a href="#page-6">6</a>
2.4.1. Interaction between Time-Scheduled and Ad Hoc
Reservations . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-2.5">2.5</a>. Requisite State Information . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3">3</a>. Architectural Concepts . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-3.1">3.1</a>. Where is Scheduling State Held? . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-3.2">3.2</a>. What State is Held? . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-3.3">3.3</a>. Enforcement of Operator Policy . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-4">4</a>. Architecture Overview . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-4.1">4.1</a>. Service Request . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-4.1.1">4.1.1</a>. Reoptimization After TED Updates . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-4.2">4.2</a>. Initialization and Recovery . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-4.3">4.3</a>. Synchronization Between PCEs . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-5">5</a>. Multi-domain Considerations . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-6">6</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-7">7</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
<a href="#section-8">8</a>. Informative References . . . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-22">22</a>
<span class="grey">Zhuang, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc8413">RFC 8413</a> Scheduled Use of Resources July 2018</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Traffic Engineering Label Switched Paths (TE-LSPs) are connection-
oriented tunnels in packet and non-packet networks [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>]
[<a href="./rfc3945" title=""Generalized Multi-Protocol Label Switching (GMPLS) Architecture"">RFC3945</a>]. TE-LSPs may reserve network resources for use by the
traffic they carry, thus providing some guarantees of service
delivery and allowing a network operator to plan the use of the
resources across the whole network.
In some technologies (such as wavelength switched optical networks)
the resource is synonymous with the label that is switched on the
path of the LSP so that it is not possible to establish an LSP that
can carry traffic without assigning a physical resource to the LSP.
In other technologies (such as packet switched networks), the
resources assigned to an LSP are a measure of the capacity of a link
that is dedicated for use by the traffic on the LSP.
In all cases, network planning consists of selecting paths for LSPs
through the network so that there will be no contention for
resources. LSP establishment is the act of setting up an LSP and
reserving resources within the network. Network optimization or
reoptimization is the process of repositioning LSPs in the network to
make the unreserved network resources more useful for potential
future LSPs while ensuring that the established LSPs continue to
fulfill their objectives.
It is often the case that it is known that an LSP will be needed at
some specific time in the future. While a path for that LSP could be
computed using knowledge of the currently established LSPs and the
currently available resources, this does not give any degree of
certainty that the necessary resources will be available when it is
time to set up the new LSP. Yet, setting up the LSP ahead of the
time when it is needed (which would guarantee the availability of the
resources) is wasteful since the network resources could be used for
some other purpose in the meantime.
Similarly, it may be known that an LSP will no longer be needed after
some future time and that it will be torn down, which will release
the network resources that were assigned to it. This information can
be helpful in planning how a future LSP is placed in the network.
Time-Scheduled (TS) reservation of TE resources can be used to
provide resource booking for TE-LSPs so as to better guarantee
services for customers and to improve the efficiency of network
resource usage into the future. This document provides a framework
that describes the problem and discusses the architecture for the
<span class="grey">Zhuang, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc8413">RFC 8413</a> Scheduled Use of Resources July 2018</span>
scheduled reservation of TE resources. This document does not
describe specific protocols or protocol extensions needed to realize
this service.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Problem Statement</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Provisioning TE-LSPs and TE Resources</span>
TE-LSPs in existing networks are provisioned using a variety of
techniques. They may be set up using RSVP-TE as a signaling protocol
[<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>] [<a href="./rfc3473" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions"">RFC3473</a>]. Alternatively, they could be established by
direct control of network elements such as in the Software-Defined
Networking (SDN) paradigm. They could also be provisioned using the
PCE Communication Protocol (PCEP) [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>] as a control protocol to
communicate with the network elements.
TE resources are reserved at the point of use. That is, the
resources (wavelengths, timeslots, bandwidth, etc.) are reserved for
use on a specific link and are tracked by the Label Switching Routers
(LSRs) at the end points of the link. Those LSRs learn which
resources to reserve during the LSP setup process.
The use of TE resources can be varied by changing the parameters of
the LSP that uses them, and the resources can be released by tearing
down the LSP.
Resources that have been reserved in the network for use by one LSP
may be preempted for use by another LSP. If RSVP-TE signaling is in
use, a holding priority and a preemption priority are used to
determine which LSPs may preempt the resources that are in use for
which other LSPs. If direct (central) control is in use, the
controller is able to make preemption decisions. In either case,
operator policy forms a key part of preemption since there is a trade
between disrupting existing LSPs and enabling new LSPs.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Selecting the Path of an LSP</span>
Although TE-LSPs can determine their paths hop by hop using the
shortest path toward the destination to route the signaling protocol
messages [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>], in practice this option is not applied because it
does not look far enough ahead into the network to verify that the
desired resources are available. Instead, the full length of the
path of an LSP is usually computed ahead of time either by the head-
end LSR of a signaled LSP or by Path Computation Element (PCE)
functionality that is in a dedicated server or built into network
management software [<a href="./rfc4655" title=""A Path Computation Element (PCE)-Based Architecture"">RFC4655</a>].
<span class="grey">Zhuang, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc8413">RFC 8413</a> Scheduled Use of Resources July 2018</span>
Such full-path computation is applied in order that an end-to-end
view of the available resources in the network can be used to
determine the best likelihood of establishing a viable LSP that meets
the service requirements. Even in this situation, however, it is
possible that two LSPs being set up at the same time will compete for
scarce network resources, which means that one or both of them will
fail to be established. This situation is avoided by using a
centralized PCE that is aware of the LSP setup requests that are in
progress.
Path selection may make allowance for preemption as described in
<a href="#section-2.1">Section 2.1</a>. That is, when selecting a path, the decision may be
made to choose a path that will result in the preemption of an
existing LSP. The trade-off between selecting a less optimal path,
failing to select any path at all, and preempting an existing LSP
must be subject to operator policy.
Path computation is subject to "objective functions" that define what
criteria are to be met when the LSP is placed [<a href="./rfc4655" title=""A Path Computation Element (PCE)-Based Architecture"">RFC4655</a>]. These can
be criteria that apply to the LSP itself (such as the shortest path
to the destination) or to the network state after the LSP is set up
(such as the maximized residual link bandwidth). The objective
functions may be requested by the application requesting the LSP and
may be filtered and enhanced by the computation engine according to
operator policy.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Planning Future LSPs</span>
LSPs may be established "on demand" when the requester determines
that a new LSP is needed. In this case, the path of the LSP is
computed as described in <a href="#section-2.2">Section 2.2</a>.
However, in many situations, the requester knows in advance that an
LSP will be needed at a particular time in the future. For example,
the requester may be aware of a large traffic flow that will start at
a well-known time, perhaps for a database synchronization or for the
exchange of content between streaming sites. Furthermore, the
requester may also know for how long the LSP is required before it
can be torn down.
The set of requests for future LSPs could be collected and held in a
central database (such as at a Network Management System (NMS)): when
the time comes for each LSP to be set up, the NMS can ask the PCE to
compute a path and can then request the LSP to be provisioned. This
approach has a number of drawbacks because it is not possible to
determine in advance whether it will be possible to deliver the LSP
since the resources it needs might be used by other LSPs in the
<span class="grey">Zhuang, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc8413">RFC 8413</a> Scheduled Use of Resources July 2018</span>
network. Thus, at the time the requester asks for the future LSP,
the NMS can only make a best-effort guarantee that the LSP will be
set up at the desired time.
A better solution, therefore, is for the requests for future LSPs to
be serviced at once. The paths of the LSPs can be computed ahead of
time and converted into reservations of network resources during
specific windows in the future. That is, while the path of the LSP
is computed and the network resources are reserved, the LSP is not
established in the network until the time for which it is scheduled.
There is a need to take into account items that need to be subject to
operator policy, such as 1) the amount of capacity available for
scheduling future reservations, 2) the operator preference for the
measures that are used with respect to the use of scheduled resources
during rapid changes in traffic demand events, or 3) a complex
(multiple nodes/links) failure event so as to protect against network
destabilization. Operator policy is discussed further in
<a href="#section-3.3">Section 3.3</a>.
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. Looking at Future Demands on TE Resources</span>
While path computation, as described in <a href="#section-2.2">Section 2.2</a>, takes account of
the currently available network resources and can act to place LSPs
in the network so that there is the best possibility of future LSPs
being accommodated, it cannot handle all eventualities. It is simple
to construct scenarios where LSPs that are placed one at a time lead
to future LSPs being blocked, but where foreknowledge of all of the
LSPs would have made it possible for them all to be set up.
If, therefore, we were able to know in advance what LSPs were going
to be requested, we could plan for them and ensure resources were
available. Furthermore, such an approach enables a commitment to be
made to a service user that an LSP will be set up and available at a
specific time.
A reservation service can be achieved by tracking the current use of
network resources and also having a future view of the resource
usage. We call this Time-Scheduled TE (TS-TE) resource reservation.
<span class="h4"><a class="selflink" id="section-2.4.1" href="#section-2.4.1">2.4.1</a>. Interaction between Time-Scheduled and Ad Hoc Reservations</span>
There will, of course, be a mixture of resource uses in a network.
For example, normal unplanned LSPs may be requested alongside TS-TE
LSPs. When an unplanned LSP is requested, no prior accommodation can
be made to arrange resource availability, so the LSP can be placed no
better than would be the case without TS-TE. However, the new LSP
can be placed considering the future demands of TS-TE LSPs that have
<span class="grey">Zhuang, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc8413">RFC 8413</a> Scheduled Use of Resources July 2018</span>
already been requested. Of course, the unplanned LSP has no known
end time and so any network planning must assume that it will consume
resources forever.
<span class="h3"><a class="selflink" id="section-2.5" href="#section-2.5">2.5</a>. Requisite State Information</span>
In order to achieve the TS-TE resource reservation, the use of
resources on the path needs to be scheduled. The scheduling state is
used to indicate when resources are reserved and when they are
available for use.
A simple information model for one piece of the scheduling state is
as follows:
{
link id;
resource id or reserved capacity;
reservation start time;
reservation end time
}
The resource that is scheduled could be link capacity, physical
resources on a link, buffers on an interface, etc., and could include
advanced considerations such as CPU utilization and the availability
of memory at nodes within the network. The resource-related
information might also include the maximal unreserved bandwidth of
the link over a time interval. That is, the intention is to book
(reserve) a percentage of the residual (unreserved) bandwidth of the
link. This could be used, for example, to reserve bandwidth for a
particular class of traffic (such as IP) that doesn't have a
provisioned LSP.
For any one resource, there could be multiple pieces of the
scheduling state, and for any one link, the timing windows might
overlap.
There are multiple ways to realize this information model and
different ways to store the data. The resource state could be
expressed as a start time and an end time (as shown above), or it
could be expressed as a start time and a duration. Multiple
reservation periods, possibly of different lengths, may need to be
recorded for each resource. Furthermore, the current state of
network reservation could be kept separate from the scheduled usage,
or everything could be merged into a single TS database.
An application may make a reservation request for immediate resource
usage or to book resources for future use so as to maximize the
chance of services being delivered and to avoid contention for
<span class="grey">Zhuang, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc8413">RFC 8413</a> Scheduled Use of Resources July 2018</span>
resources in the future. A single reservation request may book
resources for multiple periods and might request a reservation that
repeats on a regular cycle.
A computation engine (that is, a PCE) may use the scheduling state
information to help optimize the use of resources into the future and
reduce contention or blocking when the resources are actually needed.
Note that it is also necessary to store the information about future
LSPs as distinct from the specific resource scheduling. This
information is held to allow the LSPs to be instantiated when they
are due, and use the paths/resources that have been computed for
them, and also to provide correlation with the TS-TE resource
reservations so that it is clear why resources were reserved, thus
allowing preemption and handling the release of reserved resources in
the event of cancellation of future LSPs. See <a href="#section-3.2">Section 3.2</a> for
further discussion of the distinction between scheduled resource
state and scheduled LSP state.
Network performance factors (such as maximum link utilization and the
residual capacity of the network), with respect to supporting
scheduled reservations, need to be supported and are subject to
operator policy.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Architectural Concepts</span>
This section examines several important architectural concepts to
understand the design decisions reached in this document to achieve
TS-TE in a scalable and robust manner.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Where is Scheduling State Held?</span>
The scheduling state information described in <a href="#section-2.5">Section 2.5</a> has to be
held somewhere. There are two places where this makes sense:
o in the network nodes where the resources exist; or,
o in a central scheduling controller where decisions about resource
allocation are made.
The first of these makes policing of resource allocation easier. It
means that many points in the network can request immediate or
scheduled LSPs with the associated resource reservation, and that all
such requests can be correlated at the point where the resources are
<span class="grey">Zhuang, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc8413">RFC 8413</a> Scheduled Use of Resources July 2018</span>
allocated. However, this approach has some scaling and technical
problems:
o The most obvious issue is that each network node must retain the
full time-based state for all of its resources. In a busy network
with a high arrival rate of new LSPs and a low hold time for each
LSP, this could be a lot of state. Network nodes are normally
implemented with minimal spare memory.
o In order that path computation can be performed, the computing
entity normally known as a Path Computation Element (PCE)
[<a href="./rfc4655" title=""A Path Computation Element (PCE)-Based Architecture"">RFC4655</a>] needs access to a database of available links and nodes
in the network (as well as the TE properties of said links). This
database is known as the Traffic Engineering Database (TED) and is
usually populated from information advertised in the IGP by each
of the network nodes or exported using BGP Link State (BGP-LS)
[<a href="./rfc7752" title=""North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP"">RFC7752</a>]. To be able to compute a path for a future LSP, the PCE
needs to populate the TED with all of the future resource
availability: if this information is held on the network nodes, it
must also be advertised in the IGP. This could be a significant
scaling issue for the IGP and the network nodes, as all of the
advertised information is held at every network node and must be
periodically refreshed by the IGP.
o When a normal node restarts, it can recover the resource
reservation state from the forwarding hardware, from Non-Volatile
Random-Access Memory (NVRAM), or from adjacent nodes through the
signaling protocol [<a href="./rfc5063" title=""Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart"">RFC5063</a>]. If the scheduling state is held at
the network nodes, it must also be recovered after the restart of
a network node. This cannot be achieved from the forwarding
hardware because the reservation will not have been made, could
require additional expensive NVRAM, or might require that all
adjacent nodes also have the scheduling state in order to
reinstall it on the restarting node. This is potentially complex
processing with scaling and cost implications.
Conversely, if the scheduling state is held centrally, it is easily
available at the point of use. That is, the PCE can utilize the
state to plan future LSPs and can update that stored information with
the scheduled reservation of resources for those future LSPs. This
approach also has several issues:
o If there are multiple controllers, then they must synchronize
their stored scheduling state as they each plan future LSPs and
they must have a mechanism to resolve resource contention. This
is relatively simple and is mitigated by the fact that there is
ample processing time to replan future LSPs in the case of
resource contention.
<span class="grey">Zhuang, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc8413">RFC 8413</a> Scheduled Use of Resources July 2018</span>
o If other sources of immediate LSPs are allowed (for example, other
controllers or autonomous action by head-end LSRs), then the
changes in resource availability caused by the setup or tear down
of these LSPs must be reflected in the TED (by use of the IGP as
is already normally done) and may have an impact on planned future
LSPs. This impact can be mitigated by replanning future LSPs or
through LSP preemption.
o If the scheduling state is held centrally at a PCE, the state must
be held and restored after a system restart. This is relatively
easy to achieve on a central server that can have access to non-
volatile storage. The PCE could also synchronize the scheduling
state with other PCEs after restart. See <a href="#section-4.2">Section 4.2</a> for details.
o Of course, a centralized system must store information about all
of the resources in the network. In a busy network with a high
arrival rate of new LSPs and a low hold time for each LSP, this
could be a lot of state. This is multiplied by the size of the
network measured both by the number of links and nodes and by the
number of trackable resources on each link or at each node. This
challenge may be mitigated by the centralized server being
dedicated hardware, but there remains the problem of collecting
the information from the network in a timely way when there is
potentially a very large amount of information to be collected and
when the rate of change of that information is high. This latter
challenge is only solved if the central server has full control of
the booking of resources and the establishment of new LSPs so that
the information from the network only serves to confirm what the
central server expected.
Thus, considering these trade-offs, the architectural conclusion is
that the scheduling state should be held centrally at the point of
use and not in the network devices.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. What State is Held?</span>
As already described, the PCE needs access to an enhanced, time-based
TED. It stores the Traffic Engineering (TE) information, such as
bandwidth, for every link for a series of time intervals. There are
a few ways to store the TE information in the TED. For example,
suppose that the amount of the unreserved bandwidth at a priority
level for a link is Bj in a time interval from time Tj to Tk (k =
j+1), where j = 0, 1, 2, ....
<span class="grey">Zhuang, et al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc8413">RFC 8413</a> Scheduled Use of Resources July 2018</span>
Bandwidth
^
| B3
| B1 ___________
| __________
|B0 B4
|__________ B2 _________
| ________________
|
-+-------------------------------------------------------> Time
|T0 T1 T2 T3 T4
Figure 1: A Plot of Bandwidth Usage against Time
The unreserved bandwidth for the link can be represented and stored
in the TED as [T0, B0], [T1, B1], [T2, B2], [T3, B3], ... as shown in
Figure 1.
But it must be noted that service requests for future LSPs are known
in terms of the LSPs whose paths are computed and for which resources
are scheduled. For example, if the requester of a future LSP decides
to cancel the request or to modify the request, the PCE must be able
to map this to the resources that were reserved. When the LSP (or
the request for the LSP with a number of time intervals) is canceled,
the PCE must release the resources that were reserved on each of the
links along the path of the LSP in every time interval from the TED.
If the bandwidth that had been reserved for the LSP on a link was B
from time T2 to T3 and the unreserved bandwidth on the link was B2
from T2 to T3, then B is added back to the link for the time interval
from T2 to T3 and the unreserved bandwidth on the link from T2 to T3
will be seen to be B2 + B.
This suggests that the PCE needs an LSP Database (LSP-DB) [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>]
that contains information not only about LSPs that are active in the
network but also those that are planned. For each time interval that
applies to the LSP, the information for an LSP stored in the LSP-DB
includes: the time interval, the paths computed for the LSP
satisfying the constraints in the time interval, and the resources
(such as bandwidth) reserved for the LSP in the time interval. See
also <a href="#section-2.3">Section 2.3</a>
It is an implementation choice how the TED and LSP-DB are stored both
for dynamic use and for recovery after failure or restart, but it may
be noted that all of the information in the scheduled TED can be
recovered from the active network state and from the scheduled LSP-
DB.
<span class="grey">Zhuang, et al. Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc8413">RFC 8413</a> Scheduled Use of Resources July 2018</span>
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Enforcement of Operator Policy</span>
Computation requests for LSPs are serviced according to operator
policy. For example, a PCE may refuse a computation request because
the application making the request does not have sufficient
permissions or because servicing the request might take specific
resource usage over a given threshold.
Furthermore, the preemption and holding priorities of any particular
computation request may be subject to the operator's policies. The
request could be rejected if it does not conform to the operator's
policies, or (possibly more likely) the priorities could be set/
overwritten according to the operator's policies.
Additionally, the Objective Functions (OFs) of computation request
(such as maximizing residual bandwidth) are also subject to operator
policies. It is highly likely that the choice of OFs is not
available to an application and is selected by the PCE or management
system subject to operator policies and knowledge of the application.
None of these statements is new to scheduled resources. They apply
to stateless, stateful, passive, and active PCEs, and they continue
to apply to scheduling of resources.
An operator may choose to configure special behavior for a PCE that
handles resource scheduling. For example, an operator might want
only a certain percentage of any resource to be bookable. And an
operator might want the preemption of booked resources to be an
inverse function of how far in the future the resources are needed
for the first time.
It is a general assumption about the architecture described in
<a href="#section-4">Section 4</a> that a PCE is under the operational control of the operator
that owns the resources that the PCE manipulates. Thus, the operator
may configure any amount of (potentially complex) policy at the PCE.
This configuration would also include policy points surrounding
reoptimization of existing and planned LSPs in the event of changes
in the current and future (planned) resource availability.
The granularity of the timing window offered to an application will
depend on an operator's policy as well as the implementation in the
PCE and goes to define the operator' service offerings. Different
granularities and different lengths of prebooking may be offered to
different applications.
<span class="grey">Zhuang, et al. Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc8413">RFC 8413</a> Scheduled Use of Resources July 2018</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Architecture Overview</span>
The architectural considerations and conclusions described in the
previous section lead to the architecture described in this section
and illustrated in Figure 2. The interfaces and interactions shown
in the figure and labeled (a) through (f) are described in
<a href="#section-4.1">Section 4.1</a>.
-------------------
| Service Requester |
-------------------
^
a|
v
------- b --------
| |<--->| LSP-DB |
| | --------
| PCE |
| | c -----
| |<---->| TED |
------- -----
^ ^
| |
d| |e
| |
------+-----+--------------------
| | Network
| --------
| | Router |
v --------
----- -----
| LSR |<------>| LSR |
----- f -----
Figure 2: Reference Architecture for Scheduled Use of Resources
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Service Request</span>
As shown in Figure 2, some component in the network requests a
service. This may be an application, an NMS, an LSR, or any
component that qualifies as a Path Computation Client (PCC). We show
this on the figure as the "Service Requester", and it sends a request
to the PCE for an LSP to be set up at some time (either now or in the
future). The request, indicated on Figure 2 by the arrow (a),
includes all of the parameters of the LSP that the requester wishes
to supply, such as priority, bandwidth, start time, and end time.
Note that the requester in this case may be the LSR shown in the
figure or may be a distinct system.
<span class="grey">Zhuang, et al. Informational [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc8413">RFC 8413</a> Scheduled Use of Resources July 2018</span>
The PCE enters the LSP request in its LSP-DB (b) and uses information
from its TED (c) to compute a path that satisfies the constraints
(such as bandwidth) for the LSP in the time interval from the start
time to the end time. It updates the future resource availability in
the TED so that further path computations can take account of the
scheduled resource usage. It stores the path for the LSP into the
LSP-DB (b).
When it is time (i.e., at the start time) for the LSP to be set up,
the PCE sends a PCEP Initiate request to the head-end LSR (d), which
provides the path to be signaled as well as other parameters, such as
the bandwidth of the LSP.
As the LSP is signaled between LSRs (f), the use of resources in the
network is updated and distributed using the IGP. This information
is shared with the PCE either through the IGP or using BGP-LS (e),
and the PCE updates the information stored in its TED (c).
After the LSP is set up, the head-end LSR sends a PCEP LSP State
Report (PCRpt) message to the PCE (d). The report contains the
resources, such as bandwidth usage, for the LSP. The PCE updates the
status of the LSP in the LSP-DB according to the report.
When an LSP is no longer required (either because the Service
Requester has canceled the request or because the LSP's scheduled
lifetime has expired), the PCE can remove it. If the LSP is
currently active, the PCE instructs the head-end LSR to tear it down
(d), and the network resource usage will be updated by the IGP and
advertised back to the PCE through the IGP or BGP-LS (e). Once the
LSP is no longer active, the PCE can remove it from the LSP-DB (b).
<span class="h4"><a class="selflink" id="section-4.1.1" href="#section-4.1.1">4.1.1</a>. Reoptimization After TED Updates</span>
When the TED is updated as indicated in <a href="#section-4.1">Section 4.1</a>, depending on
operator policy (so as to minimize network perturbations), the PCE
may perform reoptimization of the LSPs for which it has computed
paths. These LSPs may be already provisioned, in which case the PCE
issues PCEP Update request messages for the LSPs that should be
adjusted. Additionally, the LSPs being reoptimized may be scheduled
LSPs that have not yet been provisioned, in which case reoptimization
involves updating the store of scheduled LSPs and resources.
In all cases, the purpose of reoptimization is to take account of the
resource usage and availability in the network and to compute paths
for the current and future LSPs that best satisfy the objectives of
those LSPs while keeping the network as clear as possible to support
further LSPs. Since reoptimization may perturb established LSPs, it
<span class="grey">Zhuang, et al. Informational [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc8413">RFC 8413</a> Scheduled Use of Resources July 2018</span>
is subject to operator oversight and policy. As the stability of the
network will be impacted by frequent changes, the extent and impact
of any reoptimization needs to be subject to operator policy.
Additionally, the status of the reserved resources (alarms) can
enhance the computation and planning for future LSPs and may
influence repair and reoptimization. Control of recalculations based
on failures and notifications to the operator is also subject to
policy.
See <a href="#section-3.3">Section 3.3</a> for further discussion of operator policy.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Initialization and Recovery</span>
When a PCE in the architecture shown in Figure 2 is initialized, it
must learn the state from the network, from its stored databases, and
potentially from other PCEs in the network.
The first step is to get an accurate view of the topology and
resource availability in the network. This would normally involve
reading the state directly from the network via the IGP or BGP-LS
(e), but it might include receiving a copy of the TED from another
PCE. Note that a TED stored from a previous instantiation of the PCE
is unlikely to be valid.
Next, the PCE must construct a time-based TED to show scheduled
resource usage. How it does this is implementation specific, and
this document does not dictate any particular mechanism: it may
recover a time-based TED previously saved to non-volatile storage, or
it may reconstruct the time-based TED from information retrieved from
the LSP-DB previously saved to non-volatile storage. If there is
more than one PCE active in the network, the recovering PCE will need
to synchronize the LSP-DB and time-based TED with other PCEs (see
<a href="#section-4.3">Section 4.3</a>).
Note that the stored LSP-DB needs to include the intended state and
actual state of the LSPs so that when a PCE recovers, it is able to
determine what actions are necessary.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Synchronization Between PCEs</span>
If there is active in the network more than one PCE that supports
scheduling, it is important to achieve some consistency between the
scheduled TED and scheduled LSP-DB held by the PCEs.
[<a id="ref-RFC7399">RFC7399</a>] answers various questions around synchronization between
the PCEs. It should be noted that the time-based "scheduled"
information adds another dimension to the issue of synchronization
<span class="grey">Zhuang, et al. Informational [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc8413">RFC 8413</a> Scheduled Use of Resources July 2018</span>
between PCEs. It should also be noted that a deployment may use a
primary PCE and then have other PCEs as backup, where a backup PCE
can take over only in the event of a failure of the primary PCE.
Alternatively, the PCEs may share the load at all times. The choice
of the synchronization technique is largely dependent on the
deployment of PCEs in the network.
One option for ensuring that multiple PCEs use the same scheduled
information is simply to have the PCEs driven from the same shared
database, but it is likely to be inefficient, and interoperation
between multiple implementations will be harder.
Another option is for each PCE to be responsible for its own
scheduled database and to utilize some distributed database
synchronization mechanism to have consistent information. Depending
on the implementation, this could be efficient, but interoperation
between heterogeneous implementations is still hard.
A further approach is to utilize PCEP messages to synchronize the
scheduled state between PCEs. This approach would work well if the
number of PCEs that support scheduling is small, but as the number
increases, considerable message exchange needs to happen to keep the
scheduled databases synchronized. Future solutions could also
utilize some synchronization optimization techniques for efficiency.
Another variation would be to request information from other PCEs for
a particular time slice, but this might have an impact on the
optimization algorithm.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Multi-domain Considerations</span>
Multi-domain path computation usually requires some form of
cooperation between PCEs, each of which has responsibility for
determining a segment of the end-to-end path in the domain for which
it has computational responsibility. When computing a scheduled
path, resources need to be booked in all of the domains that the path
will cross so that they are available when the LSP is finally
signaled.
Per-domain path computation [<a href="./rfc5152" title=""A Per-Domain Path Computation Method for Establishing Inter- Domain Traffic Engineering (TE) Label Switched Paths (LSPs)"">RFC5152</a>] is not an appropriate mechanism
when a scheduled LSP is being computed because the computation
requests at downstream PCEs are only triggered by signaling.
However, a similar mechanism could be used where cooperating PCEs
exchange Path Computation Request (PCReq) messages for a scheduled
LSP, as shown in Figure 3. In this case, the service requester asks
for a scheduled LSP that will span two domains (a). PCE1 computes a
path across Domain 1 and reserves the resources and also asks PCE2 to
compute and reserve in Domain 2 (b). PCE2 may return a full path or
could return a path key [<a href="./rfc5520" title=""Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism"">RFC5520</a>]. When it is time for LSP setup,
<span class="grey">Zhuang, et al. Informational [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc8413">RFC 8413</a> Scheduled Use of Resources July 2018</span>
PCE1 triggers the head-end LSR (c), and the LSP is signaled (d). If
a path key is used, the entry LSR in Domain 2 will consult PCE2 for
the path expansion (e) before completing signaling (f).
-------------------
| Service Requester |
-------------------
^
a|
v
------ b ------
| |<---------------->| |
| PCE1 | | PCE2 |
| | | |
------ ------
^ ^
| |
c| e|
| |
----+----------------- ----+-----------------
| | Domain 1 | | | Domain 2 |
| v | | v |
| ----- d ----- | | ----- f ----- |
| | LSR |<--->| LSR |<-+--+->| LSR |<--->| LSR | |
| ----- ----- | | ----- ----- |
---------------------- ----------------------
Figure 3: Per-Domain Path Computation for Scheduled LSPs
Another mechanism for PCE cooperation in multi-domain LSP setup is
Backward Recursive PCE-Based Computation (BRPC) [<a href="./rfc5441" title=""A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths"">RFC5441</a>]. This
approach relies on the downstream domain to supply a variety of
potential paths to the upstream domain. Although BRPC can arrive at
a more optimal end-to-end path than per-domain path computation, it
is not well suited to LSP scheduling because the downstream PCE would
need to reserve resources on all of the potential paths and then
release those that the upstream PCE announced it did not plan to use.
Finally, we should consider hierarchical PCE (H-PCE) [<a href="./rfc6805" title=""The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS"">RFC6805</a>]. This
mode of operation is similar to that shown in Figure 3, but a parent
PCE is used to coordinate the requests to the child PCEs, which then
results in better visibility of the end-to-end path and better
coordination of the resource booking. The sequenced flow of control
is shown in Figure 4.
<span class="grey">Zhuang, et al. Informational [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc8413">RFC 8413</a> Scheduled Use of Resources July 2018</span>
-------------------
| Service Requester |
-------------------
^
a|
v
--------
| |
| Parent |
| PCE |
| |
--------
^ ^ b
b| |_______________________
| |
v v
------ ------
| | | |
| PCE1 | | PCE2 |
| | | |
------ ------
^ ^
| |
c| e|
| |
----+----------------- ----+-----------------
| | Domain 1 | | | Domain 2 |
| v | | v |
| ----- d ----- | | ----- f ----- |
| | LSR |<--->| LSR |<-+--+->| LSR |<--->| LSR | |
| ----- ----- | | ----- ----- |
---------------------- ----------------------
Figure 4: Hierarchical PCE for Path Computation for Scheduled LSPs
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
The protocol implications of scheduled resources are unchanged from
"on demand" LSP computation and setup. A discussion of securing PCEP
is found in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>], and work to extend that security is provided
in [<a href="./rfc8253" title=""PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)"">RFC8253</a>]. Furthermore, the path key mechanism described in
[<a href="./rfc5520" title=""Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism"">RFC5520</a>] can be used to enhance privacy and security.
Similarly, there is no change to the security implications for the
signaling of scheduled LSPs. A discussion of the security of the
signaling protocols that would be used is found in [<a href="./rfc5920" title=""Security Framework for MPLS and GMPLS Networks"">RFC5920</a>].
<span class="grey">Zhuang, et al. Informational [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc8413">RFC 8413</a> Scheduled Use of Resources July 2018</span>
However, the use of scheduled LSPs extends the attack surface for a
PCE-enabled TE system by providing a larger (logically infinite)
window during which an attack can be initiated or planned. That is,
if bogus scheduled LSPs can be requested and entered into the LSP-DB,
then a large number of LSPs could be launched and significant network
resources could be blocked. Control of scheduling requests needs to
be subject to operator policy, and additional authorization needs to
be applied for access to LSP scheduling. Diagnostic tools need to be
provided to inspect the LSP-DB to spot attacks.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
This document has no IANA actions.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Informative References</span>
[<a id="ref-AUTOBW">AUTOBW</a>] Yong, L. and Y. Lee, "ASON/GMPLS Extension for Reservation
and Time Based Automatic Bandwidth Service", Work in
Progress, <a href="./draft-yong-ccamp-ason-gmpls-autobw-service-00">draft-yong-ccamp-ason-gmpls-autobw-service-00</a>,
October 2006.
[<a id="ref-DRAGON">DRAGON</a>] National Science Foundation, "The DRAGON Project: Dynamic
Resource Allocation via GMPLS Optical Networks", Overview
and Status Presentation at ONT3, September 2006,
<<a href="http://www.maxgigapop.net/wp-content/uploads/The-DRAGON-Project.pdf">http://www.maxgigapop.net/wp-content/uploads/</a>
<a href="http://www.maxgigapop.net/wp-content/uploads/The-DRAGON-Project.pdf">The-DRAGON-Project.pdf</a>>.
[<a id="ref-FRAMEWORK-TTS">FRAMEWORK-TTS</a>]
Chen, H., Toy, M., Liu, L., and K. Pithewan, "Framework
for Temporal Tunnel Services", Work In Progress, <a href="./draft-chen-teas-frmwk-tts-01">draft-</a>
<a href="./draft-chen-teas-frmwk-tts-01">chen-teas-frmwk-tts-01</a>, March 2016.
[<a id="ref-RFC3209">RFC3209</a>] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", <a href="./rfc3209">RFC 3209</a>, DOI 10.17487/RFC3209, December 2001,
<<a href="https://www.rfc-editor.org/info/rfc3209">https://www.rfc-editor.org/info/rfc3209</a>>.
[<a id="ref-RFC3473">RFC3473</a>] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", <a href="./rfc3473">RFC 3473</a>,
DOI 10.17487/RFC3473, January 2003,
<<a href="https://www.rfc-editor.org/info/rfc3473">https://www.rfc-editor.org/info/rfc3473</a>>.
[<a id="ref-RFC3945">RFC3945</a>] Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", <a href="./rfc3945">RFC 3945</a>,
DOI 10.17487/RFC3945, October 2004,
<<a href="https://www.rfc-editor.org/info/rfc3945">https://www.rfc-editor.org/info/rfc3945</a>>.
<span class="grey">Zhuang, et al. Informational [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc8413">RFC 8413</a> Scheduled Use of Resources July 2018</span>
[<a id="ref-RFC4655">RFC4655</a>] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", <a href="./rfc4655">RFC 4655</a>,
DOI 10.17487/RFC4655, August 2006,
<<a href="https://www.rfc-editor.org/info/rfc4655">https://www.rfc-editor.org/info/rfc4655</a>>.
[<a id="ref-RFC5063">RFC5063</a>] Satyanarayana, A., Ed. and R. Rahman, Ed., "Extensions to
GMPLS Resource Reservation Protocol (RSVP) Graceful
Restart", <a href="./rfc5063">RFC 5063</a>, DOI 10.17487/RFC5063, October 2007,
<<a href="https://www.rfc-editor.org/info/rfc5063">https://www.rfc-editor.org/info/rfc5063</a>>.
[<a id="ref-RFC5152">RFC5152</a>] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A
Per-Domain Path Computation Method for Establishing Inter-
Domain Traffic Engineering (TE) Label Switched Paths
(LSPs)", <a href="./rfc5152">RFC 5152</a>, DOI 10.17487/RFC5152, February 2008,
<<a href="https://www.rfc-editor.org/info/rfc5152">https://www.rfc-editor.org/info/rfc5152</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-RFC5441">RFC5441</a>] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
"A Backward-Recursive PCE-Based Computation (BRPC)
Procedure to Compute Shortest Constrained Inter-Domain
Traffic Engineering Label Switched Paths", <a href="./rfc5441">RFC 5441</a>,
DOI 10.17487/RFC5441, April 2009,
<<a href="https://www.rfc-editor.org/info/rfc5441">https://www.rfc-editor.org/info/rfc5441</a>>.
[<a id="ref-RFC5520">RFC5520</a>] Bradford, R., Ed., Vasseur, JP., and A. Farrel,
"Preserving Topology Confidentiality in Inter-Domain Path
Computation Using a Path-Key-Based Mechanism", <a href="./rfc5520">RFC 5520</a>,
DOI 10.17487/RFC5520, April 2009,
<<a href="https://www.rfc-editor.org/info/rfc5520">https://www.rfc-editor.org/info/rfc5520</a>>.
[<a id="ref-RFC5920">RFC5920</a>] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", <a href="./rfc5920">RFC 5920</a>, DOI 10.17487/RFC5920, July 2010,
<<a href="https://www.rfc-editor.org/info/rfc5920">https://www.rfc-editor.org/info/rfc5920</a>>.
[<a id="ref-RFC6805">RFC6805</a>] King, D., Ed. and A. Farrel, Ed., "The Application of the
Path Computation Element Architecture to the Determination
of a Sequence of Domains in MPLS and GMPLS", <a href="./rfc6805">RFC 6805</a>,
DOI 10.17487/RFC6805, November 2012,
<<a href="https://www.rfc-editor.org/info/rfc6805">https://www.rfc-editor.org/info/rfc6805</a>>.
[<a id="ref-RFC7399">RFC7399</a>] Farrel, A. and D. King, "Unanswered Questions in the Path
Computation Element Architecture", <a href="./rfc7399">RFC 7399</a>,
DOI 10.17487/RFC7399, October 2014,
<<a href="https://www.rfc-editor.org/info/rfc7399">https://www.rfc-editor.org/info/rfc7399</a>>.
<span class="grey">Zhuang, et al. Informational [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc8413">RFC 8413</a> Scheduled Use of Resources July 2018</span>
[<a id="ref-RFC7752">RFC7752</a>] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", <a href="./rfc7752">RFC 7752</a>,
DOI 10.17487/RFC7752, March 2016,
<<a href="https://www.rfc-editor.org/info/rfc7752">https://www.rfc-editor.org/info/rfc7752</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="https://www.rfc-editor.org/info/rfc8231">https://www.rfc-editor.org/info/rfc8231</a>>.
[<a id="ref-RFC8253">RFC8253</a>] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for the
Path Computation Element Communication Protocol (PCEP)",
<a href="./rfc8253">RFC 8253</a>, DOI 10.17487/RFC8253, October 2017,
<<a href="https://www.rfc-editor.org/info/rfc8253">https://www.rfc-editor.org/info/rfc8253</a>>.
Acknowledgements
This work has benefited from the discussions of resource scheduling
over the years. In particular, the DRAGON project [<a href="#ref-DRAGON" title=""The DRAGON Project: Dynamic Resource Allocation via GMPLS Optical Networks"">DRAGON</a>] and
[<a href="#ref-AUTOBW" title=""ASON/GMPLS Extension for Reservation and Time Based Automatic Bandwidth Service"">AUTOBW</a>], both of which provide approaches to auto-bandwidth services
in GMPLS networks.
Mehmet Toy, Lei Liu, and Khuzema Pithewan contributed to an earlier
version of [<a href="#ref-FRAMEWORK-TTS">FRAMEWORK-TTS</a>]. We would like to thank the authors of
that document on Temporal Tunnel Services for material that assisted
in thinking about this document.
Thanks to Michael Scharf and Daniele Ceccarelli for useful comments
on this work.
Jonathan Hardwick provided a helpful Routing Directorate review.
Deborah Brungard, Mirja Kuehlewind, and Benjamin Kaduk suggested many
changes during their Area Director reviews.
Contributors
The following person contributed to discussions that led to the
development of this document:
Dhruv Dhody
Email: dhruv.dhody@huawei.com
<span class="grey">Zhuang, et al. Informational [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc8413">RFC 8413</a> Scheduled Use of Resources July 2018</span>
Authors' Addresses
Yan Zhuang
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: zhuangyan.zhuang@huawei.com
Qin Wu
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: bill.wu@huawei.com
Huaimo Chen
Huawei
Boston, MA
United States of America
Email: huaimo.chen@huawei.com
Adrian Farrel
Juniper Networks
Email: afarrel@juniper.net
Zhuang, et al. Informational [Page 22]
</pre>
|
