-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-ietf-pce-stateful-pce-p2mp-13.xml
1875 lines (1752 loc) · 80 KB
/
draft-ietf-pce-stateful-pce-p2mp-13.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
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
<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"
[]>
<?rfc toc="yes" ?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?>
<?rfc compact="yes" ?>
<?rfc iprnotified="Yes" ?>
<?rfc strict="no" ?>
<rfc ipr="trust200902"
category="std"
docName="draft-ietf-pce-stateful-pce-p2mp-13"
obsoletes=""
updates=""
submissionType="IETF"
xml:lang="en">
<front>
<title abbrev="STATEFUL-P2MP">Path Computation Element (PCE)
Protocol Extensions for Stateful PCE usage for
Point-to-Multipoint Traffic Engineering Label Switched
Paths</title>
<author initials="U"
surname="Palle"
fullname="Udayasree Palle">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>udayasreereddy@gmail.com</email>
</address>
</author>
<author fullname="Dhruv Dhody"
initials="D"
surname="Dhody">
<organization abbrev="Huawei Technologies">Huawei
Technologies</organization>
<address>
<postal>
<street>Divyashree Techno Park, Whitefield</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560066</code>
<country>India</country>
</postal>
<email>dhruv.ietf@gmail.com</email>
</address>
</author>
<author initials='Y.T'
surname="Tanaka"
fullname='Yosuke Tanaka'>
<organization abbrev="NTT Communications">NTT Communications
Corporation</organization>
<address>
<postal>
<street>Granpark Tower</street>
<street>3-4-1 Shibaura, Minato-ku</street>
<region>Tokyo</region>
<code>108-8118</code>
<country>Japan</country>
</postal>
<email>yosuke.tanaka@ntt.com</email>
</address>
</author>
<author initials="V" surname="Beeram" fullname="Vishnu Pavan Beeram">
<organization>Juniper Networks</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>vbeeram@juniper.net</email>
</address>
</author>
<date day="23" month="March"
year="2019" />
<area>Routing</area>
<workgroup>PCE Working Group</workgroup>
<abstract>
<t>The Path Computation Element (PCE) has been identified as
an appropriate technology for the determination of the paths
of point-to-multipoint (P2MP) TE Label Switched Paths (LSPs).
This document provides
extensions required for Path Computation Element Communication Protocol (PCEP) so as to enable the usage of a
stateful PCE capability in supporting P2MP TE LSPs.</t>
</abstract>
</front>
<middle>
<section title="Introduction"
toc="default">
<t>As per
<xref target="RFC4655" />, the Path Computation Element (PCE)
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.</t>
<t>
<xref target="RFC4875" /> describes how to set up
point-to-multipoint (P2MP) Traffic Engineering Label Switched
Paths (TE LSPs) for use in Multiprotocol Label Switching
(MPLS) and Generalized MPLS (GMPLS) networks. The PCE has
been identified as a suitable application for the computation
of paths for P2MP TE LSPs (<xref target="RFC5671"/>).</t>
<t>The PCEP is designed as a communication protocol between
PCCs and PCEs for point-to-point (P2P) path computations and
is defined in
<xref target="RFC5440" />. The extensions of PCEP to request
path computation for P2MP TE LSPs are described in
<xref target="RFC8306" />.</t>
<!--<t>Stateful PCEs are shown to be helpful in many application
scenarios, in both MPLS and GMPLS networks, as illustrated in
<xref target='RFC8051'></xref>. These
scenarios apply equally to P2P and P2MP TE LSPs.
<xref target='RFC8231'></xref> provides the
fundamental extensions needed for stateful PCE to support
general functionality for P2P TE LSP. <xref target='RFC8281'></xref> provides
the an extensions needed for stateful PCE-initiated
P2P TE LSP.
Complementarily, this
document focuses on the extensions that are necessary in
order for the deployment of stateful PCEs to support P2MP TE
LSPs. This document describes the setup, maintenance and
teardown of PCE-initiated P2MP LSPs under the stateful PCE
model.</t>-->
<t>Stateful PCEs are shown to be helpful in many application scenarios,
in both MPLS and GMPLS networks, as illustrated in <xref target='RFC8051'></xref>. These
scenarios apply equally to P2P and P2MP TE LSPs. <xref target='RFC8231'></xref> provides
the fundamental extensions to PCEP needed for stateful PCE to support
general functionality for P2P TE LSP. <xref target='RFC8281'></xref> provides extensions
to PCEP needed for stateful PCE-initiated P2P TE LSP. This document
complements that work by focusing on PCEP extensions that are
necessary in order for the deployment of stateful PCEs to support
P2MP TE LSPs. This document describes the setup, maintenance, and
teardown of PCE-initiated P2MP LSPs under the stateful PCE model.</t>
<section title="Requirements Language"
toc="default">
<t>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 BCP 14 <xref target="RFC2119" /> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
</section>
</section>
<section title="Terminology"
toc="default">
<t>Terminology used in this document is the same as the terminology
used in
<xref target='RFC8231'></xref>,
<xref target='RFC8281'></xref>, and
<xref target="RFC8306" />.</t>
</section>
<section title="Supporting P2MP TE LSPs for Stateful PCE"
toc="default"
anchor="SEC_M">
<section title="Motivation"
toc="default">
<t>
<xref target='RFC8051'>
</xref> presents several use cases, demonstrating scenarios
that benefit from the deployment of a stateful PCE
including optimization, recovery, etc., which are equally
applicable to P2MP TE LSPs.
<xref target='RFC8231'></xref> defines the
extensions to PCEP for P2P TE LSPs. This document complements the previous work by focusing on
extensions that are necessary in order for the deployment of stateful
PCEs to support P2MP TE LSPs.</t>
<t>In addition to that, the stateful nature of a PCE
simplifies the information conveyed in PCEP messages since
it is possible to refer to the LSPs via a PCEP-specific LSP identifier (PLSP-ID)
(<xref target='RFC8231'></xref>). For P2MP, where the size of message is much larger, this is an added advantage. When using a
stateless PCE, a request to modify an existing P2MP tree requires
that all the leaves are presented in the PCEP messages along with all
the path information. But when using a stateful PCE, the PCEP
messages can use a PLSP-ID to represent all information about the LSP
that has previously been exchanged in PCEP messages, and it is only
necessary to encode the modifications (such as new or removed leaf
nodes). The PLSP-ID provides an index into the LSP-DB at the PCE,
and identifies the LSP at the PCC.</t>
<t>In environments where the P2MP TE LSPs
placement needs to change in response to application
demands, it is useful to support dynamic creation and tear
down of P2MP TE LSPs. The ability for a PCE to trigger the
creation of P2MP TE LSPs on demand can be seamlessly
integrated into a controller-based network architecture,
where intelligence in the controller can determine when and
where to set up paths. Section 3 of
<xref target='RFC8281'>
</xref> further describes the motivation behind the
PCE-Initiation capability, which is equally applicable to
P2MP TE LSPs.</t>
</section>
<section title="Objectives"
toc="default">
<t>The objectives for the protocol extensions to support
P2MP TE LSPs for stateful PCE are the same as the objectives
described in section 3.2 of
<xref target='RFC8231'></xref>.</t>
</section>
</section>
<section title="Functions to Support P2MP TE LSPs for Stateful PCEs"
toc="default">
<t>
<xref target='RFC8231'></xref> specifies new
functions to support a stateful PCE. It also specifies that a
function can be initiated either from a PCC towards a PCE
(C-E) or from a PCE towards a PCC (E-C).</t>
<t>This document extends these functions to support P2MP TE
LSPs.</t>
<t>
<list style="hanging">
<t hangText="Capability Advertisement (E-C,C-E):">both
the PCC and the PCE must announce during PCEP session
establishment that they support Stateful PCE
extensions for P2MP using mechanisms defined in
<xref target='SEC_CA'></xref>.</t>
<t hangText="LSP State Synchronization (C-E):">after the
session between the PCC and a stateful PCE with P2MP
capability is initialized, the PCE must learn the state
of a PCC's P2MP TE LSPs before it can perform path
computations or update LSP attributes in a PCC.</t>
<t hangText="LSP Update Request (E-C):">a stateful PCE
with P2MP capability requests modification of attributes
on a PCC's P2MP TE LSPs.</t>
<t hangText="LSP State Report (C-E):">a PCC sends an LSP
state report to a PCE whenever the state of a P2MP TE LSP
changes.</t>
<t hangText="LSP Control Delegation (C-E,E-C):">a PCC
grants to a PCE the right to update LSP attributes on one
or more P2MP TE LSPs; the PCE becomes the authoritative
source of the LSP's attributes as long as the delegation
is in effect (See Section 5.7 of
<xref target='RFC8231'></xref>); the
PCC may withdraw the delegation or the PCE may give up
the delegation at any time.</t>
<t hangText="PCE-initiated LSP instantiation (E-C):">a PCE
sends an LSP Initiate Message to a PCC to instantiate or
delete a P2MP TE LSP <xref target='RFC8281'></xref>.</t>
</list>
</t>
</section>
<section title="Architectural Overview of Protocol Extensions"
toc="default">
<section title="Extension of PCEP Messages"
toc="default">
<t>New PCEP messages are defined in
<xref target='RFC8231'></xref> to support
stateful PCE for P2P TE LSPs. In this document these
messages are extended to support P2MP TE LSPs.</t>
<t>
<list style="hanging">
<t hangText="Path Computation State Report (PCRpt):">
Each P2MP TE LSP State Report in a PCRpt message can
contain actual P2MP TE LSP path attributes, LSP status,
etc. An LSP State Report carried in a PCRpt message is
also used in delegation or revocation of control of a
P2MP TE LSP to/from a PCE. The extension of PCRpt
message is described in
<xref target="SEC_RPT" />.</t>
<t hangText="Path Computation Update Request (PCUpd):">
Each P2MP TE LSP Update Request in a PCUpd message MUST
contain all LSP parameters that a PCE wishes to set for
a given P2MP TE LSP. An LSP Update Request carried in a
PCUpd message is also used to return LSP delegations if
at any point PCE no longer desires control of a P2MP TE
LSP. The PCUpd message is described in
<xref target="SEC_UPD" />.</t>
</list>
</t>
<t>A PCEP message is defined in
<xref target='RFC8281'></xref> to support
stateful PCE instantiation of P2P TE LSPs. In this document this
message is extended to support P2MP TE LSPs.</t>
<t>
<list style="hanging">
<t hangText="Path Computation LSP Initiate Message (PCInitiate):">
PCInitiate is a PCEP message sent by a PCE to a PCC to trigger P2MP TE LSPs
instantiation or deletion. The PCInitiate message is described in
<xref target="SEC_PCINIT" />.
</t>
</list>
</t>
<t>The Path Computation Request (PCReq) and Path Computation Reply (PCRep)
messages are also extended to support passive stateful PCE for P2P TE LSP in
<xref target='RFC8231'></xref>. In this document these
messages are extended to support P2MP TE LSPs as well.</t>
</section>
<section title="Capability Advertisement"
toc="default"
anchor="SEC_CA">
<t>During PCEP Initialization Phase, as per Section 7.1.1
of
<xref target='RFC8231'></xref>, PCEP
speakers advertise Stateful capability via the STATEFUL-PCE-CAPABILITY TLV in the OPEN object.
Various flags are defined for the STATEFUL-PCE-CAPABILITY TLV
defined in <xref target='RFC8231'></xref> and
updated in <xref target='RFC8281'></xref>
and <xref target='RFC8232'></xref>.
</t>
<t>Three new flags N (P2MP-CAPABILITY), M (P2MP-LSP-UPDATE-CAPABILITY), and
P (P2MP-LSP-INSTANTIATION-CAPABILITY)
are added in this document:</t>
<t>
<list style="hanging">
<t hangText="N (P2MP-CAPABILITY flag - 1 bit):">if
set to 1 by a PCC, the N Flag
indicates that the PCC is willing to send P2MP LSP State Reports whenever
any parameters or operational status change of the P2MP LSP; if
set to 1 by a PCE, the N Flag indicates that the PCE is interested
in receiving LSP State Reports whenever there is any parameters or
operational status change of the P2MP LSP. The P2MP-CAPABILITY Flag MUST be
advertised by both a PCC and a PCE for PCRpt messages P2MP extension to be
allowed on a PCEP session.</t>
<t hangText="M (P2MP-LSP-UPDATE-CAPABILITY flag - 1 bit):">if
set to 1 by a PCC, the M Flag
indicates that the PCC allows modification of P2MP LSP parameters; if
set to 1 by a PCE, the M Flag indicates that the PCE is capable of
updating P2MP LSP parameters. The P2MP-LSP-UPDATE-CAPABILITY Flag MUST be
advertised by both a PCC and a PCE for PCUpd messages P2MP extension to be
allowed on a PCEP session.</t>
<t hangText="P (P2MP-LSP-INSTANTIATION-CAPABILITY flag - 1 bit):">
If set to 1 by a PCC, the P Flag indicates that the PCC
allows instantiation of a P2MP LSP by a PCE. If
set to 1
by a PCE, the P flag indicates that the PCE supports
P2MP LSP instantiation. The P2MP-LSP-INSTANTIATION-CAPABILITY
flag MUST be set by both PCC and PCE in order to support
PCE-initiated P2MP LSP instantiation.</t>
</list>
</t>
<t>A PCEP speaker should continue to advertise the basic P2MP
capability via mechanisms as described in
<xref target="RFC8306"/>.</t>
</section>
<section title="IGP Extensions for Stateful PCE P2MP Capabilities Advertisement"
toc="default">
<t>
When PCC is a Label Switching Router (LSR), participating in the IGP (OSPF or IS-IS), and PCEs
are either LSRs or servers also participating in the IGP, an
effective mechanism for PCE discovery within an IGP routing domain
consists of utilizing IGP advertisements. Extensions for the
advertisement of PCE Discovery Information are defined for OSPF and
for IS-IS in <xref target="RFC5088"/> and <xref target="RFC5089"/> respectively.</t>
<t>The PCE-CAP-FLAGS sub-TLV, defined in <xref target="RFC5089"/>, is an optional sub-
TLV used to advertise PCE capabilities. It MAY be present within the
PCE Discovery (PCED) TLV carried by OSPF or IS-IS. <xref target="RFC5088"/> and <xref target="RFC5089"/>
provide the description and processing rules for this sub-TLV when
carried within OSPF and IS-IS, respectively.</t>
<t>The format of the PCE-CAP-FLAGS sub-TLV is included below for easy
reference: </t>
<t>Type: 5 </t>
<t>Length: Multiple of 4. </t>
<t>Value: This contains an array of units of 32 bit flags with the most
significant bit as 0. Each bit represents one PCE capability. </t>
<t>PCE capability bit flags are defined in <xref target="RFC5088"/>. This document defines
new capability bits (early allocated by IANA) for the stateful PCE with P2MP as follows:</t>
<figure>
<artwork align="center">
Bit Capability
13 Active Stateful PCE with P2MP
14 Passive Stateful PCE with P2MP
15 PCE-Initiation with P2MP
</artwork>
</figure>
<t>Note that while active, passive or initiation stateful PCE with P2MP capabilities may be
advertised during discovery, PCEP Speakers that wish to use stateful
PCEP MUST advertise stateful PCEP capabilities during PCEP session
setup, as specified in the current document. A PCC MAY initiate
stateful PCEP P2MP capability advertisement at PCEP session setup even if it
did not receive any IGP PCE capability advertisements.</t>
</section>
<section title="State Synchronization"
toc="default">
<t>State Synchronization operations (described in Section
5.6 of
<xref target='RFC8231'></xref>) are
applicable for the P2MP TE LSPs as well. The optimizations
described in <xref target='RFC8232'></xref>
can also be applied for P2MP TE LSPs.</t>
</section>
<section title="LSP Delegation"
toc="default">
<t>LSP delegation operations (described in Section 5.7 of
<xref target='RFC8231'></xref>) are
applicable for P2MP TE LSPs as well.</t>
</section>
<section title="LSP Operations"
toc="default">
<section title="Passive Stateful PCE"
toc="default">
<t>LSP operations for passive stateful PCE (described in
Section 5.8.1 of
<xref target='RFC8231'></xref>) are
applicable for P2MP TE LSPs as well.</t>
<t>The PCReq and PCRep message
format for P2MP TE LSPs is described in Section 3.4 and
Section 3.5 of <xref target="RFC8306"/> respectively.</t>
<t>The PCReq and PCRep message for P2MP TE LSPs are
extended to support encoding of LSP object, so that it is
possible to refer to an LSP with a unique identifier and
simplify the PCEP message exchange. For example, in case of
modification of one leaf in a P2MP tree, there should be
no need to carry the full P2MP tree in PCReq
message.</t>
<t>The extension for the Request and Response message for
passive stateful operations on P2MP TE LSPs are described
in <xref target='SEC_REQ'></xref> and
<xref target='SEC_REP'></xref>. The extension for the
Path Computation LSP State Report (PCRpt) message is
described in <xref target='SEC_RPT'></xref>.</t>
</section>
<section title="Active Stateful PCE"
toc="default">
<t>LSP operations for active stateful PCE (described in
Section 5.8.2 of
<xref target='RFC8231'></xref>) are
applicable for P2MP TE LSPs as well.</t>
<t>The extension for the Path Computation LSP Update
(PCUpd) message for
active stateful operations on P2MP TE LSPs are described
in <xref target='SEC_UPD'></xref>.</t>
</section>
<section title="PCE-Initiated LSP"
toc="default">
<t>As per section 5.1 of
<xref target='RFC8281'></xref>, the
PCE sends a Path Computation LSP Initiate Request
(PCInitiate) message to the PCC to suggest instantiation or
deletion of a
P2P TE LSP. This document extends the PCInitiate message to
support P2MP TE LSPs (see details in
<xref target="SEC_PCINIT" />).</t>
<t>The P2MP TE LSPs suggested instantiation and deletion operations are
same as for P2P LSP as described in section 5.3
and 5.4 of
<xref target='RFC8281'></xref>. </t>
<section title="P2MP TE LSPs Instantiation"
toc="default"
anchor="SEC_INST">
<t>The Instantiation operation of P2MP TE LSPs is same as
defined in section 5.3 of
<xref target='RFC8281'></xref>
including handling of PLSP-ID, SYMBOLIC-PATH-NAME TLV etc.
Rules of processing and error codes remains unchanged.
The N (P2MP)
flag (<xref target="LSP"/>) MUST be set in LSP object in PCInitiate message by PCE
to specify the instantiation is for P2MP TE LSPs. Like the PLSP-ID
as per <xref target='RFC8281'></xref>, the
P2MP-LSP-IDENTIFIERS TLV SHOULD NOT be included in the LSP object in
PCIntiitate message (as
it is generated by PCC and carried in PCRpt message instead) and
MUST be ignored on receipt. </t>
</section>
<section title="P2MP TE LSPs Deletion"
toc="default">
<t>The deletion operation of P2MP TE LSPs is same as defined
in section 5.4 of
<xref target='RFC8281'></xref> by
sending an LSP Initiate Message with an LSP object carrying
the PLSP-ID of the LSP to be removed and an SRP object with
the R flag set (LSP-REMOVE as per section 5.2 of
<xref target='RFC8281'></xref>).
Rules of processing and error codes remains unchanged.</t>
</section>
<section title="Adding and Pruning Leaves for the P2MP TE LSP"
toc="default">
<t>Adding of new leaves and Pruning of old Leaves for
the PCE initiated P2MP TE LSP MUST be carried in PCUpd message
as per <xref target='SEC_UPD'></xref>
for P2MP TE LSP extensions.
As defined in <xref target='RFC8306'></xref>, leaf type = 1 for
adding of new leaves, leaf type = 2 for pruning of old leaves of
P2MP END-POINTS Object are used in PCUpd message.</t>
<t>PCC MAY use the Incremental State Update mechanism as described
in <xref target='RFC4875'></xref> to signal adding and pruning
of leaves.</t>
<t>Section 3.10 of <xref target='RFC8306'></xref> defines the error-handling procedures when adding new leaves to or removing old leaves from the existing
P2MP tree for PCReq message. The same error handling and error-codes are also applicable to the stateful PCE messages as described in this document.</t>
</section>
<section title="P2MP TE LSPs Delegation and Cleanup"
toc="default">
<t>P2MP TE LSPs delegation and cleanup operations are same
as defined in section 6 of
<xref target='RFC8281'></xref>.
Rules of processing and error codes remains unchanged.</t>
</section>
</section>
</section>
</section>
<section title="PCEP Message Extensions"
toc="default">
<t>Message formats in this section, as those in <xref target='RFC8231'></xref>, <xref target='RFC8281'></xref>, and <xref target='RFC5440'></xref>, are presented
using Routing Backus-Naur Format (RBNF) as specified in <xref target='RFC5511'></xref>.</t>
<section title="The PCRpt Message"
toc="default"
anchor="SEC_RPT">
<t>As per Section 6.1 of
<xref target='RFC8231'></xref>, PCRpt
message is used to report the current state of a P2P TE
LSP. This document extends the PCRpt message in reporting
the status of P2MP TE LSPs.</t>
<t>The format of PCRpt message is as follows:</t>
<figure align="left"
alt=""
height=""
suppress-title="true"
title=""
width=""
anchor="SEC_FIG4">
<artwork align="left"
alt=""
height=""
name=""
type=""
width=""
xml:space="preserve">
<PCRpt Message> ::= <Common Header>
<state-report-list>
Where:
<state-report-list> ::= <state-report>
[<state-report-list>]
<state-report> ::= [<SRP>]
<LSP>
<end-point-intended-path-pair-list>
[<actual-attribute-list>
<end-point-actual-path-pair-list>]
[<intended-attribute-list>]
Where:
<end-point-intended-path-pair-list>::=
[<END-POINTS>]
[<S2LS>]
<intended-path>
[<end-point-intended-path-pair-list>]
<end-point-actual-path-pair-list>::=
[<END-POINTS>]
[<S2LS>]
<actual-path>
[<end-point-actual-path-pair-list>]
<intended-path> ::= (<ERO>|<SERO>)
[<intended-path>]
<actual-path> ::= (<RRO>|<SRRO>)
[<actual-path>]
<intended-attribute-list> is defined in [RFC5440] and
extended by PCEP extensions.
<actual-attribute-list> consists of the actual computed and
signaled values of the <BANDWIDTH> and <metric-lists>
objects defined in [RFC5440].
</artwork>
</figure>
<t>The P2MP END-POINTS object defined in
<xref target="RFC8306"/> is mandatory for specifying
address of P2MP leaves grouped based on leaf types.</t>
<t>
<list style="symbols">
<t>New leaves to add (leaf type = 1)</t>
<t>Old leaves to remove (leaf type = 2)</t>
<t>Old leaves whose path can be modified/reoptimized (leaf type = 3)</t>
<t>Old leaves whose path must be left unchanged (leaf type = 4)</t>
</list>
</t>
<t>When reporting the status of a P2MP TE LSP, the
destinations MUST be grouped in END-POINTS object based on the operational status (O
field in S2LS object) and leaf type (in END-POINTS).
This way, leaves of the same type that share the same operational status are grouped together.
For reporting the status of delegated P2MP TE LSPs leaf-type = 3 is used, whereas for non-delegated
P2MP TE LSPs, leaf-type = 4 is used.</t>
<t>For a delegated P2MP TE LSP configuration changes are reported via PCRpt message. For example,
adding of new leaves END-POINTS (leaf-type = 1) is used where as removing of old leaves (leaf-type = 2) is used. </t>
<t>Note that the compatibility with the
<xref target='RFC8231'></xref> definition
of <state-report> is preserved. At least one instance of
<END-POINTS> MUST be present in this message for P2MP LSP.</t>
<t>Note that the ordering of <end-point-intended-path-pair-list>, <actual-attribute-list>, <end-point-actual-path-pair-list>, and <intended-attribute-list> is done to retain compatibility with state reports for the P2P LSPs as per <xref target='RFC8231'></xref>.</t>
<t>During state synchronization, the PCRpt message reports the status of the full P2MP tree.</t>
<t>The S2LS object MUST be carried in PCRpt
message along with END-POINTS object when N (P2MP) flag is set in
LSP object for P2MP TE LSPs. If the S2LS object is missing, the receiving
PCE MUST send a PCErr message with Error-type=6 ("Mandatory Object
missing") and Error-value=13 (early allocated by IANA) ("S2LS object missing"). If the
END-POINTS object is missing, the receiving
PCE MUST send a PCErr message with Error-type=6 ("Mandatory Object
missing") and Error-value=3 ("END-POINTS object missing") (defined
in <xref target='RFC5440'></xref>.</t>
<t>The S2LS object could be used in conjunction with the intended-path (ERO) as well as the actual-path (RRO); for the same leaf, the state encoded in the S2LS object associated with the actual-path MUST be used over the intended-path.</t>
<t>If the E-bit (ERO-Compress bit) was set to 1 in the report, then the
path will be formed by an ERO followed by a list of SEROs or RRO followed by a list of SRROs.</t>
</section>
<section title="The PCUpd Message"
toc="default"
anchor="SEC_UPD">
<t>As per Section 6.2 of
<xref target='RFC8231'></xref>, PCUpd
message is used to update P2P TE LSP attributes. This
document extends the PCUpd message in updating the
attributes of a P2MP TE LSP.</t>
<t>The format of a PCUpd message is as follows:</t>
<figure align="left"
alt=""
height=""
suppress-title="true"
title=""
width=""
anchor="SEC_FIG5">
<artwork align="left"
alt=""
height=""
name=""
type=""
width=""
xml:space="preserve">
<PCUpd Message> ::= <Common Header>
<update-request-list>
Where:
<update-request-list> ::= <update-request>
[<update-request-list>]
<update-request> ::= <SRP>
<LSP>
<end-point-path-pair-list>
<attribute-list>
Where:
<end-point-path-pair-list>::=
[<END-POINTS>]
<intended-path>
[<end-point-path-pair-list>]
<intended-path> ::= (<ERO>|<SERO>)
[<intended-path>]
<attribute-list> is defined in [RFC5440] and
extended by PCEP extensions.
</artwork>
</figure>
<t>Note that the compatibility with the
<xref target='RFC8231'></xref> definition
of <update-request> is preserved.</t>
<t>The PCC SHOULD use the make-before-break or sub-group-based
procedures described in <xref target='RFC4875'></xref> based
on a local policy decision.</t>
<t>The END-POINTS object MUST be carried in PCUpd
message when N flag is set in
LSP object for a P2MP TE LSP. If the
END-POINTS object is missing, the receiving
PCC MUST send a PCErr message with Error-type=6 ("Mandatory Object
missing") and Error-value=3 ("END-POINTS object missing") (defined
in <xref target='RFC5440'></xref>).</t>
</section>
<section title="The PCReq Message"
toc="default"
anchor="SEC_REQ">
<t>As per Section 3.4 of
<xref target='RFC8306'></xref>, PCReq
message is used for a P2MP Path Computation Request.
This document extends the PCReq message such that a PCC MAY
include the LSP object in the PCReq message if the stateful PCE
P2MP capability has been negotiated on a PCEP session between
the PCC and a PCE.</t>
<t>The format of PCReq message is as follows:</t>
<figure align="left"
alt=""
height=""
suppress-title="true"
title=""
width=""
anchor="SEC_FIG6">
<artwork align="left"
alt=""
height=""
name=""
type=""
width=""
xml:space="preserve">
<![CDATA[
<PCReq Message>::= <Common Header>
[<svec-list>]
<request-list>
where:
<svec-list>::= <SVEC>
[<OF>]
[<metric-list>]
[<svec-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<end-point-rro-pair-list>
[<LSP>]
[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>|<BNC>]
[<LOAD-BALANCING>]
<end-point-rro-pair-list>::= <END-POINTS>
[<RRO-List>[<BANDWIDTH>]]
[<end-point-rro-pair-list>]
<RRO-List>::=(<RRO>|<SRRO>)[<RRO-List>]
<metric-list>::=<METRIC>[<metric-list>]
]]>
</artwork>
</figure>
</section>
<section title="The PCRep Message"
toc="default"
anchor="SEC_REP">
<t>As per Section 3.5 of
<xref target='RFC8306'></xref>, PCRep
message is used for a P2MP Path Computation Reply.
This document extends the PCRep message such that a PCE MAY
include the LSP object in the PCRep message if the stateful PCE
P2MP capability has been negotiated on a PCEP session between
the PCC and a PCE.</t>
<t>The format of PCRep message is as follows:</t>
<t><figure align="left"
alt=""
height=""
suppress-title="true"
title=""
width=""
anchor="SEC_FIG7">
<artwork align="left"
alt=""
height=""
name=""
type=""
width=""
xml:space="preserve">
<![CDATA[
<PCRep Message>::= <Common Header>
<response-list>
where:
<response-list>::=<response>[<response-list>]
<response>::=<RP>
[<end-point-path-pair-list>]
[<LSP>]
[<NO-PATH>]
[<UNREACH-DESTINATION>]
[<attribute-list>]
<end-point-path-pair-list>::= [<END-POINTS>]
<path>
[<end-point-path-pair-list>]
<path> ::= (<ERO>|<SERO>) [<path>]
<attribute-list>::=[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
]]>
</artwork>
</figure> </t>
</section>
<section title="The PCInitiate message"
toc="default"
anchor="SEC_PCINIT">
<t>As defined in section 5.1 of
<xref target='RFC8281'></xref>, PCE
sends a PCInitiate message to a PCC to recommend instantiation
of a P2P TE
LSP. This document extends the format of PCInitiate message
for the creation of P2MP TE LSPs but the creation and
deletion operations of P2MP TE LSPs are same to the P2P TE
LSPs.</t>
<t>The format of PCInitiate message is as follows:</t>
<figure align="left"
alt=""
height=""
suppress-title="true"
title=""
width=""
anchor="SEC_FIG8">
<artwork align="left"
alt=""
height=""
name=""
type=""
width=""
xml:space="preserve">
<PCInitiate Message> ::= <Common Header>
<PCE-initiated-lsp-list>
Where:
<PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request>
[<PCE-initiated-lsp-list>]
<PCE-initiated-lsp-request> ::=
(<PCE-initiated-lsp-instantiation>|<PCE-initiated-lsp-deletion>)
<PCE-initiated-lsp-instantiation> ::= <SRP>
<LSP>
<end-point-path-pair-list>
[<attribute-list>]
<PCE-initiated-lsp-deletion> ::= <SRP>
<LSP>
Where:
<end-point-path-pair-list>::=
[<END-POINTS>]
<intended-path>
[<end-point-path-pair-list>]
<intended-path> ::= (<ERO>|<SERO>)
[<intended-path>]
<attribute-list> is defined in [RFC5440] and extended
by PCEP extensions.
</artwork>
</figure>
<t>The PCInitiate message with an LSP object with N flag
(P2MP) set is used to convey operation on a P2MP TE LSP.
The SRP object is used to correlate between initiation
requests sent by the PCE and the error reports and state
reports sent by the PCC as described in
<xref target='RFC8231'></xref>.</t>
<t>The END-POINTS object MUST be carried in PCInitiate
message when N flag is set in
LSP object for a P2MP TE LSP. If the
END-POINTS object is missing, the receiving
PCC MUST send a PCErr message with Error-type=6 ("Mandatory Object
missing") and Error-value=3 ("END-POINTS object missing") (defined
in <xref target='RFC5440'></xref>).</t>
</section>
<section title="Example"
toc="default">
<section title="P2MP TE LSPs Update Request"
toc="default">
<t>An LSP Update Request message is sent by an active
stateful PCE to update the P2MP TE LSPs parameters or
attributes. An example of a PCUpd message for P2MP TE LSPs
is described below:</t>
<figure align="left"
alt=""
height=""
suppress-title="true"
title=""
width="">
<artwork align="left"
alt=""
height=""
name=""
type=""
width=""
xml:space="preserve">
Common Header
SRP
LSP with P2MP flag set
END-POINTS for leaf type 3
ERO list
</artwork>
</figure>
<t>In this example, a stateful PCE requests an update of the
path taken to some of the leaves in a P2MP tree. The
update request uses the END-POINT type 3
(modified/reoptimized). The ERO list represents the source to leaves
path after modification. The update message does not need
to encode the full P2MP tree in this case.</t>
</section>
<section title="P2MP TE LSP Report"
toc="default">
<t>The LSP State Report message is sent by a PCC to report or
delegate the P2MP TE LSPs. An example of a PCRpt message
for a delegated P2MP TE LSPs is described below to add new leaves to
an existing P2MP TE LSP:</t>
<figure align="left"
alt=""
height=""
suppress-title="true"
title=""
width="">
<artwork align="left"
alt=""
height=""
name=""
type=""
width=""
xml:space="preserve">
Common Header
LSP with P2MP flag set
END-POINTS for leaf type 1
S2LS (O=DOWN)
ERO list (empty)
</artwork>
</figure>
<t>An example of a PCRpt message for a P2MP TE LSP is
described below to prune leaves from an existing P2MP TE
LSP:</t>
<figure align="left"
alt=""
height=""
suppress-title="true"
title=""
width="">
<artwork align="left"
alt=""
height=""
name=""
type=""
width=""
xml:space="preserve">
Common Header
LSP with P2MP flag set
END-POINTS for leaf type 2
S2LS (O=UP)
ERO list (empty)
</artwork>
</figure>
<t>An example of a PCRpt message for a delegated P2MP TE LSP is
described below to report status of leaves in an
existing P2MP TE LSP:</t>
<figure align="left"
alt=""
height=""
suppress-title="true"
title=""
width="">
<artwork align="left"
alt=""
height=""
name=""
type=""
width=""
xml:space="preserve">
Common Header
SRP
LSP with P2MP flag set
END-POINTS for leaf type 3
S2LS (O=UP)
RRO list
END-POINTS for leaf type 3
S2LS (O=DOWN)