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) D. Dhody
Request for Comments: 8637 Huawei Technologies
Category: Informational Y. Lee
ISSN: 2070-1721 Futurewei Technologies
D. Ceccarelli
Ericsson
July 2019
<span class="h1">Applicability of the Path Computation Element (PCE)</span>
<span class="h1">to the Abstraction and Control of TE Networks (ACTN)</span>
Abstract
Abstraction and Control of TE Networks (ACTN) refers to the set of
virtual network (VN) operations needed to orchestrate, control, and
manage large-scale multidomain TE networks so as to facilitate
network programmability, automation, efficient resource sharing, and
end-to-end virtual service-aware connectivity and network function
virtualization services.
The Path Computation Element (PCE) is a component, application, or
network node that is capable of computing a network path or route
based on a network graph and applying computational constraints. The
PCE serves requests from Path Computation Clients (PCCs) that
communicate with it over a local API or using the Path Computation
Element Communication Protocol (PCEP).
This document examines the applicability of PCE to the ACTN
framework.
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/rfc8637">https://www.rfc-editor.org/info/rfc8637</a>.
<span class="grey">Dhody, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc8637">RFC 8637</a> PCE-ACTN July 2019</span>
Copyright Notice
Copyright (c) 2019 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-2">2</a>
<a href="#section-2">2</a>. Background Information . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.1">2.1</a>. Path Computation Element (PCE) . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.1.1">2.1.1</a>. Role of PCE in SDN . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.1.2">2.1.2</a>. PCE in Multidomain and Multilayer Deployments . . . . <a href="#page-4">4</a>
<a href="#section-2.1.3">2.1.3</a>. Relationship to PCE-Based Central Control . . . . . . <a href="#page-5">5</a>
<a href="#section-2.2">2.2</a>. Abstraction and Control of TE Networks (ACTN) . . . . . . <a href="#page-5">5</a>
<a href="#section-3">3</a>. Architectural Considerations . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.1">3.1</a>. Multidomain Coordination via Hierarchy . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.2">3.2</a>. Abstraction . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-3.3">3.3</a>. Customer Mapping . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-3.4">3.4</a>. Virtual Service Coordination . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-4">4</a>. Interface Considerations . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-5">5</a>. Realizing ACTN with PCE (and PCEP) . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-6">6</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-7">7</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-8">8</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-8.1">8.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-8.2">8.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#appendix-A">Appendix A</a>. Additional Information . . . . . . . . . . . . . . . <a href="#page-21">21</a>
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-22">22</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Abstraction and Control of TE Networks (ACTN) [<a href="./rfc8453" title=""Framework for Abstraction and Control of TE Networks (ACTN)"">RFC8453</a>] refers to the
set of virtual network (VN) operations needed to orchestrate,
control, and manage large-scale multidomain TE networks so as to
facilitate network programmability, automation, efficient resource
sharing, and end-to-end virtual service-aware connectivity and
network function virtualization services.
<span class="grey">Dhody, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc8637">RFC 8637</a> PCE-ACTN July 2019</span>
The Path Computation Element (PCE) [<a href="./rfc4655" title=""A Path Computation Element (PCE)-Based Architecture"">RFC4655</a>] is a component,
application, or network node that is capable of computing a network
path or route based on a network graph and applying computational
constraints. The PCE serves requests from Path Computation Clients
(PCCs) that communicate with it over a local API or using the Path
Computation Element Communication Protocol (PCEP).
This document examines the PCE and ACTN architecture and describes
how PCE architecture is applicable to ACTN. It also lists the PCEP
extensions that are needed to use PCEP as an ACTN interface. This
document also identifies any gaps in PCEP that exist at the time of
publication of this document.
Further, ACTN, stateful Hierarchical PCE (H-PCE) [<a href="#ref-PCE-HPCE">PCE-HPCE</a>], and PCE
as a central controller (PCECC) [<a href="./rfc8283" title=""An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control"">RFC8283</a>] are based on the same basic
hierarchy framework and are thus compatible with each other.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Background Information</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Path Computation Element (PCE)</span>
The Path Computation Element Communication Protocol (PCEP) [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>]
provides mechanisms for Path Computation Clients (PCCs) to request a
Path Computation Element (PCE) [<a href="./rfc4655" title=""A Path Computation Element (PCE)-Based Architecture"">RFC4655</a>] to perform path
computations.
The ability to compute shortest constrained TE LSPs in Multiprotocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across
multiple domains has been identified as a key motivation for PCE
development.
A stateful PCE [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>] is capable of considering, for the purposes
of path computation, not only the network state in terms of links and
nodes (referred to as the Traffic Engineering Database or TED), but
also the status of active services (previously computed paths), and
currently reserved resources, stored in the Label Switched Paths
Database (LSP-DB).
[<a id="ref-RFC8051">RFC8051</a>] describes general considerations for a stateful PCE
deployment and examines its applicability and benefits as well as its
challenges and limitations through a number of use cases.
[<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
<span class="grey">Dhody, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc8637">RFC 8637</a> PCE-ACTN July 2019</span>
constrained paths while considering individual LSPs and their
interactions. [<a href="./rfc8281" title=""Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model"">RFC8281</a>] describes the setup, maintenance, and
teardown of PCE-initiated LSPs under the stateful PCE model.
[<a id="ref-RFC8231">RFC8231</a>] also describes the active stateful PCE. The active PCE
functionality allows a PCE to reroute an existing LSP or make changes
to the attributes of an existing LSP, or a PCC to delegate control of
specific LSPs to a new PCE.
<span class="h4"><a class="selflink" id="section-2.1.1" href="#section-2.1.1">2.1.1</a>. Role of PCE in SDN</span>
Software-Defined Networking (SDN) [<a href="./rfc7149" title=""Software-Defined Networking: A Perspective from within a Service Provider Environment"">RFC7149</a>] refers to a separation
between the control elements and the forwarding components so that
software running in a centralized system, called a controller, can
act to program the devices in the network to behave in specific ways.
A required element in an SDN architecture is a component that plans
how the network resources will be used and how the devices will be
programmed. It is possible to view this component as performing
specific computations to place flows within the network given
knowledge of the availability of network resources, how other
forwarding devices are programmed, and the way that other flows are
routed. It is concluded in [<a href="./rfc7399" title=""Unanswered Questions in the Path Computation Element Architecture"">RFC7399</a>] that this is the same function
that a PCE might offer in a network operated using a dynamic control
plane. This is the function and purpose of a PCE, and the way that a
PCE integrates into a wider network control system including SDN is
presented in Application-Based Network Operation (ABNO) [<a href="./rfc7491" title=""A PCE-Based Architecture for Application-Based Network Operations"">RFC7491</a>].
<span class="h4"><a class="selflink" id="section-2.1.2" href="#section-2.1.2">2.1.2</a>. PCE in Multidomain and Multilayer Deployments</span>
Computing paths across large multidomain environments requires
special computational components and cooperation between entities in
different domains capable of complex path computation. The PCE
provides an architecture and a set of functional components to
address this problem space. A PCE may be used to compute end-to-end
paths across multidomain environments using a per-domain path
computation technique [<a href="./rfc5152" title=""A Per-Domain Path Computation Method for Establishing Inter- Domain Traffic Engineering (TE) Label Switched Paths (LSPs)"">RFC5152</a>]. The Backward-Recursive PCE-based
path computation (BRPC) mechanism [<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>] defines a PCE-based path
computation procedure to compute interdomain-constrained MPLS and
GMPLS TE networks. However, per-domain technique assumes that the
sequence of domains to be crossed from source to destination is
known, either fixed by the network operator or obtained by other
means. BRPC can work best with a known domain sequence, and it will
also work nicely with a small set of interconnected domains.
However, it doesn't work well for a large set of interconnected
domains.
<span class="grey">Dhody, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc8637">RFC 8637</a> PCE-ACTN July 2019</span>
[<a id="ref-RFC6805">RFC6805</a>] describes a Hierarchical PCE (H-PCE) architecture that can
be used for computing end-to-end paths for interdomain MPLS Traffic
Engineering (TE) and GMPLS Label Switched Paths (LSPs) when the
domain sequence is not known. Within the Hierarchical PCE (H-PCE)
architecture, the Parent PCE (P-PCE) is used to compute a multidomain
path based on the domain connectivity information. A Child PCE
(C-PCE) may be responsible for a single domain or multiple domains;
it is used to compute the intradomain path based on its domain
topology information.
[<a id="ref-PCE-HPCE">PCE-HPCE</a>] states the considerations for stateful PCEs in
Hierarchical PCE architecture. In particular, the behavior changes
and adds to the existing stateful PCE mechanisms (including PCE-
initiated LSP setup and active PCE usage) in the context of networks
using the H-PCE architecture.
[<a id="ref-RFC5623">RFC5623</a>] describes a framework for applying the PCE-based
architecture to interlayer (G)MPLS TE. It provides suggestions for
the deployment of PCE in support of multilayer networks. It also
describes the relationship between PCE and a functional component in
charge of the control and management of the Virtual Network Topology
(VNT) [<a href="./rfc5212" title=""Requirements for GMPLS-Based Multi- Region and Multi-Layer Networks (MRN/MLN)"">RFC5212</a>] called the VNT Manager (VNTM).
<span class="h4"><a class="selflink" id="section-2.1.3" href="#section-2.1.3">2.1.3</a>. Relationship to PCE-Based Central Control</span>
[<a id="ref-RFC8283">RFC8283</a>] introduces the architecture for PCE as a central controller
(PCECC); it further examines the motivations and applicability for
PCEP as a southbound interface (SBI) and introduces the implications
for the protocol. <a href="./rfc8283#section-2.1.3">Section 2.1.3 of [RFC8283]</a> describes a hierarchy
of PCE-based controllers as per the PCE Hierarchy Framework defined
in [<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>].
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Abstraction and Control of TE Networks (ACTN)</span>
[<a id="ref-RFC8453">RFC8453</a>] describes the high-level ACTN requirements and the
architecture model for ACTN, including the entities Customer Network
Controller (CNC), Multidomain Service Coordinator (MDSC), and
Provisioning Network Controller (PNC) and their interfaces.
The ACTN reference architecture is shown in Figure 1, which is
reproduced here from [<a href="./rfc8453" title=""Framework for Abstraction and Control of TE Networks (ACTN)"">RFC8453</a>] for convenience. [<a href="./rfc8453" title=""Framework for Abstraction and Control of TE Networks (ACTN)"">RFC8453</a>] remains
the definitive reference for the ACTN architecture. As depicted in
Figure 1, the ACTN architecture identifies a three-tier hierarchy.
<span class="grey">Dhody, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc8637">RFC 8637</a> PCE-ACTN July 2019</span>
+---------+ +---------+ +---------+
| CNC | | CNC | | CNC |
+---------+ +---------+ +---------+
\ | /
\ | /
Boundary =============\==============|==============/============
Between \ | /
Customer & ------- | CMI -------
Network Operator \ | /
+---------------+
| MDSC |
+---------------+
/ | \
------------ | MPI -------------
/ | \
+-------+ +-------+ +-------+
| PNC | | PNC | | PNC |
+-------+ +-------+ +-------+
| SBI / | / \
| / | SBI / \
--------- ----- | / \
( ) ( ) | / \
- Control - ( Phys. ) | / -----
( Plane ) ( Net ) | / ( )
( Physical ) ----- | / ( Phys. )
( Network ) ----- ----- ( Net )
- - ( ) ( ) -----
( ) ( Phys. ) ( Phys. )
--------- ( Net ) ( Net )
----- -----
CMI - (CNC-MDSC Interface)
MPI - (MDSC-PNC Interface)
SBI - (Southbound Interface)
Figure 1: ACTN Hierarchy
There are two interfaces with respect to the MDSC: one north of the
MDSC (the CNC-MDSC Interface (CMI)), and one south (the MDSC-PNC
Interface (MPI)). A hierarchy of MDSCs is possible with a recursive
MPI interface.
[<a id="ref-RFC8454">RFC8454</a>] provides an information model for ACTN interfaces.
<span class="grey">Dhody, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc8637">RFC 8637</a> PCE-ACTN July 2019</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Architectural Considerations</span>
The ACTN architecture [<a href="./rfc8453" title=""Framework for Abstraction and Control of TE Networks (ACTN)"">RFC8453</a>] is based on the hierarchy and
recursiveness of controllers. It defines three types of controllers
(depending on the functionalities they implement). The main
functionalities are:
o Multidomain coordination
o Abstraction
o Customer mapping/translation
o Virtual service coordination
<a href="./rfc8453#section-3">Section 3 of [RFC8453]</a> describes these functions.
It should be noted that this document lists all possible ways in
which PCE could be used for each of the above functions, but all
functions are not required to be implemented via PCE. Similarly,
this document presents the ways in which PCEP could be used as the
communications medium between functional components. Operators may
choose to use the PCEP for multidomain coordination via stateful
H-PCE but alternatively use Network Configuration Protocol (NETCONF)
[<a href="./rfc6241" title=""Network Configuration Protocol (NETCONF)"">RFC6241</a>], RESTCONF [<a href="./rfc8040" title=""RESTCONF Protocol"">RFC8040</a>], or 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 get access to the topology and support abstraction function.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Multidomain Coordination via Hierarchy</span>
With the definition of domain being everything that is under the
control of the single logical controller, as per [<a href="./rfc8453" title=""Framework for Abstraction and Control of TE Networks (ACTN)"">RFC8453</a>], it is
needed both to have a control entity that oversees the specific
aspects of the different domains and to build a single abstracted
end-to-end network topology in order to coordinate end-to-end path
computation and path/service provisioning.
The MDSC in ACTN framework realizes this function by coordinating the
per-domain PNCs in a hierarchy of controllers. It also needs to
detach from the underlying network technology and express customer
concerns by business needs.
[<a id="ref-RFC6805">RFC6805</a>] and [<a href="#ref-PCE-HPCE">PCE-HPCE</a>] describe a hierarchy of PCEs with the Parent
PCE coordinating multidomain path computation function between Child
PCEs. It is easy to see how these principles align, and thus how the
stateful H-PCE architecture can be used to realize ACTN.
<span class="grey">Dhody, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc8637">RFC 8637</a> PCE-ACTN July 2019</span>
The per-domain stitched LSP in the Hierarchical stateful PCE
architecture, described in Section 3.3.1 of [<a href="#ref-PCE-HPCE">PCE-HPCE</a>], is well
suited for multidomain coordination function. This includes domain
sequence selection, End-to-End (E2E) path computation, and
controller-initiated (PCE-initiated) path setup and reporting. This
is also applicable to multilayer coordination in case of IP+optical
networks.
[<a id="ref-PCE-STATE-SYNC">PCE-STATE-SYNC</a>] describes the procedures to allow a stateful
communication between PCEs for various use cases. The procedures and
extensions are also applicable to Child and Parent PCE communication
and are thus useful for ACTN as well.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Abstraction</span>
To realize ACTN, an abstracted view of the underlying network
resources needs to be built. This includes global network-wide
abstracted topology based on the underlying network resources of each
domain. This also includes abstract topology created as per the
customer service connectivity requests and represented as a VN slice
allocated to each customer.
In order to compute and provide optimal paths, PCEs require an
accurate and timely Traffic Engineering Database (TED).
Traditionally, this TED has been obtained from a link-state (LS)
routing protocol supporting traffic engineering extensions. PCE may
construct its TED by participating in the IGP ([<a href="./rfc3630" title=""Traffic Engineering (TE) Extensions to OSPF Version 2"">RFC3630</a>] and
[<a href="./rfc5305" title=""IS-IS Extensions for Traffic Engineering"">RFC5305</a>] for MPLS-TE; [<a href="./rfc4203" title=""OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)"">RFC4203</a>] and [<a href="./rfc5307" title=""IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)"">RFC5307</a>] for GMPLS). An
alternative is offered by BGP-LS [<a href="./rfc7752" title=""North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP"">RFC7752</a>].
In case of 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>], the Parent PCE needs to build the domain
topology map of the child domains and their interconnectivity.
[<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>] and [<a href="#ref-PCE-INTER-AREA">PCE-INTER-AREA</a>] suggest that BGP-LS could be used as a
"northbound" TE advertisement from the Child PCE to the Parent PCE.
[<a id="ref-PCEP-LS">PCEP-LS</a>] proposes another approach for learning and maintaining the
Link-State and TE information as an alternative to IGPs and BGP
flooding, using PCEP itself. The Child PCE can use this mechanism to
transport Link-State and TE information from Child PCE to a Parent
PCE using PCEP.
In ACTN, there is a need to control the level of abstraction based on
the deployment scenario and business relationship between the
controllers. The mechanism used to disseminate information from the
PNC (Child PCE) to the MDSC (Parent PCE) should support abstraction.
[<a href="./rfc8453" title=""Framework for Abstraction and Control of TE Networks (ACTN)"">RFC8453</a>] describes a few alternative approaches of abstraction. The
resulting abstracted topology can be encoded using the PCEP-LS
mechanisms [<a href="#ref-PCEP-LS" title=""PCEP Extension for Distribution of Link-State and TE Information."">PCEP-LS</a>] and its optical network extension
<span class="grey">Dhody, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc8637">RFC 8637</a> PCE-ACTN July 2019</span>
[<a href="#ref-PCEP-OPTICAL">PCEP-OPTICAL</a>]. PCEP-LS is an attractive option when the operator
would wish to have a single control-plane protocol (PCEP) to achieve
ACTN functions.
[<a id="ref-RFC8453">RFC8453</a>] discusses two ways to build abstract topology from an MDSC
standpoint with interaction with PNCs. The primary method is called
automatic generation of abstract topology by configuration. With
this method, automatic generation is based on the abstraction/
summarization of the whole domain by the PNC and its advertisement on
the MPI. The secondary method is called on-demand generation of
supplementary topology via Path Compute Request/Reply. This method
may be needed to obtain further complementary information such as
potential connectivity from Child PCEs in order to facilitate an end-
to-end path provisioning. PCEP is well suited to support both
methods.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Customer Mapping</span>
In ACTN, there is a need to map customer virtual network (VN)
requirements into a network provisioning request to the PNC. That
is, the customer requests/commands are mapped by the MDSC into
network provisioning requests that can be sent to the PNC.
Specifically, the MDSC provides mapping and translation of a
customer's service request into a set of parameters that are specific
to a network type and technology such that the network configuration
process is made possible.
[<a id="ref-RFC8281">RFC8281</a>] describes the setup, maintenance, and teardown of PCE-
initiated LSPs under the stateful PCE model, without the need for
local configuration on the PCC, thus allowing for a dynamic network
that is centrally controlled and deployed. To instantiate or delete
an LSP, the PCE sends the Path Computation LSP Initiate Request
(PCInitiate) message to the PCC. As described in [<a href="#ref-PCE-HPCE">PCE-HPCE</a>], for
interdomain LSP in Hierarchical PCE architecture, the initiation
operations can be carried out at the Parent PCE. In this case, after
Parent PCE finishes the E2E path computation, it can send the
PCInitiate message to the Child PCE; the Child PCE further propagates
the initiate request to the Label Switching Router (LSR). The
customer request is received by the MDSC (Parent PCE), and, based on
the business logic, global abstracted topology, network conditions,
and local policy, the MDSC (Parent PCE) translates this into a per-
domain LSP initiation request that a PNC (Child PCE) can understand
and act on. This can be done via the PCInitiate message.
PCEP extensions for associating opaque policy between PCEP peer
[<a href="#ref-ASSOC-POLICY">ASSOC-POLICY</a>] can be used.
<span class="grey">Dhody, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc8637">RFC 8637</a> PCE-ACTN July 2019</span>
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Virtual Service Coordination</span>
Virtual service coordination function in ACTN incorporates customer
service-related information into the virtual network service
operations in order to seamlessly operate virtual networks while
meeting customers' service requirements.
[<a id="ref-PCEP-VN">PCEP-VN</a>] describes the need for associating a set of LSPs with a VN
"construct" to facilitate VN operations in PCE architecture. This
association allows the PCEs to identify which LSPs belong to a
certain VN.
This association based on VN is useful for various optimizations at
the VN level, which can be applied to all the LSPs that are part of
the VN slice. During path computation, the impact of a path for an
LSP is compared against the paths of other LSPs in the VN. This is
to ensure optimization and SLA attainment for the VN rather than for
a single LSP. Similarly, during reoptimization, advanced path
computation algorithms and optimization techniques can be considered
for all the LSPs belonging to a VN/customer and optimize them all
together.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Interface Considerations</span>
As per [<a href="./rfc8453" title=""Framework for Abstraction and Control of TE Networks (ACTN)"">RFC8453</a>], to allow virtualization and multidomain
coordination, the network has to provide open, programmable
interfaces in which customer applications can create, replace, and
modify virtual network resources and services in an interactive,
flexible, and dynamic fashion while having no impact on other
customers. The two ACTN interfaces are as follows:
o The CNC-MDSC Interface (CMI) is an interface between a Customer
Network Controller and a Multidomain Service Coordinator. It
requests the creation of the network resources, topology, or
services for the applications. The MDSC may also report potential
network topology availability if queried for current capability
from the Customer Network Controller.
o The MDSC-PNC Interface (MPI) is an interface between a Multidomain
Service Coordinator and a Provisioning Network Controller. It
communicates the creation request, if required, of new
connectivity of bandwidth changes in the physical network via the
PNC. In multidomain environments, the MDSC needs to establish
multiple MPIs, one for each PNC, as there are multiple PNCs
responsible for its domain control.
<span class="grey">Dhody, et al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc8637">RFC 8637</a> PCE-ACTN July 2019</span>
In the case of a hierarchy of MDSCs, the MPI is applied recursively.
From an abstraction point of view, the top-level MDSC, which
interfaces the CNC, operates on a higher level of abstraction (i.e.,
less granular level) than the lower-level MDSCs.
PCEP is especially suitable on the MPI as it meets the requirement
and the functions as set out in the ACTN framework [<a href="./rfc8453" title=""Framework for Abstraction and Control of TE Networks (ACTN)"">RFC8453</a>]. Its
recursive nature is well suited via the multilevel hierarchy of PCE.
PCEP can also be applied to the CMI as the CNC can be a path
computation client while the MDSC can be a path computation server.
<a href="#section-5">Section 5</a> describes how PCE and PCEP could help realize ACTN on the
MPI.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Realizing ACTN with PCE (and PCEP)</span>
As per the example in Figure 2, there are 4 domains, each with their
own PNC and MDSC on top. The PNC and MDSC need PCE as an important
function. The PNC (or Child PCE) already uses PCEP to communicate to
the network device. It can utilize the PCEP as the MPI to
communicate between controllers too.
<span class="grey">Dhody, et al. Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc8637">RFC 8637</a> PCE-ACTN July 2019</span>
******
..........*MDSC*..............................
. ****** .. MPI .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
v v v .
****** ****** ****** .
*PNC1* *PNC2* *PNC4* .
****** ****** ****** .
+---------------+ +---------------+ +---------------+ .
|A |----| |----| C| .
| | | | | | .
|DOMAIN 1 |----|DOMAIN 2 |----|DOMAIN 4 | .
+------------B13+ +---------------+ +B43------------+ .
\ / .
\ ****** / .
\ *PNC3*<............/.....................
\ ****** /
\+---------------+/
B31 B34
| |
|DOMAIN 3 B|
+---------------+
MDSC -> Parent PCE
PNC -> Child PCE
MPI -> PCEP
Figure 2: ACTN with PCE
o Building Domain Topology at MDSC: PNC (or Child PCE) needs to have
the TED to compute the path in its domain. As described in
<a href="#section-3.2">Section 3.2</a>, it can learn the topology via IGP or BGP-LS. PCEP-LS
is also a proposed mechanism to carry link state and traffic
engineering information within PCEP. A mechanism to carry
abstracted topology while hiding technology-specific information
between PNC and MDSC is described in [<a href="#ref-PCEP-LS" title=""PCEP Extension for Distribution of Link-State and TE Information."">PCEP-LS</a>]. At the end of
this step, the MDSC (or Parent PCE) has the abstracted topology
from each of its PNCs (or Child PCE). This could be as simple as
a domain topology map as described in [<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>], or it can have
full topology information of all domains. The latter is not
scalable, and thus, an abstracted topology of each domain
interconnected by interdomain links is the most common case.
<span class="grey">Dhody, et al. Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc8637">RFC 8637</a> PCE-ACTN July 2019</span>
* Topology Change: When the PNC learns of any topology change,
the PNC needs to decide if the change needs to be notified to
the MDSC. This is dependent on the level of abstraction
between the MDSC and the PNC.
o VN Instantiate: When an MDSC is requested to instantiate a VN, the
minimal information that is required would be a VN identifier and
a set of end points. Various path computation, setup constraints,
and objective functions may also be provided. In PCE terms, a VN
Instantiate can be considered as a set of paths belonging to the
same VN. As described in <a href="#section-3.4">Section 3.4</a> and [<a href="#ref-PCEP-VN" title=""Path Computation Element communication Protocol (PCEP) extensions for Establishing Relationships between sets of LSPs and Virtual Networks"">PCEP-VN</a>], the VN
association can help in identifying the set of paths that belong
to a VN. The rest of the information, like the endpoints,
constraints, and objective function (OF), is already defined in
PCEP in terms of a single path.
* Path Computation: As per the example in Figure 2, the VN
instantiate requires two end-to-end paths between (A in Domain
1 to B in Domain 3) and (A in Domain 1 to C in Domain 4). The
MDSC (or Parent PCE) triggers the end-to-end path computation
for these two paths. MDSC can do path computation based on the
abstracted domain topology that it already has, or it may use
the H-PCE procedures (<a href="#section-3.1">Section 3.1</a>) using the PCReq and PCRep
messages to get the end-to-end path with the help of the Child
PCEs (PNC). Either way, the resultant E2E paths may be broken
into per-domain paths.
* A-B: (A-B13,B13-B31,B31-B)
* A-C: (A-B13,B13-B31,B31-B34,B34-B43,B43-C)
* Per-Domain Path Instantiation: Based on the above path
computation, MDSC can issue the path instantiation request to
each PNC via PCInitiate message (see [<a href="#ref-PCE-HPCE">PCE-HPCE</a>] and [<a href="#ref-PCEP-VN" title=""Path Computation Element communication Protocol (PCEP) extensions for Establishing Relationships between sets of LSPs and Virtual Networks"">PCEP-VN</a>]).
A suitable stitching mechanism would be used to stitch these
per-domain LSPs. One such mechanism is described in
[<a href="#ref-PCE-INTERDOMAIN">PCE-INTERDOMAIN</a>], where PCEP is extended to support stitching
in stateful H-PCE context.
* Per-Domain Path Report: Each PNC should report the status of
the per-domain LSP to the MDSC via PCRpt message, as per the
hierarchy of stateful PCEs ([<a href="#ref-PCE-HPCE">PCE-HPCE</a>]). The status of the
end-to-end LSP (A-B and A-C) is made up when all the per-domain
LSPs are reported up by the PNCs.
* Delegation: It is suggested that the per-domain LSPs are
delegated to respective PNCs so that they can control the path
and attributes based on the conditions of each domain network.
<span class="grey">Dhody, et al. Informational [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc8637">RFC 8637</a> PCE-ACTN July 2019</span>
* State Synchronization: The state needs to be synchronized
between the Parent PCE and Child PCE. The mechanism described
in [<a href="#ref-PCE-STATE-SYNC">PCE-STATE-SYNC</a>] can be used.
o VN Modify: MDSC is requested to modify a VN, for example, the
bandwidth for VN is increased. This may trigger path computation
at MDSC as described in the previous step and can trigger an
update to an existing per-intradomain path (via PCUpd message) or
the creation (or deletion) of a per-domain path (via PCInitiate
message). As described in [<a href="#ref-PCE-HPCE">PCE-HPCE</a>], this should be done in
make-before-break fashion.
o VN Delete: MDSC is requested to delete a VN, in this case, based
on the E2E paths, and the resulting per-domain paths need to be
removed (via PCInitiate message).
o VN Update (based on network changes): Any change in the per-domain
LSP is reported to the MDSC (via PCRpt message) as per [<a href="#ref-PCE-HPCE">PCE-HPCE</a>].
This may result in changes in the E2E path or VN status. This may
also trigger a reoptimization leading to a new per-domain path, an
update to an existing path, or the deletion of the path.
o VN Protection: The VN protection/restoration requirements need to
be applied to each E2E path as well as each per-domain path. The
MDSC needs to play a crucial role in coordinating the right
protection/restoration policy across each PNC. The existing
protection/restoration mechanism of PCEP can be applied on each
path.
o In case a PNC generates an abstract topology towards the MDSC, the
PCInitiate/PCUpd messages from the MDSC to a PNC will contain a
path with abstract nodes and links. A PNC would need to take that
as an input for path computation to get a path with physical nodes
and links. Similarly, a PNC would convert the path received from
the device (with physical nodes and links) into an abstract path
(based on the abstract topology generated before with abstract
nodes and links) and report it to the MDSC.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. IANA Considerations</span>
This document has no IANA actions.
<span class="grey">Dhody, et al. Informational [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc8637">RFC 8637</a> PCE-ACTN July 2019</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
Various security considerations for PCEP are described in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>]
and [<a href="./rfc8253" title=""PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)"">RFC8253</a>]. Security considerations as stated in Sections <a href="#section-10.1">10.1</a>,
10.6, and 10.7 of [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>] continue to apply on PCEP when used as an
ACTN interface. Further, this document lists various extensions of
PCEP that are applicable; each of them specify various security
considerations that continue to apply here.
The ACTN framework described in [<a href="./rfc8453" title=""Framework for Abstraction and Control of TE Networks (ACTN)"">RFC8453</a>] defines key components and
interfaces for managed traffic-engineered networks. It also lists
various security considerations such as request and control of
resources, confidentially of the information, and availability of
function, which should be taken into consideration.
As per [<a href="./rfc8453" title=""Framework for Abstraction and Control of TE Networks (ACTN)"">RFC8453</a>], securing the request and control of resources,
confidentiality of the information, and availability of function
should all be critical security considerations when deploying and
operating ACTN platforms. From a security and reliability
perspective, ACTN may encounter many risks such as malicious attack
and rogue elements attempting to connect to various ACTN components
(with PCE being one of them). Furthermore, some ACTN components
represent a single point of failure and threat vector, and must also
manage policy conflicts and eavesdropping of communication between
different ACTN components. [<a href="./rfc8453" title=""Framework for Abstraction and Control of TE Networks (ACTN)"">RFC8453</a>] further states that all
protocols used to realize the ACTN framework should have rich
security features, and customer, application, and network data should
be stored in encrypted data stores. When PCEP is used as an ACTN
interface, the security of PCEP provided by Transport Layer Security
(TLS) [<a href="./rfc8253" title=""PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)"">RFC8253</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>] (unless explicitly set aside in [<a href="./rfc8253" title=""PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)"">RFC8253</a>]), is
used.
As per [<a href="./rfc8453" title=""Framework for Abstraction and Control of TE Networks (ACTN)"">RFC8453</a>], regarding the MPI, a PKI-based mechanism is
suggested, such as building a TLS or HTTPS connection between the
MDSC and PNCs, to ensure trust between the physical network layer
control components and the MDSC. Which MDSC the PNC exports topology
information to, and the level of detail (full or abstracted), should
also be authenticated, and specific access restrictions and topology
views should be configurable and/or policy based. When PCEP is used
in MPI, the security functions, as per [<a href="./rfc8253" title=""PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)"">RFC8253</a>], are used to fulfill
these requirements.
As per [<a href="./rfc8453" title=""Framework for Abstraction and Control of TE Networks (ACTN)"">RFC8453</a>], regarding the CMI, suitable authentication and
authorization of each CNC connecting to the MDSC will be required.
If PCEP is used in CMI, the security functions, as per [<a href="./rfc8253" title=""PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)"">RFC8253</a>], can
be used to support peer authentication, message encryption, and
integrity checks.
<span class="grey">Dhody, et al. Informational [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc8637">RFC 8637</a> PCE-ACTN July 2019</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</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-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-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-RFC8453">RFC8453</a>] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Abstraction and Control of TE Networks (ACTN)", <a href="./rfc8453">RFC 8453</a>,
DOI 10.17487/RFC8453, August 2018,
<<a href="https://www.rfc-editor.org/info/rfc8453">https://www.rfc-editor.org/info/rfc8453</a>>.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-ASSOC-POLICY">ASSOC-POLICY</a>]
Litkowski, S., Sivabalan, S., Tantsura, J., Hardwick, J.,
and M. Negi, "Path Computation Element communication
Protocol extension for associating Policies and LSPs",
Work in Progress, <a href="./draft-ietf-pce-association-policy-05">draft-ietf-pce-association-policy-05</a>,
February 2019.
[<a id="ref-EXP">EXP</a>] Casellas, R., Vilalta, R., Martinez, R., Munoz, R., Zheng,
H., and Y. Lee, "Experimental Validation of the ACTN
architecture for flexi-grid optical networks using Active
Stateful Hierarchical PCEs", 19th International Conference
on Transparent Optical Networks (ICTON),
DOI 10.5281/zenodo.832904, July 2017,
<<a href="https://zenodo.org/record/832904">https://zenodo.org/record/832904</a>>.
[<a id="ref-PCE-HPCE">PCE-HPCE</a>]
Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King,
"Hierarchical Stateful Path Computation Element (PCE).",
Work in Progress, <a href="./draft-ietf-pce-stateful-hpce-10">draft-ietf-pce-stateful-hpce-10</a>, June
2019.
<span class="grey">Dhody, et al. Informational [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc8637">RFC 8637</a> PCE-ACTN July 2019</span>
[<a id="ref-PCE-INTER-AREA">PCE-INTER-AREA</a>]
King, D. and H. Zheng, "Applicability of the Path
Computation Element to Interarea and Inter-AS MPLS and
GMPLS Traffic Engineering", Work in Progress,
<a href="./draft-ietf-pce-inter-area-as-applicability-07">draft-ietf-pce-inter-area-as-applicability-07</a>, December
2018.
[<a id="ref-PCE-INTERDOMAIN">PCE-INTERDOMAIN</a>]
Dugeon, O., Meuric, J., Lee, Y., and D. Ceccarelli, "PCEP
Extension for Stateful Interdomain Tunnels", Work in
Progress, <a href="./draft-dugeon-pce-stateful-interdomain-02">draft-dugeon-pce-stateful-interdomain-02</a>, March
2019.
[<a id="ref-PCE-STATE-SYNC">PCE-STATE-SYNC</a>]
Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter
Stateful Path Computation Element (PCE) Communication
Procedures.", Work in Progress,
<a href="./draft-litkowski-pce-state-sync-05">draft-litkowski-pce-state-sync-05</a>, March 2019.
[<a id="ref-PCEP-LS">PCEP-LS</a>] Dhody, D., Lee, Y., and D. Ceccarelli, "PCEP Extension for
Distribution of Link-State and TE Information.", Work in
Progress, <a href="./draft-dhodylee-pce-pcep-ls-13">draft-dhodylee-pce-pcep-ls-13</a>, February 2019.
[<a id="ref-PCEP-OPTICAL">PCEP-OPTICAL</a>]
Lee, Y., Zheng, H., Ceccarelli, D., Wang, W., Park, P.,
and B. Yoon, "PCEP Extension for Distribution of Link-
State and TE information for Optical Networks", Work in
Progress, <a href="./draft-lee-pce-pcep-ls-optical-07">draft-lee-pce-pcep-ls-optical-07</a>, March 2019.
[<a id="ref-PCEP-VN">PCEP-VN</a>] Lee, Y., Zhang, X., and D. Ceccarelli, "Path Computation
Element communication Protocol (PCEP) extensions for
Establishing Relationships between sets of LSPs and
Virtual Networks", Work in Progress,
<a href="./draft-leedhody-pce-vn-association-08">draft-leedhody-pce-vn-association-08</a>, June 2019.
[<a id="ref-RFC3630">RFC3630</a>] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", <a href="./rfc3630">RFC 3630</a>,
DOI 10.17487/RFC3630, September 2003,
<<a href="https://www.rfc-editor.org/info/rfc3630">https://www.rfc-editor.org/info/rfc3630</a>>.
[<a id="ref-RFC4203">RFC4203</a>] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", <a href="./rfc4203">RFC 4203</a>, DOI 10.17487/RFC4203, October 2005,
<<a href="https://www.rfc-editor.org/info/rfc4203">https://www.rfc-editor.org/info/rfc4203</a>>.
<span class="grey">Dhody, et al. Informational [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc8637">RFC 8637</a> PCE-ACTN July 2019</span>
[<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-RFC5212">RFC5212</a>] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux,
M., and D. Brungard, "Requirements for GMPLS-Based Multi-
Region and Multi-Layer Networks (MRN/MLN)", <a href="./rfc5212">RFC 5212</a>,
DOI 10.17487/RFC5212, July 2008,
<<a href="https://www.rfc-editor.org/info/rfc5212">https://www.rfc-editor.org/info/rfc5212</a>>.
[<a id="ref-RFC5305">RFC5305</a>] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", <a href="./rfc5305">RFC 5305</a>, DOI 10.17487/RFC5305, October
2008, <<a href="https://www.rfc-editor.org/info/rfc5305">https://www.rfc-editor.org/info/rfc5305</a>>.
[<a id="ref-RFC5307">RFC5307</a>] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions
in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", <a href="./rfc5307">RFC 5307</a>, DOI 10.17487/RFC5307, October 2008,
<<a href="https://www.rfc-editor.org/info/rfc5307">https://www.rfc-editor.org/info/rfc5307</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-RFC5623">RFC5623</a>] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel,
"Framework for PCE-Based Inter-Layer MPLS and GMPLS
Traffic Engineering", <a href="./rfc5623">RFC 5623</a>, DOI 10.17487/RFC5623,
September 2009, <<a href="https://www.rfc-editor.org/info/rfc5623">https://www.rfc-editor.org/info/rfc5623</a>>.
[<a id="ref-RFC6241">RFC6241</a>] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", <a href="./rfc6241">RFC 6241</a>, DOI 10.17487/RFC6241, June 2011,
<<a href="https://www.rfc-editor.org/info/rfc6241">https://www.rfc-editor.org/info/rfc6241</a>>.
[<a id="ref-RFC7149">RFC7149</a>] Boucadair, M. and C. Jacquenet, "Software-Defined
Networking: A Perspective from within a Service Provider
Environment", <a href="./rfc7149">RFC 7149</a>, DOI 10.17487/RFC7149, March 2014,
<<a href="https://www.rfc-editor.org/info/rfc7149">https://www.rfc-editor.org/info/rfc7149</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">Dhody, et al. Informational [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc8637">RFC 8637</a> PCE-ACTN July 2019</span>
[<a id="ref-RFC7491">RFC7491</a>] King, D. and A. Farrel, "A PCE-Based Architecture for
Application-Based Network Operations", <a href="./rfc7491">RFC 7491</a>,
DOI 10.17487/RFC7491, March 2015,
<<a href="https://www.rfc-editor.org/info/rfc7491">https://www.rfc-editor.org/info/rfc7491</a>>.
[<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-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-RFC8040">RFC8040</a>] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", <a href="./rfc8040">RFC 8040</a>, DOI 10.17487/RFC8040, January 2017,
<<a href="https://www.rfc-editor.org/info/rfc8040">https://www.rfc-editor.org/info/rfc8040</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>>.
[<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>>.
[<a id="ref-RFC8281">RFC8281</a>] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", <a href="./rfc8281">RFC 8281</a>, DOI 10.17487/RFC8281, December 2017,
<<a href="https://www.rfc-editor.org/info/rfc8281">https://www.rfc-editor.org/info/rfc8281</a>>.
<span class="grey">Dhody, et al. Informational [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc8637">RFC 8637</a> PCE-ACTN July 2019</span>
[<a id="ref-RFC8283">RFC8283</a>] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An
Architecture for Use of PCE and the PCE Communication
Protocol (PCEP) in a Network with Central Control",
<a href="./rfc8283">RFC 8283</a>, DOI 10.17487/RFC8283, December 2017,
<<a href="https://www.rfc-editor.org/info/rfc8283">https://www.rfc-editor.org/info/rfc8283</a>>.
[<a id="ref-RFC8454">RFC8454</a>] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B.
Yoon, "Information Model for Abstraction and Control of TE
Networks (ACTN)", <a href="./rfc8454">RFC 8454</a>, DOI 10.17487/RFC8454,
September 2018, <<a href="https://www.rfc-editor.org/info/rfc8454">https://www.rfc-editor.org/info/rfc8454</a>>.
<span class="grey">Dhody, et al. Informational [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc8637">RFC 8637</a> PCE-ACTN July 2019</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Additional Information</span>
In the paper [<a href="#ref-EXP" title=""Experimental Validation of the ACTN architecture for flexi-grid optical networks using Active Stateful Hierarchical PCEs"">EXP</a>], the application of the ACTN architecture is
presented to demonstrate the control of a multidomain flexi-grid
optical network by proposing, adopting, and extending:
o the Hierarchical active stateful PCE architectures and protocols
o the PCEP protocol to support efficient and incremental link-state
topological reporting, known as PCEP-LS
o the per-link partitioning of the optical spectrum based on
variable-sized allocated frequency slots enabling network sharing
and virtualization
o the use of a model-based interface to dynamically request the
instantiation of virtual networks for specific clients/tenants.
The design and implementation of the test bed are reported in order
to validate the approach.
Acknowledgments
The authors would like to thank Jonathan Hardwick for the inspiration
behind this document. Further thanks to Avantika for her comments
with suggested text.
Thanks to Adrian Farrel and Daniel King for their substantial
reviews.
Thanks to Yingzhen Qu for RTGDIR review.
Thanks to Rifaat Shekh-Yusef for SECDIR review.
Thanks to Meral Shirazipour for GENART review.
Thanks to Roman Danyliw and Barry Leiba for IESG review comments.
Thanks to Deborah Brungard for being the responsible AD.
<span class="grey">Dhody, et al. Informational [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc8637">RFC 8637</a> PCE-ACTN July 2019</span>
Authors' Addresses
Dhruv Dhody
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
Email: dhruv.ietf@gmail.com
Young Lee
Futurewei Technologies
5340 Legacy Drive, Suite 173
Plano, TX 75024
United States of America
Email: younglee.tx@gmail.com
Daniele Ceccarelli
Ericsson
Torshamnsgatan,48
Stockholm
Sweden
Email: daniele.ceccarelli@ericsson.com
Dhody, et al. Informational [Page 22]
</pre>
|
