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
|
<pre>Internet Engineering Task Force (IETF) S. Yasukawa
Request for Comments: 5862 NTT Corporation
Category: Informational A. Farrel
ISSN: 2070-1721 Old Dog Consulting
June 2010
<span class="h1">Path Computation Clients (PCC) - Path Computation Element (PCE)</span>
<span class="h1">Requirements for Point-to-Multipoint MPLS-TE</span>
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.
Extensions to the MPLS and GMPLS signaling and routing protocols have
been made in support of point-to-multipoint (P2MP) Traffic Engineered
(TE) Label Switched Paths (LSPs). The use of PCE in MPLS networks is
already established, and since P2MP TE LSP routes are sometimes
complex to compute, it is likely that PCE will be used for P2MP LSPs.
Generic requirements for a communication protocol between Path
Computation Clients (PCCs) and PCEs are presented in <a href="./rfc4657">RFC 4657</a>, "Path
Computation Element (PCE) Communication Protocol Generic
Requirements". This document complements the generic requirements
and presents a detailed set of PCC-PCE communication protocol
requirements for point-to-multipoint MPLS/GMPLS traffic engineering.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc5862">http://www.rfc-editor.org/info/rfc5862</a>.
<span class="grey">Yasukawa & Farrel Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5862">RFC 5862</a> PCC-PCE and P2MP MPLS-TE June 2010</span>
Copyright Notice
Copyright (c) 2010 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="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
<span class="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. The intention
is that the PCE is used to compute the path of Traffic Engineered
Label Switched Paths (TE LSPs) within Multiprotocol Label Switching
(MPLS) and Generalized MPLS (GMPLS) networks.
Requirements for point-to-multipoint (P2MP) MPLS TE LSPs are
documented in [<a href="./rfc4461" title=""Signaling Requirements for Point-to- Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)"">RFC4461</a>], and signaling protocol extensions for
setting up P2MP MPLS TE LSPs are defined in [<a href="./rfc4875" title=""Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)"">RFC4875</a>]. P2MP MPLS TE
networks are considered in support of various features, including
layer 3 multicast virtual private networks [<a href="./rfc4834" title=""Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)"">RFC4834</a>].
Path computation for P2MP TE LSPs presents a significant challenge,
and network optimization of multiple P2MP TE LSPs requires
considerable computational resources. PCE offers a way to offload
such path computations from Label Switching Routers (LSRs).
The applicability of the PCE-based path computation architecture to
P2MP MPLS TE is described in a companion document [<a href="./rfc5671" title=""Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE)"">RFC5671</a>]. No
further attempt is made to justify the use of PCE for P2MP MPLS TE
within this document.
This document presents a set of PCC-PCE communication protocol
(PCECP) requirements for P2MP MPLS traffic engineering. It
supplements the generic requirements documented in [<a href="./rfc4657" title=""Path Computation Element (PCE) Communication Protocol Generic Requirements"">RFC4657</a>].
<span class="grey">Yasukawa & Farrel Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5862">RFC 5862</a> PCC-PCE and P2MP MPLS-TE June 2010</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Conventions Used in This Document</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
Although this document is not a protocol specification, this
convention is adopted for clarity of description of requirements.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. PCC-PCE Communication Requirements for P2MP MPLS Traffic Engineering</span>
This section sets out additional requirements specific to P2MP MPLS
TE that are not covered in [<a href="./rfc4657" title=""Path Computation Element (PCE) Communication Protocol Generic Requirements"">RFC4657</a>].
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. PCC-PCE Communication</span>
The PCC-PCE communication protocol MUST allow requests and replies
for the computation of paths for P2MP LSPs.
This requires no additional messages, but requires the addition of
the parameters described in the following sections to the existing
PCC-PCE communication protocol messages.
<span class="h4"><a class="selflink" id="section-3.1.1" href="#section-3.1.1">3.1.1</a>. Indication of P2MP Path Computation Request</span>
R1: Although the presence of certain parameters (such as a list of
more than one destination) MAY be used by a protocol
specification to allow an implementation to infer that a Path
Computation Request is for a P2MP LSP, an explicit parameter
SHOULD be placed in a conspicuous place within a Path
Computation Request message to allow a receiving PCE to easily
identify that the request is for a P2MP path.
<span class="h4"><a class="selflink" id="section-3.1.2" href="#section-3.1.2">3.1.2</a>. Indication of P2MP Objective Functions</span>
R2: [<a href="./rfc4657" title=""Path Computation Element (PCE) Communication Protocol Generic Requirements"">RFC4657</a>] includes the requirement to be able to specify the
objective functions to be applied by a PCE during path
computation.
This document makes no change to that requirement, but it should
be noted that new and different objective functions will be used
for P2MP computation. Definitions for core objective functions
can be found in [<a href="./rfc5541" title=""Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"">RFC5541</a>] together with usage procedures. New
objective functions for use with P2MP path computations will
need to be defined and allocated codepoints in a separate
document.
<span class="grey">Yasukawa & Farrel Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5862">RFC 5862</a> PCC-PCE and P2MP MPLS-TE June 2010</span>
<span class="h4"><a class="selflink" id="section-3.1.3" href="#section-3.1.3">3.1.3</a>. Non-Support of P2MP Path Computation</span>
R3: PCEs are not required to support P2MP path computation.
Therefore, it MUST be possible for a PCE to reject a P2MP Path
Computation Request message with a reason code that indicates no
support for P2MP path computation.
<span class="h4"><a class="selflink" id="section-3.1.4" href="#section-3.1.4">3.1.4</a>. Non-Support by Back-Level PCE Implementations</span>
It is possible that initial PCE implementations will be developed
without support for P2MP path computation and without the ability to
recognize the explicit parameter described in <a href="#section-3.1.1">Section 3.1.1</a>. Such
legacy implementations will not be able to make use of the new reason
code described in <a href="#section-3.1.3">Section 3.1.3</a>.
R4: Therefore, at least one parameter required for inclusion in a
P2MP Path Computation Request message MUST be defined in such a
way as to cause automatic rejection as unprocessable or
unrecognized by a back-level PCE implementation without
requiring any changes to that PCE. It is RECOMMENDED that the
parameter that causes this result be the parameter described in
<a href="#section-3.1.1">Section 3.1.1</a>.
<span class="h4"><a class="selflink" id="section-3.1.5" href="#section-3.1.5">3.1.5</a>. Specification of Destinations</span>
R5: Since P2MP LSPs have more than one destination, it MUST be
possible for a single Path Computation Request to list multiple
destinations.
<span class="h4"><a class="selflink" id="section-3.1.6" href="#section-3.1.6">3.1.6</a>. Indication of P2MP Paths</span>
R6: The Path Computation Response MUST be able to carry the path of
a P2MP LSP.
P2MP paths can be expressed as a compressed series of routes as
described in [<a href="./rfc4875" title=""Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)"">RFC4875</a>]. The Path Computation Response MUST be able
to carry the P2MP path as either a compressed path (but not
necessarily using the identical encoding as described in [<a href="./rfc4875" title=""Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)"">RFC4875</a>]),
or as a non-compressed path comprising a series of source-to-leaf
point-to-point (P2P) paths (known as S2L sub-paths).
R7: By default, the path returned by the PCE SHOULD use the
compressed format.
The request from the PCC MAY allow the PCC to express a
preference for receiving a compressed or non-compressed P2MP
path in the response.
<span class="grey">Yasukawa & Farrel Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5862">RFC 5862</a> PCC-PCE and P2MP MPLS-TE June 2010</span>
<span class="h4"><a class="selflink" id="section-3.1.7" href="#section-3.1.7">3.1.7</a>. Multi-Message Requests and Responses</span>
R8: A single P2MP LSP may have many destinations, and the computed
path (tree) may be very extensive. In these cases, it is
possible that the entire Path Computation Request or Response
cannot fit within one PCE message. Therefore, it MUST be
possible for a single request or response to be conveyed by a
sequence of PCE messages.
Note that there is a requirement in [<a href="./rfc4657" title=""Path Computation Element (PCE) Communication Protocol Generic Requirements"">RFC4657</a>] for reliable and
in-order message delivery, so it is assumed that components of the
sequence will be delivered in order and without missing components.
<span class="h4"><a class="selflink" id="section-3.1.8" href="#section-3.1.8">3.1.8</a>. Non-Specification of Per-Destination Constraints and Parameters</span>
[<a id="ref-RFC4875">RFC4875</a>] requires that all branches of a single P2MP LSP have the
same characteristics, and achieves this by not allowing the signaling
parameters to be varied for different branches of the same P2MP LSP.
R9: It MUST NOT be possible to set different constraints, traffic
parameters, or quality-of-service requirements for different
destinations of a P2MP LSP within a single computation request.
<span class="h4"><a class="selflink" id="section-3.1.9" href="#section-3.1.9">3.1.9</a>. Path Modification and Path Diversity</span>
R10: No changes are made to the requirement to support path
modification and path diversity as described in [<a href="./rfc4657" title=""Path Computation Element (PCE) Communication Protocol Generic Requirements"">RFC4657</a>].
Note, however, that a consequence of this requirement is that it
MUST be possible to supply an existing path in a Path
Computation Request. This requirement is unchanged from
[<a href="./rfc4657" title=""Path Computation Element (PCE) Communication Protocol Generic Requirements"">RFC4657</a>], but it is a new requirement that such paths MUST be
able to be P2MP paths. The PCC MUST be able to supply these
paths as compressed paths or as non-compressed paths (see
<a href="#section-3.1.6">Section 3.1.6</a>) according to the preference of the PCC.
<span class="h4"><a class="selflink" id="section-3.1.10" href="#section-3.1.10">3.1.10</a>. Reoptimization of P2MP TE LSPs</span>
R11: Reoptimization MUST be supported for P2MP TE LSPs as described
for P2P LSPs in [<a href="./rfc4657" title=""Path Computation Element (PCE) Communication Protocol Generic Requirements"">RFC4657</a>]. To support this, the existing path
MUST be supplied as described in <a href="#section-3.1.9">Section 3.1.9</a>.
Because P2MP LSPs are more complex, it is often the case that
small optimization improvements can be made after changes in
network resource availability. However, re-signaling any LSP
introduces risks to the stability of the service provided to the
customer and the stability of the network, even when techniques
like make-before-break [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>] are used. Therefore, a P2MP
Path Computation Request SHOULD contain a parameter that allows
<span class="grey">Yasukawa & Farrel Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5862">RFC 5862</a> PCC-PCE and P2MP MPLS-TE June 2010</span>
the PCC to express a cost-benefit reoptimization threshold for
the whole LSP, as well as per destination. The setting of this
parameter is subject to local policy at the PCC and SHOULD be
subject to policy at the PCE [<a href="./rfc5394" title=""Policy-Enabled Path Computation Framework"">RFC5394</a>].
Path reoptimization responses SHOULD indicate which of the
routes (as supplied according to <a href="#section-3.1.6">Section 3.1.6</a>) have been
modified from the paths supplied in the request.
<span class="h4"><a class="selflink" id="section-3.1.11" href="#section-3.1.11">3.1.11</a>. Addition and Removal of Destinations from Existing Paths</span>
A variation of path modification described in <a href="#section-3.1.9">Section 3.1.9</a> is that
destinations may be added to, or removed from, existing P2MP TE LSPs.
In the case of the addition of one or more destinations, it is
necessary to compute a path for a new branch of the P2MP LSP. It may
be desirable to recompute the whole P2MP tree, to add the new branch
as a simple spur from the existing tree, or to recompute part of the
P2MP tree.
R12: To support this function for leaf additions, it MUST be possible
to make the following indications in a Path Computation Request:
- The path of an existing P2MP LSP (as described in
<a href="#section-3.1.9">Section 3.1.9</a>).
- Which destinations are new additions to the tree.
- Which destinations of the existing tree must not have their
paths modified.
It MAY also be possible to indicate in a Path Computation
Request a cost-benefit reoptimization threshold, such that the
addition of new leaves will not cause reoptimization of the
existing P2MP tree unless a certain improvement is made over
simply grafting the new leaves to the existing tree. (Compare
with <a href="#section-3.1.10">Section 3.1.10</a>.)
In the case of the deletion of one or more destinations, it is
not necessary to compute a new path for the P2MP TE LSP, but
such a computation may yield optimizations over a simple pruning
of the tree. The recomputation function in this case is
essentially the same as that described in <a href="#section-3.1.10">Section 3.1.10</a>, but
note that it MAY be possible to supply the full previous path of
the entire P2MP TE LSP (that is, before the deletion of the
destinations) in the Path Computation Request.
<span class="grey">Yasukawa & Farrel Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5862">RFC 5862</a> PCC-PCE and P2MP MPLS-TE June 2010</span>
For both addition and deletion of destinations, the Path
Computation Response SHOULD indicate which of the routes (as
supplied according to <a href="#section-3.1.6">Section 3.1.6</a>) have been modified from the
paths supplied in the Path Computation Request, as described in
<a href="#section-3.1.10">Section 3.1.10</a>.
Note that the selection of all of these options is subject to
local policy at the PCC and SHOULD be subject to policy at the
PCE [<a href="./rfc5394" title=""Policy-Enabled Path Computation Framework"">RFC5394</a>].
<span class="h4"><a class="selflink" id="section-3.1.12" href="#section-3.1.12">3.1.12</a>. Specification of Applicable Branch Nodes</span>
For administrative or security reasons, or for other policy reasons,
it may be desirable to limit the set of nodes within the network that
may be used as branch points for a given LSP, i.e., to provide to the
path computation a limiting set of nodes that can be used as branches
for a P2MP path computation, or to provide a list of nodes that must
not be used as branch points.
R13: The PCC MUST be able to specify in a Path Computation Request a
list of nodes that constitutes a limiting superset of the branch
nodes for a P2MP path computation.
A PCC MUST be able to specify in a Path Computation Request a
list of nodes that must not be used as branch nodes for a P2MP
path computation.
<span class="h4"><a class="selflink" id="section-3.1.13" href="#section-3.1.13">3.1.13</a>. Capabilities Exchange</span>
PCE capabilities exchange forms part of PCE discovery [<a href="./rfc4674" title=""Requirements for Path Computation Element (PCE) Discovery"">RFC4674</a>], but
may also be included in the PCECP message exchanges [<a href="./rfc4657" title=""Path Computation Element (PCE) Communication Protocol Generic Requirements"">RFC4657</a>].
R14: The ability to perform P2MP path computation and the objective
functions supported by a PCE SHOULD be advertised as part of PCE
discovery. In the event that the PCE's ability to perform P2MP
computation is not advertised as part of PCE discovery, the
PCECP MUST allow a PCC to discover which PCEs with which it
communicates support P2MP path computation, and which objective
functions specific to P2MP path computation are supported by
each PCE.
The list of objective functions is assumed to be coordinated with
those that can be requested as described in <a href="#section-3.1.2">Section 3.1.2</a>.
These requirements do not represent a change to [<a href="./rfc4657" title=""Path Computation Element (PCE) Communication Protocol Generic Requirements"">RFC4657</a>], except to
add more capabilities and objective functions.
<span class="grey">Yasukawa & Farrel Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5862">RFC 5862</a> PCC-PCE and P2MP MPLS-TE June 2010</span>
<span class="h4"><a class="selflink" id="section-3.1.14" href="#section-3.1.14">3.1.14</a>. Path-Tree Diversity</span>
<a href="#section-3.1.9">Section 3.1.9</a> sets out the requirement to be able to request multiple
diverse paths. Additionally, with P2MP trees, it may be that only
parts of the tree can be, or need to be, diverse.
R15: The PCC SHOULD be able to request a PCE to compute a secondary
P2MP path tree with partial path diversity for specific leaves
or a specific S2L sub-path.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Manageability Considerations</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Control of Function and Policy</span>
PCE implementations MAY provide a configuration switch to allow
support of P2MP MPLS TE computations to be enabled or disabled. When
the level of support is changed, this SHOULD be re-advertised as
described in <a href="#section-3.1.13">Section 3.1.13</a>.
Support for, and advertisement of support for, P2MP MPLS TE path
computation MAY be subject to policy, and a PCE MAY hide its P2MP
capabilities from certain PCCs by not advertising them through the
discovery protocol and not reporting them to the specific PCCs in any
PCECP capabilities exchange. Further, a PCE MAY be directed by
policy to refuse a P2MP path computation for any reason including,
but not limited to, the identity of the PCC that makes the request.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Information and Data Models</span>
PCECP protocol extensions to support P2MP MPLS TE SHOULD be
accompanied by MIB objects for the control and monitoring of the
protocol and the PCE that performs the computations. The MIB objects
MAY be provided in the same MIB module as used for general PCECP
control and monitoring or MAY be provided in a new MIB module.
The MIB objects SHOULD provide the ability to control and monitor all
aspects of PCECP relevant to P2MP MPLS TE path computation.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Liveness Detection and Monitoring</span>
No changes are necessary to the liveness detection and monitoring
requirements as already embodied in [<a href="./rfc4657" title=""Path Computation Element (PCE) Communication Protocol Generic Requirements"">RFC4657</a>]. However, it should be
noted that, in general, P2MP computations are likely to take longer
than P2P computations. The liveness detection and monitoring
features of the PCECP SHOULD take this into account.
<span class="grey">Yasukawa & Farrel Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5862">RFC 5862</a> PCC-PCE and P2MP MPLS-TE June 2010</span>
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Verifying Correct Operation</span>
There are no additional requirements beyond those expressed in
[<a href="./rfc4657" title=""Path Computation Element (PCE) Communication Protocol Generic Requirements"">RFC4657</a>] for verifying the correct operation of the PCECP. Note
that verification of the correct operation of the PCE and its
algorithms is out of scope for the protocol requirements, but a PCC
MAY send the same request to more than one PCE and compare the
results.
<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>. Requirements on Other Protocols and Functional Components</span>
A PCE operates on a topology graph that may be built using
information distributed by TE extensions to the routing protocol
operating within the network. In order that the PCE can select a
suitable path for the signaling protocol to use to install the P2MP
LSP, the topology graph must include information about the P2MP
signaling and branching capabilities of each LSR in the network.
Whatever means is used to collect the information to build the
topology graph, the graph MUST include the requisite information. If
the TE extensions to the routing protocol are used, these SHOULD be
as described in [<a href="./rfc5073" title=""IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities"">RFC5073</a>].
<span class="h3"><a class="selflink" id="section-4.6" href="#section-4.6">4.6</a>. Impact on Network Operation</span>
The use of a PCE to compute P2MP paths is not expected to have
significant impact on network operations. However, it should be
noted that the introduction of P2MP support to a PCE that already
provides P2P path computation might change the loading of the PCE
significantly, and that might have an impact on the network behavior,
especially during recovery periods immediately after a network
failure.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
P2MP computation requests do not raise any additional security issues
for the PCECP, as there are no new messages and no new PCC-PCE
relationships or transactions introduced.
Note, however, that P2MP computation requests are more CPU-intensive
and also use more link bandwidth. Therefore, if the PCECP was
susceptible to denial of service attacks based on the injection of
spurious Path Computation Requests, the support of P2MP path
computation would exacerbate the effect.
It would be possible to consider applying different authorization
policies for P2MP Path Computation Requests compared to other
requests.
<span class="grey">Yasukawa & Farrel Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5862">RFC 5862</a> PCC-PCE and P2MP MPLS-TE June 2010</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Acknowledgments</span>
Thanks to Dean Cheng, Young Lee, Quintin Zhao, Daniel King,
Fabien Verhaeghe, and Francis Dupont for their comments and
suggestions on this document.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. References</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.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>, March 1997.
[<a id="ref-RFC4657">RFC4657</a>] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol Generic
Requirements", <a href="./rfc4657">RFC 4657</a>, September 2006.
[<a id="ref-RFC5394">RFC5394</a>] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
"Policy-Enabled Path Computation Framework", <a href="./rfc5394">RFC 5394</a>,
December 2008.
[<a id="ref-RFC5671">RFC5671</a>] Yasukawa, S. and A. Farrel, Ed., "Applicability of the
Path Computation Element (PCE) to Point-to-Multipoint
(P2MP) MPLS and GMPLS Traffic Engineering (TE)",
<a href="./rfc5671">RFC 5671</a>, October 2009.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<a id="ref-RFC3209">RFC3209</a>] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", <a href="./rfc3209">RFC 3209</a>, December 2001.
[<a id="ref-RFC4461">RFC4461</a>] Yasukawa, S., Ed., "Signaling Requirements for Point-to-
Multipoint Traffic-Engineered MPLS Label Switched Paths
(LSPs)", <a href="./rfc4461">RFC 4461</a>, April 2006.
[<a id="ref-RFC4655">RFC4655</a>] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", <a href="./rfc4655">RFC 4655</a>,
August 2006.
[<a id="ref-RFC4674">RFC4674</a>] Le Roux, J., Ed., "Requirements for Path Computation
Element (PCE) Discovery", <a href="./rfc4674">RFC 4674</a>, October 2006.
[<a id="ref-RFC4834">RFC4834</a>] Morin, T., Ed., "Requirements for Multicast in Layer 3
Provider-Provisioned Virtual Private Networks (PPVPNs)",
<a href="./rfc4834">RFC 4834</a>, April 2007.
<span class="grey">Yasukawa & Farrel Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5862">RFC 5862</a> PCC-PCE and P2MP MPLS-TE June 2010</span>
[<a id="ref-RFC4875">RFC4875</a>] Aggarwal, R., Ed., Papadimitriou, D., Ed., and
S. Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", <a href="./rfc4875">RFC 4875</a>,
May 2007.
[<a id="ref-RFC5073">RFC5073</a>] Vasseur, J., Ed., and J. Le Roux, Ed., "IGP Routing
Protocol Extensions for Discovery of Traffic Engineering
Node Capabilities", <a href="./rfc5073">RFC 5073</a>, December 2007.
[<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>, June 2009.
Authors' Addresses
Seisho Yasukawa
NTT Corporation
9-11, Midori-Cho 3-Chome
Musashino-Shi, Tokyo 180-8585
JAPAN
EMail: yasukawa.seisho@lab.ntt.co.jp
Adrian Farrel
Old Dog Consulting
EMail: adrian@olddog.co.uk
Yasukawa & Farrel Informational [Page 11]
</pre>
|
