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) E. Oki
Request for Comments: 8282 Kyoto University
Category: Standards Track T. Takeda
ISSN: 2070-1721 NTT
A. Farrel
Juniper Networks
F. Zhang
Huawei Technologies Co., Ltd.
December 2017
Extensions to the Path Computation Element Communication Protocol (PCEP)
for Inter-Layer MPLS and GMPLS Traffic Engineering
Abstract
The Path Computation Element (PCE) provides path computation
functions in support of traffic engineering in Multiprotocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) networks.
MPLS and GMPLS networks may be constructed from layered service
networks. It is advantageous for overall network efficiency to
provide end-to-end traffic engineering across multiple network layers
through a process called inter-layer traffic engineering. PCE is a
candidate solution for such requirements.
The PCE Communication Protocol (PCEP) is designed as a communication
protocol between Path Computation Clients (PCCs) and PCEs. This
document presents PCEP extensions for inter-layer traffic
engineering.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="https://www.rfc-editor.org/info/rfc8282">https://www.rfc-editor.org/info/rfc8282</a>.
<span class="grey">Oki, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc8282">RFC 8282</a> Inter-Layer PCEP December 2017</span>
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Requirements Language . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2">2</a>. Overview of PCE-Based Inter-Layer Path Computation . . . . . <a href="#page-4">4</a>
<a href="#section-3">3</a>. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.1">3.1</a>. INTER-LAYER Object . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.2">3.2</a>. SWITCH-LAYER Object . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-3.3">3.3</a>. REQ-ADAP-CAP Object . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-3.4">3.4</a>. New Metric Types . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-3.5">3.5</a>. SERVER-INDICATION Object . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-4">4</a>. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-4.1">4.1</a>. Path Computation Request . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-4.2">4.2</a>. Path Computation Reply . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-4.3">4.3</a>. Stateful PCE and PCE Initiated LSPs . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-5">5</a>. Updated Format of PCEP Messages . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-6">6</a>. Manageability Considerations . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-7">7</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-7.1">7.1</a>. New PCEP Objects . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-7.2">7.2</a>. New Registry for INTER-LAYER Object Flags . . . . . . . . <a href="#page-17">17</a>
<a href="#section-7.3">7.3</a>. New Metric Types . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-8">8</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-9">9</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-9.1">9.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-9.2">9.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-22">22</a>
<span class="grey">Oki, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc8282">RFC 8282</a> Inter-Layer PCEP December 2017</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The Path Computation Element (PCE) defined in [<a href="./rfc4655" title=""A Path Computation Element (PCE)-Based Architecture"">RFC4655</a>] is an entity
that is capable of computing a network path or route based on a
network graph and applying computational constraints. A Path
Computation Client (PCC) may make requests to a PCE for paths to be
computed, and a PCE may initiate or modify services in a network by
supplying new paths [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>] [<a href="./rfc8281" title=""Path Computation Element Communication Protocol (PCEP) Extensions for PCE-initiated LSP Setup in a Stateful PCE Model"">RFC8281</a>].
A network may comprise multiple layers. These layers may represent
separation of technologies (e.g., packet switch capable (PSC), time
division multiplex (TDM), and lambda switch capable (LSC)) [<a href="./rfc3945" title=""Generalized Multi-Protocol Label Switching (GMPLS) Architecture"">RFC3945</a>];
separation of data-plane switching granularity levels (e.g., Virtual
Circuit 4 (VC4) and VC12) [<a href="./rfc5212" title=""Requirements for GMPLS-Based Multi- Region and Multi-Layer Networks (MRN/MLN)"">RFC5212</a>]; or a distinction between client
and server networking roles (e.g., commercial or administrative
separation of client and server networks). In this multi-layer
network, Label Switched Paths (LSPs) in lower layers are used to
carry higher-layer LSPs. The network topology formed by lower-layer
LSPs and advertised as traffic engineering links (TE links) in the
higher layer is called a Virtual Network Topology (VNT) [<a href="./rfc5212" title=""Requirements for GMPLS-Based Multi- Region and Multi-Layer Networks (MRN/MLN)"">RFC5212</a>].
Discussion of other ways that network layering can be supported such
that connectivity in a higher-layer network can be provided by LSPs
in a lower-layer network is provided in [<a href="./rfc7926" title=""Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks"">RFC7926</a>].
It is important to optimize network resource utilization globally,
i.e., taking into account all layers, rather than optimizing resource
utilization at each layer independently. This allows better network
efficiency to be achieved. This is what we call inter-layer traffic
engineering. This includes mechanisms allowing the computation of
end-to-end paths across layers (known as inter-layer path
computation) and mechanisms for control and management of the VNT by
setting up and releasing LSPs in the lower layers [<a href="./rfc5212" title=""Requirements for GMPLS-Based Multi- Region and Multi-Layer Networks (MRN/MLN)"">RFC5212</a>].
PCE can provide a suitable mechanism for resolving inter-layer path
computation issues. The framework for applying the PCE-based path
computation architecture to inter-layer traffic engineering is
described in [<a href="./rfc5623" title=""Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering"">RFC5623</a>].
The PCE communication protocol (PCEP) is designed as a communication
protocol between PCCs and PCEs and is defined in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>]. A set of
requirements for PCEP extensions to support inter-layer traffic
engineering is described in [<a href="./rfc6457" title=""PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering"">RFC6457</a>].
This document presents PCEP extensions for inter-layer traffic
engineering that satisfy the requirements described in [<a href="./rfc6457" title=""PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering"">RFC6457</a>].
<span class="grey">Oki, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc8282">RFC 8282</a> Inter-Layer PCEP December 2017</span>
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Requirements Language</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
<a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] [<a href="./rfc8174" title=""Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"">RFC8174</a>] when, and only when, they appear in all
capitals, as shown here.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Overview of PCE-Based Inter-Layer Path Computation</span>
[<a id="ref-RFC4206">RFC4206</a>] defines a way to signal a higher-layer LSP, which has an
explicit route that includes hops traversed by LSPs in lower layers.
The computation of end-to-end paths across layers is called inter-
layer path computation.
A Label Switching Router (LSR) in the higher layer might not have
information on the lower-layer topology, particularly in an overlay
or augmented model [<a href="./rfc3945" title=""Generalized Multi-Protocol Label Switching (GMPLS) Architecture"">RFC3945</a>]; hence, it may not be able to compute an
end-to-end path across layers.
PCE-based inter-layer path computation consists of using one or more
PCEs to compute an end-to-end path across layers. This could be
achieved by relying on a single PCE that has topology information
about multiple layers and can directly compute an end-to-end path
across layers considering the topology of all of the layers.
Alternatively, the inter-layer path computation could be performed
using multiple cooperating PCEs where each PCE has information about
the topology of one or more layers (but not all layers) and where the
PCEs collaborate to compute an end-to-end path.
As described in [<a href="./rfc5339" title=""Evaluation of Existing GMPLS Protocols against Multi-Layer and Multi- Region Networks (MLN/MRN)"">RFC5339</a>], a hybrid node may advertise a single TE
link with multiple switching capabilities. Normally, those TE links
exist at the layer/region boarder. In this case, a PCE needs to be
capable of specifying the server-layer path information when the
server-layer path information is required to be returned to the PCC.
[<a id="ref-RFC5623">RFC5623</a>] describes models for inter-layer path computation in more
detail. It introduces the Virtual Network Topology Manager (VNTM), a
functional element that controls the VNT, and sets out three distinct
models (and a fourth hybrid model) for inter-layer control involving
a PCE, triggered signaling, and a Network Management System (NMS).
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Protocol Extensions</span>
This section describes PCEP extensions for inter-layer path
computation. Four new objects are defined: the INTER-LAYER object,
the SWITCH-LAYER object, the REQ-ADAP-CAP object, and the SERVER-
INDICATION object. Also, two new metric types are defined.
<span class="grey">Oki, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc8282">RFC 8282</a> Inter-Layer PCEP December 2017</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. INTER-LAYER Object</span>
The INTER-LAYER object is optional and can be used in Path
Computation Request (PCReq) and Path Computation Reply (PCRep)
messages, and also in Path Computation State Report (PCRpt), Path
Computation Update Request (PCUpd), and Path Computation LSP Initiate
Request (PCInitiate) messages.
In a PCReq message, the INTER-LAYER object indicates whether inter-
layer path computation is allowed, the type of path to be computed,
and whether triggered signaling (hierarchical LSPs per [<a href="./rfc4206" title=""Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)"">RFC4206</a>] or
stitched LSPs per [<a href="./rfc5150" title=""Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)"">RFC5150</a>] depending on physical network
technologies) is allowed. When the INTER-LAYER object is absent from
a PCReq message, the receiving PCE MUST process as though inter-layer
path computation had been explicitly disallowed (I-bit set to zero --
see below).
In a PCRep message, the INTER-LAYER object indicates whether
inter-layer path computation has been performed, the type of path
that has been computed, and whether triggered signaling is used.
When a PCReq message includes more than one request, an INTER-LAYER
object is used per request. When a PCRep message includes more than
one path per request that is responded to, an INTER-LAYER object is
used per path.
The applicability of this object to PCRpt and PCUpd messages is the
same as for other objects on those messages as described in
[<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>]. The applicability of this object to the PCInitiate
message is the same as for other objects on those messages as
described in [<a href="./rfc8281" title=""Path Computation Element Communication Protocol (PCEP) Extensions for PCE-initiated LSP Setup in a Stateful PCE Model"">RFC8281</a>]. These messages use the <attribute-list> as
defined in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>] and extended by further PCEP extensions, so the
<attribute-list> as extended in <a href="#section-5">Section 5</a> can be used to include the
INTER-LAYER object on these messages.
INTER-LAYER Object-Class is 36.
Inter-layer Object-Type is 1.
The format of the INTER-LAYER object body is shown in Figure 1.
<span class="grey">Oki, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc8282">RFC 8282</a> Inter-Layer PCEP December 2017</span>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |T|M|I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The INTER-LAYER Object
I flag (1 bit): The I flag is used by a PCC in a PCReq message to
indicate to a PCE whether an inter-layer path is allowed. When the I
flag is set (one), the PCE MAY perform inter-layer path computation
and return an inter-layer path. When the flag is clear (zero), the
path that is returned MUST NOT be an inter-layer path.
The I flag is used by a PCE in a PCRep message to indicate to a PCC
whether the path returned is an inter-layer path. When the I flag is
set (one), the path is an inter-layer path. When it is clear (zero),
the path is contained within a single layer because either inter-
layer path computation was not performed or a mono-layer path
(without any virtual TE link and without any loose hop that spans the
lower-layer network) was found notwithstanding the use of inter-layer
path computation.
M flag (1 bit): The M flag is used by a PCC in a PCReq message to
indicate to a PCE whether a mono-layer path or multi-layer path is
requested. When the M flag is set (one), a multi-layer path is
requested. When it is clear (zero), a mono-layer path is requested.
The M flag is used by a PCE in a PCRep message to indicate to a PCC
whether a mono-layer path or multi-layer path is returned. When the
M flag is set (one), a multi-layer path is returned. When the M flag
is clear (zero), a mono-layer path is returned.
If the I flag is clear (zero), the M flag has no meaning and MUST be
ignored.
[<a id="ref-RFC6457">RFC6457</a>] describes two sub-options for mono-layer path.
o A mono-layer path that is specified by strict hops. The path may
include virtual TE links.
o A mono-layer path that includes loose hops that span the lower-
layer network.
The choice of this sub-option can be specified by the use of the O
flag in the Request Parameter (RP) object specified in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>].
<span class="grey">Oki, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc8282">RFC 8282</a> Inter-Layer PCEP December 2017</span>
T flag (1 bit): The T flag is used by a PCC in a PCReq message to
indicate to a PCE whether triggered signaling is allowed. When the T
flag is set (one), triggered signaling is allowed. When it is clear
(zero), triggered signaling is not allowed.
The T flag is used by a PCE in a PCRep message to indicate to a PCC
whether triggered signaling is required to support the returned path.
When the T flag is set (one), triggered signaling is required. When
it is clear (zero), triggered signaling is not required.
Note that triggered signaling is used to support hierarchical
[<a href="./rfc4206" title=""Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)"">RFC4206</a>] or stitched [<a href="./rfc5150" title=""Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)"">RFC5150</a>] LSPs according to the physical
attributes of the network layers.
If the I flag is clear (zero), the T flag has no meaning and MUST be
ignored.
Note that the I and M flags differ in the following ways. When the I
flag is clear (zero), virtual TE links must not be used in path
computation. In addition, loose hops that span the lower-layer
network must not be specified. Only regular TE links from the same
layer may be used.
o When the I flag is set (one), the M flag is clear (zero), and the
T flag is set (one), virtual TE links are allowed in path
computation. In addition, when the O flag of the RP object is
set, loose hops that span the lower-layer network may be
specified. This will initiate lower-layer LSP setup; thus, the
inter-layer path is set up even though the path computation result
from a PCE to a PCC includes hops from the same layer only.
o However, when the I flag is set (one), the M flag is clear (zero),
and the T flag is clear (zero), since triggered signaling is not
allowed, virtual TE links that have not been pre-signaled MUST NOT
be used in path computation. In addition, loose hops that span
the lower-layer network MUST NOT be specified. Therefore, this is
equivalent to the I flag being clear (zero).
Reserved bits of the INTER-LAYER object sent between a PCC and PCE in
the same domain MUST be transmitted as zero and SHOULD be ignored on
receipt. A PCE that forwards a path computation request to other
PCEs MUST preserve the settings of reserved bits in the PCReq
messages it sends and in the PCRep messages it forwards to PCCs.
Note that the flags in the PCRpt message indicate the state of an
LSP, whereas the flags in the PCUpd and the PCInitiate messages
indicate the intended/desired state as determined by the PCE.
<span class="grey">Oki, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc8282">RFC 8282</a> Inter-Layer PCEP December 2017</span>
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. SWITCH-LAYER Object</span>
The SWITCH-LAYER object is optional on a PCReq message and specifies
switching layers in which a path MUST, or MUST NOT, be established.
A switching layer is expressed as a switching type and encoding type.
When a SWITCH-LAYER object is used on a PCReq, it is interpreted in
the context of the INTER-LAYER object on the same message. If no
INTER-LAYER object is present, the PCE MUST process the SWITCH-LAYER
object as though inter-layer path computation had been explicitly
disallowed. In such a case, the SWITCH-LAYER object MUST NOT have
more than one LSP Encoding Type and Switching Type with the I flag
set.
The SWITCH-LAYER object is optional on a PCRep message, where it is
used with the NO-PATH object in the case of unsuccessful path
computation to indicate the set of constraints that could not be
satisfied.
The SWITCH-LAYER object may be used on a PCRpt message consistent
with how properties of existing LSPs are reported on that message
[<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>]. The PCRpt message uses the <attribute-list> as defined in
[<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>] and extended by further PCEP extensions. This message can
use the <attribute-list> as extended in <a href="#section-5">Section 5</a> to carry the
SWITCH-LAYER object. The SWITCH-LAYER object is not used on a PCUpd
or PCInitiate messages.
SWITCH-LAYER Object-Class is 37.
Switch-layer Object-Type is 1.
The format of the SWITCH-LAYER object body is shown in Figure 2.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | Reserved |I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
// . //
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | Reserved |I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The SWITCH-LAYER Object
<span class="grey">Oki, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc8282">RFC 8282</a> Inter-Layer PCEP December 2017</span>
Each row indicates a switching type and encoding type that must or
must not be used for a specified layer(s) in the computed path.
The format is based on [<a href="./rfc3471" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"">RFC3471</a>] and has equivalent semantics.
LSP Encoding Type (8 bits): see [<a href="./rfc3471" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"">RFC3471</a>] for a description of
parameters.
Switching Type (8 bits): see [<a href="./rfc3471" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"">RFC3471</a>] for a description of
parameters.
I flag (1 bit): the I flag indicates whether a layer with the
specified switching type and encoding type must or must not be used
by the computed path. When the I flag is set (one), the computed
path MUST traverse a layer with the specified switching type and
encoding type. When the I flag is clear (zero), the computed path
MUST NOT enter or traverse any layer with the specified switching
type and encoding type.
When a combination of switching type and encoding type is not
included in the SWITCH-LAYER object, the computed path MAY traverse a
layer with that combination of switching type and encoding type.
A PCC may want to specify only a Switching Type and not an LSP
Encoding Type. In this case, the LSP Encoding Type is set to zero.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. REQ-ADAP-CAP Object</span>
The REQ-ADAP-CAP object is optional and is used to specify a
requested adaptation capability for both ends of the lower-layer LSP.
The REQ-ADAP-CAP object is used in a PCReq message for inter-PCE
communication, where the PCE that is responsible for computing
higher-layer paths acts as a PCC to request a path computation from a
PCE that is responsible for computing lower-layer paths.
The REQ-ADAP-CAP object is used in a PCRep message in case of
unsuccessful path computation (in this case, the PCRep message also
contains a NO-PATH object, and the REQ-ADAP-CAP object is used to
indicate the set of constraints that could not be satisfied).
The REQ-ADAP-CAP object MAY be used in a PCReq message in a mono-
layer network to specify a requested adaptation capability for both
ends of the LSP. In this case, it MAY be carried without an INTER-
LAYER object.
The applicability of this object to PCRpt and PCUpd messages is the
same as for other objects on those messages as described in
[<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>]. The applicability of this object to the PCInitiate
<span class="grey">Oki, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc8282">RFC 8282</a> Inter-Layer PCEP December 2017</span>
message is the same as for other objects on those messages as
described in [<a href="./rfc8281" title=""Path Computation Element Communication Protocol (PCEP) Extensions for PCE-initiated LSP Setup in a Stateful PCE Model"">RFC8281</a>]. These messages use the <attribute-list> as
defined in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>] and extended by further PCEP extensions. These
messages can use the <attribute-list> as extended in <a href="#section-5">Section 5</a> to
carry the REQ-ADAP-CAP object.
REQ-ADAP-CAP Object-Class is 38.
Req-Adap-Cap Object-Type is 1.
The format of the REQ-ADAP-CAP object body is shown in Figure 3.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Cap | Encoding | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The REQ-ADAP-CAP Object
The format is based on [<a href="./rfc6001" title=""Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/ MRN)"">RFC6001</a>] and has equivalent semantics as the
Interface Adjustment Capability Descriptor (IACD) Upper Switching
Capability and Lower Switching Capability fields.
Switching Capability (8 bits): see [<a href="./rfc4203" title=""OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)"">RFC4203</a>] for a description of
parameters.
Encoding (8 bits): see [<a href="./rfc3471" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"">RFC3471</a>] for a description of parameters.
A PCC may want to specify a Switching Capability, but not an
Encoding. In this case, the Encoding MUST be set to zero.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. New Metric Types</span>
This document defines two new metric types for use in the PCEP METRIC
object.
IANA has assigned the value 18 to indicate the metric "Number of
adaptations on a path".
IANA has assigned the value 19 to indicate the metric "Number of
layers on a path".
See Sections <a href="#section-4.1">4.1</a>, <a href="#section-4.2">4.2</a>, and <a href="#section-4.3">4.3</a> for a description of how these metrics
are applied.
<span class="grey">Oki, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc8282">RFC 8282</a> Inter-Layer PCEP December 2017</span>
<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>. SERVER-INDICATION Object</span>
The SERVER-INDICATION is optional and is used to indicate that path
information included in the Explicit Route Object (ERO) is server-
layer information, and it specifies the characteristics of the server
layer, e.g., the switching capability and encoding of the server-
layer path.
The format of the SERVER-INDICATION object body is shown in Figure 4.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Cap | Encoding | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Optional TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The SERVER-INDICATION Object
SERVER-INDICATION Object-Class is 39.
Server-indication Object-Type is 1.
Switching Capability (8 bits): see [<a href="./rfc4203" title=""OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)"">RFC4203</a>] for a description of
parameters.
Encoding (8 bits): see [<a href="./rfc3471" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"">RFC3471</a>] for a description of parameters.
Optional TLVs: Optional TLVs MAY be included within the object to
specify more specific server-layer path information (e.g., traffic
parameters). Such TLVs will be defined by other documents.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Procedures</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Path Computation Request</span>
A PCC requests or allows inter-layer path computation in a PCReq
message by including the INTER-LAYER object with the I flag set. The
INTER-LAYER object indicates whether inter-layer path computation is
allowed, which path type is requested, and whether triggered
signaling is allowed.
The SWITCH-LAYER object, which MUST NOT be present unless the INTER-
LAYER object is also present, is optionally used to specify the
switching types and encoding types that define layers that must, or
must not, be used in the computed path. When the SWITCH-LAYER object
is used with the INTER-LAYER object I flag clear (zero), inter-layer
<span class="grey">Oki, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc8282">RFC 8282</a> Inter-Layer PCEP December 2017</span>
path computation is not allowed, but constraints specified in the
SWITCH-LAYER object apply. Example usage includes path computation
in a single-layer GMPLS network.
The REQ-ADAP-CAP object is optionally used to specify the interface
switching capability of both ends of the lower-layer LSP. The
REQ-ADAP-CAP object is used in inter-PCE communication, where the PCE
that is responsible for computing higher-layer paths makes a request
as a PCC to a PCE that is responsible for computing lower-layer
paths. Alternatively, the REQ-ADAP-CAP object may be used in the
NMS-VNTM model, where the VNTM makes a request as a PCC to a PCE that
is responsible for computing lower-layer paths.
The METRIC object is optionally used to specify metric types to be
optimized or bounded. When metric type 18 is used, it indicates that
path computation MUST minimize or bound the number of adaptations on
a path. When metric type 19 is used, it indicates that path
computation MUST minimize or bound the number of layers to be
involved on a path.
Furthermore, in order to allow different Objective Functions (OFs) to
be applied within different network layers, multiple OF objects
[<a href="./rfc5541" title=""Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"">RFC5541</a>] MAY be present. In such a case, the first OF object
specifies an objective function for the higher-layer network, and
subsequent OF objects specify objection functions of the subsequent
lower-layer networks.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Path Computation Reply</span>
In the case of successful path computation, the requested PCE replies
to the requesting PCC for the inter-layer path computation result in
a PCRep message that MAY include the INTER-LAYER object. When the
INTER-LAYER object is included in a PCRep message, the I, M, and T
flags indicate semantics of the path as described in <a href="#section-3.1">Section 3.1</a>.
Furthermore, when the C flag of the METRIC object in a PCReq is set,
the METRIC object MUST be included in the PCRep to provide the
computed metric value, as specified in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>].
The PCE MAY specify the server-layer path information in the ERO. In
this case, the requested PCE replies with a PCRep message that
includes at least two sets of ERO information in the path-list: one
is for the client-layer path information, and another one is the
server-layer path information. When SERVER-INDICATION is included in
a PCRep message, it indicates that the path in the ERO is the server-
layer path information. The server-layer path specified in the ERO
could be loose or strict. On receiving the replied path, the PCC
(e.g., NMS and ingress node) can trigger the signaling to set up the
LSPs according to the computed paths.
<span class="grey">Oki, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc8282">RFC 8282</a> Inter-Layer PCEP December 2017</span>
In the case of unsuccessful path computation, the PCRep message also
contains a NO-PATH object, and the SWITCH-TYPE object and/or
REQ-ADAP-CAP MAY be used to indicate the set of constraints that
could not be satisfied.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Stateful PCE and PCE Initiated LSPs</span>
Processing for stateful PCEs is described in [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>]. That
document defines the PCRpt message to allow a PCC to report to a PCE
that an LSP already exists in the network and to delegate control of
that LSP to the PCE.
When the LSP is a multi-layer LSP (or a mono-layer LSP for which
specific adaptations exist), the message objects defined in this
document are used on the PCRpt to describe an LSP that is delegated
to the PCE so that the PCE may process the LSP.
Furthermore, [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>] defines the PCUpd message to allow a PCE to
modify an LSP that has been delegated to it. When the LSP is a
multi-layer LSP (or a mono-layer LSP for which specific adaptations
exist), the message objects defined in this document are used on the
PCUpd to describe the new attributes of the modified LSP.
Processing for PCE-initiated LSPs is described in [<a href="./rfc8281" title=""Path Computation Element Communication Protocol (PCEP) Extensions for PCE-initiated LSP Setup in a Stateful PCE Model"">RFC8281</a>]. That
document defines the PCInitiate message that is used by a PCE to
request a PCC to set up a new LSP. When the LSP is a multi-layer LSP
(or a mono-layer LSP for which specific adaptations exist), the
message objects defined in this document are used on the PCInitiate
to describe the attributes of the new LSP.
The new metric types defined in this document can also be used with
the stateful PCE extensions. The format of PCEP messages described
in [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>] and [<a href="./rfc8281" title=""Path Computation Element Communication Protocol (PCEP) Extensions for PCE-initiated LSP Setup in a Stateful PCE Model"">RFC8281</a>] uses <attribute-list> (which is extended
in <a href="#section-5">Section 5</a> for the purpose of including the new metrics).
The stateful PCE implementation MAY use the extension of PCReq and
PCRep messages as defined in <a href="#section-5">Section 5</a> to also enable the use of
inter-layer parameters during passive stateful operations, using the
LSP object.
<span class="grey">Oki, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc8282">RFC 8282</a> Inter-Layer PCEP December 2017</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Updated Format of PCEP Messages</span>
Message formats in this section, as those in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>], are presented
using Routing Backus-Naur Format (RBNF) as specified in [<a href="./rfc5511" title=""Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications"">RFC5511</a>].
The format of the PCReq message is updated as shown in Figure 5.
<PCReq Message>::= <Common Header>
[<svec-list>]
<request-list>
where:
<svec-list>::=<SVEC>
[<svec-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<END-POINTS>
[<LSP>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<of-list>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
[<INTER-LAYER> [<SWITCH-LAYER>]]
[<REQ-ADAP-CAP>]
where:
<of-list>::=<OF>[<of-list>]
<metric-list>::=<METRIC>[<metric-list>]
Figure 5: The Updated PCReq Message
The format of the PCRep message is updated as shown in Figure 6.
<span class="grey">Oki, et al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc8282">RFC 8282</a> Inter-Layer PCEP December 2017</span>
<PCRep Message> ::= <Common Header>
<response-list>
where:
<response-list>::=<response>[<response-list>]
<response>::=<RP>
[<LSP>]
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
<path-list>::=<path>[<path-list>]
<path>::= <ERO><attribute-list>
where:
<attribute-list>::=[<of-list>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
[<INTER-LAYER>]
[<SWITCH-LAYER>]
[<REQ-ADAP-CAP>]
[<SERVER-INDICATION>]
<of-list>::=<OF>[<of-list>]
<metric-list>::=<METRIC>[<metric-list>]
Figure 6: The Updated PCRep Message
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Manageability Considerations</span>
Implementations of this specification should provide a mechanism to
configure any optional features (such as whether a PCE supports
inter-layer computation and which metrics are supported).
A Management Information Base (MIB) module for modeling PCEP is
described in [<a href="./rfc7420" title=""Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module"">RFC7420</a>]. Systems that already use a MIB module to
manage their PCEP implementations might want to augment that module
to provide controls and indicators for support of inter-layer
features defined in this document and to add counters of messages
sent and received containing the objects defined here.
<span class="grey">Oki, et al. Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc8282">RFC 8282</a> Inter-Layer PCEP December 2017</span>
However, the preferred mechanism for configuration is through a YANG
model. Work has started on a YANG model for PCEP [<a href="#ref-PCEP-YANG">PCEP-YANG</a>], and
this could be enhanced as described for the MIB module, above.
Additional policy configuration might be provided to allow a PCE to
discriminate between the computation services offered to different
PCCs.
A set of monitoring tools for the PCE-based architecture are provided
in [<a href="./rfc5886" title=""A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture"">RFC5886</a>]. Systems implementing this specification and PCE
monitoring should consider defining extensions to the mechanisms
defined in [<a href="./rfc5886" title=""A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture"">RFC5886</a>] to help monitor inter-layer path computation
requests.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
IANA maintains a registry called "Path Computation Element Protocol
(PCEP) Numbers". Per this document, IANA has carried out actions on
subregistries of that registry.
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. New PCEP Objects</span>
IANA has made the following assignments in the "PCEP Objects"
subregistry.
Object-Class Value | Name | Object-Type | Reference
-------------------+-------+-----------------------+-----------
INTER-LAYER | 36 | 0: Reserved | <a href="./rfc8282">RFC 8282</a>
| | 1: Inter-layer |
| | 2-15: Unassigned |
| | |
SWITCH-LAYER | 37 | 0: Reserved | <a href="./rfc8282">RFC 8282</a>
| | 1: Switch-layer |
| | 2-15: Unassigned |
| | |
REQ-ADAP-CAP | 38 | 0: Reserved | <a href="./rfc8282">RFC 8282</a>
| | 1: Req-Adap-Cap |
| | 2-15: Unassigned |
| | |
SERVER-INDICATION | 39 | 0: Reserved | <a href="./rfc8282">RFC 8282</a>
| | 1: Server-indication |
Figure 7: New PCEP Objects
<span class="grey">Oki, et al. Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc8282">RFC 8282</a> Inter-Layer PCEP December 2017</span>
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. New Registry for INTER-LAYER Object Flags</span>
IANA has created a new subregistry to manage the Flag field of the
INTER-LAYER object called the "Inter-Layer Object Path Property Bits"
registry.
New bit numbers may be allocated only by "IETF Review" [<a href="./rfc8126" title="">RFC8126</a>].
Each bit should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit up to
a maximum of bit 31)
o Capability Description
o Defining RFC
IANA has populated the registry as follows:
Bit | Flag | Multi-Layer Path Property | Reference
----+------+-------------------------------+------------
0-28| | Unassigned |
29 | T | Triggered Signaling Allowed | <a href="./rfc8282">RFC 8282</a>
30 | M | Multi-Layer Requested | <a href="./rfc8282">RFC 8282</a>
31 | I | Inter-Layer Allowed | <a href="./rfc8282">RFC 8282</a>
Figure 8: New Registry for INTER-LAYER Object Flags
<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>. New Metric Types</span>
Two new metric types are defined in this document for the METRIC
object (specified in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>]). IANA has made the following
allocations from the "Metric Object T Field" registry.
Value | Description | Reference
------+---------------------------------+------------
18 | Number of adaptations on a path | <a href="./rfc8282">RFC 8282</a>
19 | Number of layers on a path | <a href="./rfc8282">RFC 8282</a>
Figure 9: New Metric Types
IANA has updated the registry to show the registration procedure of
"IETF Review" as already documented in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>].
<span class="grey">Oki, et al. Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc8282">RFC 8282</a> Inter-Layer PCEP December 2017</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
Inter-layer traffic engineering with PCE may raise new security
issues when PCE-PCE communication is done between different layer
networks for inter-layer path computation. Security issues may also
exist when a single PCE is granted full visibility of TE information
that applies to multiple layers.
The Path-Key-based mechanism defined in [<a href="./rfc5520" title=""Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism"">RFC5520</a>] MAY be applied to
address the topology confidentiality between different layers.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. References</span>
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC3471">RFC3471</a>] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description",
<a href="./rfc3471">RFC 3471</a>, DOI 10.17487/RFC3471, January 2003,
<<a href="https://www.rfc-editor.org/info/rfc3471">https://www.rfc-editor.org/info/rfc3471</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>>.
[<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>>.
[<a id="ref-RFC4206">RFC4206</a>] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", <a href="./rfc4206">RFC 4206</a>,
DOI 10.17487/RFC4206, October 2005,
<<a href="https://www.rfc-editor.org/info/rfc4206">https://www.rfc-editor.org/info/rfc4206</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>>.
<span class="grey">Oki, et al. Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc8282">RFC 8282</a> Inter-Layer PCEP December 2017</span>
[<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-RFC8126">RFC8126</a>] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>,
<a href="./rfc8126">RFC 8126</a>, DOI 10.17487/RFC8126, June 2017,
<<a href="https://www.rfc-editor.org/info/rfc8126">https://www.rfc-editor.org/info/rfc8126</a>>.
[<a id="ref-RFC8174">RFC8174</a>] Leiba, B., "Ambiguity of Uppercase vs Lowercase in <a href="./rfc2119">RFC</a>
<a href="./rfc2119">2119</a> Key Words", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc8174">RFC 8174</a>, DOI 10.17487/RFC8174,
May 2017, <<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>>.
[<a id="ref-RFC8231">RFC8231</a>] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", <a href="./rfc8231">RFC 8231</a>,
DOI 10.17487/RFC8231, September 2017,
<<a href="https://www.rfc-editor.org/info/rfc8231">https://www.rfc-editor.org/info/rfc8231</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="http://www.rfc-editor.org/info/rfc20">http://www.rfc-editor.org/info/rfc20</a>>.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative References</span>
[<a id="ref-PCEP-YANG">PCEP-YANG</a>]
Dhody, D., Hardwick, J., Beeram, V., and j.
jefftant@gmail.com, "A YANG Data Model for Path
Computation Element Communications Protocol (PCEP)", Work
in Progress, <a href="./draft-ietf-pce-pcep-yang-05">draft-ietf-pce-pcep-yang-05</a>, June 2017.
[<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-RFC5150">RFC5150</a>] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel,
"Label Switched Path Stitching with Generalized
Multiprotocol Label Switching Traffic Engineering (GMPLS
TE)", <a href="./rfc5150">RFC 5150</a>, DOI 10.17487/RFC5150, February 2008,
<<a href="https://www.rfc-editor.org/info/rfc5150">https://www.rfc-editor.org/info/rfc5150</a>>.
<span class="grey">Oki, et al. Standards Track [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc8282">RFC 8282</a> Inter-Layer PCEP December 2017</span>
[<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-RFC5339">RFC5339</a>] Le Roux, JL., Ed. and D. Papadimitriou, Ed., "Evaluation
of Existing GMPLS Protocols against Multi-Layer and Multi-
Region Networks (MLN/MRN)", <a href="./rfc5339">RFC 5339</a>,
DOI 10.17487/RFC5339, September 2008,
<<a href="https://www.rfc-editor.org/info/rfc5339">https://www.rfc-editor.org/info/rfc5339</a>>.
[<a id="ref-RFC5511">RFC5511</a>] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol
Specifications", <a href="./rfc5511">RFC 5511</a>, DOI 10.17487/RFC5511, April
2009, <<a href="https://www.rfc-editor.org/info/rfc5511">https://www.rfc-editor.org/info/rfc5511</a>>.
[<a id="ref-RFC5541">RFC5541</a>] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", <a href="./rfc5541">RFC 5541</a>,
DOI 10.17487/RFC5541, June 2009,
<<a href="https://www.rfc-editor.org/info/rfc5541">https://www.rfc-editor.org/info/rfc5541</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-RFC5886">RFC5886</a>] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of
Monitoring Tools for Path Computation Element (PCE)-Based
Architecture", <a href="./rfc5886">RFC 5886</a>, DOI 10.17487/RFC5886, June 2010,
<<a href="https://www.rfc-editor.org/info/rfc5886">https://www.rfc-editor.org/info/rfc5886</a>>.
[<a id="ref-RFC6001">RFC6001</a>] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard,
D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol
Extensions for Multi-Layer and Multi-Region Networks (MLN/
MRN)", <a href="./rfc6001">RFC 6001</a>, DOI 10.17487/RFC6001, October 2010,
<<a href="https://www.rfc-editor.org/info/rfc6001">https://www.rfc-editor.org/info/rfc6001</a>>.
[<a id="ref-RFC6457">RFC6457</a>] Takeda, T., Ed. and A. Farrel, "PCC-PCE Communication and
PCE Discovery Requirements for Inter-Layer Traffic
Engineering", <a href="./rfc6457">RFC 6457</a>, DOI 10.17487/RFC6457, December
2011, <<a href="https://www.rfc-editor.org/info/rfc6457">https://www.rfc-editor.org/info/rfc6457</a>>.
<span class="grey">Oki, et al. Standards Track [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc8282">RFC 8282</a> Inter-Layer PCEP December 2017</span>
[<a id="ref-RFC7420">RFC7420</a>] Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
Hardwick, "Path Computation Element Communication Protocol
(PCEP) Management Information Base (MIB) Module",
<a href="./rfc7420">RFC 7420</a>, DOI 10.17487/RFC7420, December 2014,
<<a href="https://www.rfc-editor.org/info/rfc7420">https://www.rfc-editor.org/info/rfc7420</a>>.
[<a id="ref-RFC7926">RFC7926</a>] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G.,
Ceccarelli, D., and X. Zhang, "Problem Statement and
Architecture for Information Exchange between
Interconnected Traffic-Engineered Networks", <a href="https://www.rfc-editor.org/bcp/bcp206">BCP 206</a>,
<a href="./rfc7926">RFC 7926</a>, DOI 10.17487/RFC7926, July 2016,
<<a href="https://www.rfc-editor.org/info/rfc7926">https://www.rfc-editor.org/info/rfc7926</a>>.
Acknowledgments
The authors would like to thank Cyril Margaria for his valuable
comments. Helpful comments and suggested text were offered by Dhruv
Dhody, who also fixed the RBNF. Jonathan Hardwick provided a helpful
review as document shepherd.
Contributors
Jean-Louis Le Roux
France Telecom R&D
Av Pierre Marzin
Lannion 22300
France
Email: jeanlouis.leroux@orange.com
<span class="grey">Oki, et al. Standards Track [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc8282">RFC 8282</a> Inter-Layer PCEP December 2017</span>
Authors' Addresses
Eiji Oki
Kyoto University
Yoshida-honmachi, Sakyo-ku, Kyoto
Japan
Email: oki@i.kyoto-u.ac.jp
Tomonori Takeda
NTT
3-9-11 Midori-cho
Musashino-shi, Tokyo
Japan
Email: tomonori.takeda@ntt.com
Adrian Farrel
Juniper Networks
Email: afarrel@juniper.net
Fatai Zhang
Huawei Technologies Co., Ltd.
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District, Shenzhen 518129
China
Phone: +86-755-28972912
Email: zhangfatai@huawei.com
Oki, et al. Standards Track [Page 22]
</pre>
|
