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
|
<pre>Network Working Group E. Oki
Request for Comments: 5521 University of Electro-Communications
Category: Standards Track T. Takeda
NTT
A. Farrel
Old Dog Consulting
April 2009
<span class="h1">Extensions to the Path Computation Element Communication Protocol</span>
<span class="h1">(PCEP) for Route Exclusions</span>
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
<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="./rfc5521">RFC 5521</a> Extensions to PCEP for Route Exclusions April 2009</span>
Abstract
The Path Computation Element (PCE) provides functions of path
computation in support of traffic engineering (TE) in Multi-Protocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.
When a Path Computation Client (PCC) requests a PCE for a route, it
may be useful for the PCC to specify, as constraints to the path
computation, abstract nodes, resources, and Shared Risk Link Groups
(SRLGs) that are to be explicitly excluded from the computed route.
Such constraints are termed "route exclusions".
The PCE Communication Protocol (PCEP) is designed as a communication
protocol between PCCs and PCEs. This document presents PCEP
extensions for route exclusions.
Table of Contents
<a href="#section-1">1</a>. Introduction ................................................. <a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Conventions Used in This Document .......................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Protocol Procedures and Extensions ........................... <a href="#page-4">4</a>
<a href="#section-2.1">2.1</a>. Exclude Route Object (XRO) ............................. <a href="#page-4">4</a>
<a href="#section-2.1.1">2.1.1</a>. Definition ..................................... <a href="#page-4">4</a>
<a href="#section-2.1.2">2.1.2</a>. Processing Rules ............................... <a href="#page-8">8</a>
<a href="#section-2.2">2.2</a>. Explicit Route Exclusion ............................... <a href="#page-9">9</a>
<a href="#section-2.2.1">2.2.1</a>. Definition ..................................... <a href="#page-9">9</a>
<a href="#section-2.2.2">2.2.2</a>. Processing Rules .............................. <a href="#page-10">10</a>
<a href="#section-3">3</a>. Exclude Route with Confidentiality .......................... <a href="#page-11">11</a>
<a href="#section-3.1">3.1</a>. Exclude Route Object (XRO) Carrying Path-Key .......... <a href="#page-11">11</a>
<a href="#section-3.1.1">3.1.1</a>. Definition .................................... <a href="#page-11">11</a>
<a href="#section-3.1.2">3.1.2</a>. Processing Rules .............................. <a href="#page-12">12</a>
<a href="#section-4">4</a>. IANA Considerations ......................................... <a href="#page-13">13</a>
<a href="#section-4.1">4.1</a>. PCEP Objects .......................................... <a href="#page-13">13</a>
<a href="#section-4.2">4.2</a>. New Subobject for the Include Route Object ............ <a href="#page-13">13</a>
<a href="#section-4.3">4.3</a>. Error Object Field Values ............................. <a href="#page-13">13</a>
<a href="#section-4.4">4.4</a>. Exclude Route Flags ................................... <a href="#page-14">14</a>
<a href="#section-5">5</a>. Manageability Considerations ................................ <a href="#page-14">14</a>
<a href="#section-6">6</a>. Security Considerations ..................................... <a href="#page-14">14</a>
<a href="#section-7">7</a>. References .................................................. <a href="#page-15">15</a>
<a href="#section-7.1">7.1</a>. Normative References .................................. <a href="#page-15">15</a>
<a href="#section-7.2">7.2</a>. Informative References ................................ <a href="#page-15">15</a>
Acknowledgements ................................................ <a href="#page-16">16</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="./rfc5521">RFC 5521</a> Extensions to PCEP for Route Exclusions April 2009</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.
When a PCC requests a PCE for a route, it may be useful for the PCC
to specify abstract nodes, resources, and Shared Risk Link Groups
(SRLGs) that are to be explicitly excluded from the route.
For example, disjoint paths for inter-domain Label Switched Paths
(LSPs) may be computed by cooperation between PCEs, each of which
computes segments of the paths across one domain. In order to
achieve path computation for a secondary (backup) path, a PCE may act
as a PCC to request another PCE for a route that must be
node/link/SRLG disjoint from the primary (working) path. Another
example is where a network operator wants a path to avoid specified
nodes for administrative reasons, perhaps because the specified nodes
will be out-of-service in the near future.
[<a id="ref-RFC4657">RFC4657</a>] specifies generic requirements for a communication protocol
between PCCs and PCEs. Generic constraints described in [<a href="./rfc4657" title=""Path Computation Element (PCE) Communication Protocol Generic Requirements"">RFC4657</a>]
include route exclusions for links, nodes, and SRLGs. That is, the
requirement for support of route exclusions within the PCC-PCE
communication protocol is already established.
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>]. This
document presents PCEP extensions to satisfy the requirements for
route exclusions as described in Sections <a href="#section-5.1.4">5.1.4</a> and <a href="#section-5.1.16">5.1.16</a> of
[<a href="./rfc4657" title=""Path Computation Element (PCE) Communication Protocol Generic Requirements"">RFC4657</a>].
Note that MPLS-TE and GMPLS signaling extensions for communicating
route exclusions between network nodes for specific Label Switched
Paths (LSPs) are described in [<a href="./rfc4874" title=""Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)"">RFC4874</a>]. Route exclusions may be
specified during provisioning requests for specific LSPs by setting
the mplsTunnelHopInclude object of MPLS-TE-STD-MIB defined in
[<a href="./rfc3812" title=""Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)"">RFC3812</a>] to false (2).
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</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>].
<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="./rfc5521">RFC 5521</a> Extensions to PCEP for Route Exclusions April 2009</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Protocol Procedures and Extensions</span>
This section describes the procedures adopted by a PCE handling a
request for path computation with route exclusions received from a
PCC, and defines how those exclusions are encoded.
There are two types of route exclusion described in [<a href="./rfc4874" title=""Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)"">RFC4874</a>].
1. Exclusion of certain abstract nodes or resources from the whole
path. This set of abstract nodes is referred to as the Exclude
Route List.
2. Exclusion of certain abstract nodes or resources between a
specific pair of abstract nodes present in an explicit path. Such
specific exclusions are referred to as an Explicit Route
Exclusion.
This document defines protocol extensions to allow a PCC to specify
both types of route exclusions to a PCE on a path computation
request.
A new PCEP object, the Exclude Route Object (XRO), is defined to
convey the Exclude Route List. The existing Include Route Object
(IRO) in PCEP [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>] is modified by introducing a new IRO
subobject, the Explicit Exclusion Route subobject (EXRS), to convey
Explicit Route Exclusions.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Exclude Route Object (XRO)</span>
<span class="h4"><a class="selflink" id="section-2.1.1" href="#section-2.1.1">2.1.1</a>. Definition</span>
The XRO is OPTIONAL and MAY be carried within Path Computation
Request (PCReq) and Path Computation Reply (PCRep) messages.
When present in a PCReq message, the XRO provides a list of network
resources that the PCE is requested to exclude from the path that it
computes. Flags associated with each list member instruct the PCE as
to whether the network resources must be excluded from the computed
path, or whether the PCE should make best efforts to exclude the
resources from the computed path.
The XRO MAY be used on a PCRep message that carries the NO-PATH
object (i.e., one that reports a path computation failure) to
indicate the set of elements of the original XRO that prevented the
PCE from finding a path.
The XRO MAY also be used on a PCRep message for a successful path
computation when the PCE wishes to provide a set of exclusions to be
<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="./rfc5521">RFC 5521</a> Extensions to PCEP for Route Exclusions April 2009</span>
signaled during LSP setup using the extensions to Resource
Reservation Protocol (RSVP)-TE [<a href="./rfc4874" title=""Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)"">RFC4874</a>].
The XRO Object-Class is 17.
The XRO Object-Type is 1.
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 | Flags |F|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: XRO Body Format
Reserved: 16 bits - MUST be set to zero on transmission and SHOULD be
ignored on receipt.
Flags: 16 bits - The following flags are currently defined:
F (Fail - 1 bit): when set, the requesting PCC requires the
computation of a new path for an existing TE LSP that has failed.
If the F bit is set, the path of the existing TE LSP MUST be
provided in the PCReq message by means of a Record Route Object
(RRO) defined in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>]. This allows the path computation to
take into account the previous path and reserved resources to
avoid double bandwidth booking should the Traffic Engineering
Database (TED) have not yet been updated or the corresponding
resources not be yet been released. This will usually be used in
conjunction with the exclusion from the path computation of the
failed resource that caused the LSP to fail.
Subobjects: The XRO is made up of one or more subobject(s). An XRO
with no subobjects MUST NOT be sent and SHOULD be ignored on receipt.
In the following subobject definitions, a set of fields have
consistent meaning as follows:
X
The X-bit indicates whether the exclusion is mandatory or desired.
0 indicates that the resource specified MUST be excluded from the
path computed by the PCE. 1 indicates that the resource specified
SHOULD be excluded from the path computed by the PCE, but MAY be
<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="./rfc5521">RFC 5521</a> Extensions to PCEP for Route Exclusions April 2009</span>
included subject to PCE policy and the absence of a viable path
that meets the other constraints and excludes the resource.
Type
The type of the subobject. The following subobject types are
defined.
Type Subobject
-------------+-------------------------------
1 IPv4 prefix
2 IPv6 prefix
4 Unnumbered Interface ID
32 Autonomous system number
34 SRLG
Length
The length of the subobject including the Type and Length fields.
Prefix Length
Where present, this field can be used to indicate a set of
addresses matching a prefix. If the subobject indicates a single
address, the prefix length MUST be set to the full length of the
address.
Attribute
The Attribute field indicates how the exclusion subobject is to be
interpreted.
0 Interface
The subobject is to be interpreted as an interface or set of
interfaces. All interfaces identified by the subobject are to be
excluded from the computed path according to the setting of the
X-bit. This value is valid only for subobject types 1, 2, and 3.
1 Node
The subobject is to be interpreted as a node or set of nodes. All
nodes identified by the subobject are to be excluded from the
computed path according to the setting of the X-bit. This value
is valid only for subobject types 1, 2, 3, and 4.
2 SRLG
The subobject identifies an SRLG explicitly or indicates all of
the SRLGs associated with the resource or resources identified by
the subobject. Resources that share any SRLG with those
identified are to be excluded from the computed path according to
the setting of the X-bit. This value is valid for all subobjects.
<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="./rfc5521">RFC 5521</a> Extensions to PCEP for Route Exclusions April 2009</span>
Reserved
Reserved fields within subobjects MUST be transmitted as zero and
SHOULD be ignored on receipt.
The subobjects are encoded as follows:
IPv4 prefix Subobject
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Type = 1 | Length | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) | Prefix Length | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 prefix Subobject
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Type = 2 | Length | IPv6 address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | Prefix Length | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Unnumbered Interface ID Subobject
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Type = 3 | Length | Reserved | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The TE Router ID and Interface ID fields are as defined in [<a href="./rfc3477" title=""Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)"">RFC3477</a>].
<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="./rfc5521">RFC 5521</a> Extensions to PCEP for Route Exclusions April 2009</span>
Autonomous System Number Subobject
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Type = 4 | Length | 2-Octet AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that as in other PCEP objects [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>] and RSVP-TE objects
[<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>], no support for 4-octet Autonomous System (AS) Numbers is
provided. It is anticipated that, as 4-octet AS Numbers become more
common, both PCEP and RSVP-TE will be updated in a consistent way to
add this support.
SRLG Subobject
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Type = 5 | Length | SRLG Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG Id (continued) | Reserved | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Attribute SHOULD be set to two (2) and SHOULD be ignored on
receipt.
<span class="h4"><a class="selflink" id="section-2.1.2" href="#section-2.1.2">2.1.2</a>. Processing Rules</span>
A PCC builds an XRO to encode all of the resources that it wishes the
PCE to exclude from the path that it is requested to compute. For
each exclusion, the PCC clears the X-bit to indicate that the PCE is
required to exclude the resources, or sets the X-bit to indicate that
the PCC simply desires that the resources are excluded. For each
exclusion, the PCC also sets the Attribute field to indicate how the
PCE should interpret the contents of the exclusion subobject.
When a PCE receives a PCReq message it looks for an XRO to see if
exclusions are required. If the PCE finds more than one XRO, it MUST
use the first one in the message and MUST ignore subsequent
instances.
If the PCE does not recognize the XRO, it MUST return a PCErr message
with Error-Type "Unknown Object" as described in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>].
If the PCE is unwilling or unable to process the XRO, it MUST return
a PCErr message with the Error-Type "Not supported object" and follow
the relevant procedures described in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>].
<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="./rfc5521">RFC 5521</a> Extensions to PCEP for Route Exclusions April 2009</span>
If the PCE processes the XRO and attempts to compute a path, it MUST
adhere to the requested exclusions as expressed in the XRO. That is,
the returned path MUST NOT include any resources encoded with the
X-bit clear, and SHOULD NOT include any with the X-bit set unless
alternate paths that match the other constraints expressed in the
PCReq are unavailable.
When a PCE returns a path in a PCRep, it MAY also supply an XRO. An
XRO in a PCRep message with the NO-PATH object indicates that the set
of elements of the original XRO prevented the PCE from finding a
path. On the other hand, if an XRO is present in a PCRep message
without a NO-PATH object, the PCC SHOULD apply the contents using the
same rules as in [<a href="./rfc4874" title=""Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)"">RFC4874</a>] and the PCC or a corresponding LSR SHOULD
signal an RSVP-TE XRO to indicate the exclusions that downstream LSRs
should apply. This may be particularly useful in per-domain path
computation scenarios [<a href="./rfc5152" title=""A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)"">RFC5152</a>].
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Explicit Route Exclusion</span>
<span class="h4"><a class="selflink" id="section-2.2.1" href="#section-2.2.1">2.2.1</a>. Definition</span>
Explicit Route Exclusion defines network elements that must not or
should not be used on the path between two abstract nodes or
resources explicitly indicated in the Include Route Object (IRO)
[<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>]. This information is encoded by defining a new subobject
for the IRO.
The new IRO subobject, the Explicit Exclusion Route subobject (EXRS),
has type 33 (see <a href="#section-4">Section 4</a>). The EXRS contains one or more
subobjects in its own right. An EXRS MUST NOT be sent with no
subobjects, and if received with no subobjects, MUST be ignored.
The format of the EXRS is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// One or more EXRS subobjects //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L
MUST be set to zero on transmission and MUST be ignored on
receipt.
<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="./rfc5521">RFC 5521</a> Extensions to PCEP for Route Exclusions April 2009</span>
Reserved
MUST be set to zero on transmission and SHOULD be ignored on
receipt.
The EXRS subobject may carry any of the subobjects defined for
inclusion in the XRO by this document or by future documents. The
meanings of the fields of the XRO subobjects are unchanged when the
subobjects are included in an EXRS, except that scope of the
exclusion is limited to the single hop between the previous and
subsequent elements in the IRO.
<span class="h4"><a class="selflink" id="section-2.2.2" href="#section-2.2.2">2.2.2</a>. Processing Rules</span>
A PCC that supplies a partial explicit route to a PCE in an IRO MAY
also specify explicit exclusions by including one or more EXRSs in
the IRO.
If a PCE that does not support the use of EXRS receives an IRO in a
PCReq message that contains an EXRS, it will respond according to the
rules for a malformed object as described in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>]. The PCE MAY
also include the IRO in the PCErr to indicate in which case the IRO
SHOULD be terminated immediately after the unrecognized EXRS.
If a PCE that supports the EXRS in an IRO parses an IRO and
encounters an EXRS that contains a subobject that it does not support
or recognize, it MUST act according to the setting of the X-bit in
the subobject. If the X-bit is clear, the PCE MUST respond with a
PCErr with Error-Type "Unrecognized EXRS subobject" and set the
Error-Value to the EXRS subobject type code (see <a href="#section-4">Section 4</a>). If the
X-bit is set, the PCE MAY respond with a PCErr as already stated or
MAY ignore the EXRS subobject: this choice is a local policy
decision.
If a PCE parses an IRO and encounters an EXRS subobject that it
recognizes, it MUST act according to the requirements expressed in
the subobject. That is, if the X-bit is clear, the PCE MUST NOT
produce a path that includes any resource identified by the EXRS
subobject in the path between the previous abstract node in the IRO
and the next abstract node in the IRO. If the X-bit is set, the PCE
SHOULD NOT produce a path that includes any resource identified by
the EXRS subobject in the path between the previous abstract node in
the IRO and the next abstract node in the IRO unless it is not
possible to construct a path that avoids that resource while still
complying with the other constraints expressed in the PCReq message.
<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="./rfc5521">RFC 5521</a> Extensions to PCEP for Route Exclusions April 2009</span>
A successful path computation reported in a PCRep message MUST
include an ERO to specify the path that has been computed as
specified in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>]. That ERO MAY contain specific route
exclusions using the EXRS as specified in [<a href="./rfc4874" title=""Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)"">RFC4874</a>].
If the path computation fails and a PCErr is returned with a NO-PATH
object, the PCE MAY include an IRO to report the hops that could not
be complied with as described in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>], and that IRO MAY include
EXRSs.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Exclude Route with Confidentiality</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Exclude Route Object (XRO) Carrying Path-Key</span>
<span class="h4"><a class="selflink" id="section-3.1.1" href="#section-3.1.1">3.1.1</a>. Definition</span>
In PCE-based inter-domain diverse path computation, an XRO may be
used to find a backup (secondary) path. A sequential path
computation approach may be applied for this purpose, where a working
(primary) path route is computed first and a backup path route that
must be a node/link/SRLG disjoint route from the working path is then
computed [<a href="./rfc5298" title=""Analysis of Inter-Domain Label Switched Path (LSP) Recovery"">RFC5298</a>]. Backward Recursive Path Computation (BRPC) may
be used for inter-domain path computation [<a href="./rfc5441" title=""A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths"">RFC5441</a>].
In some cases of inter-domain computation (e.g., where domains are
administered by different service providers), confidentiality must be
kept. For primary path computation, to preserve confidentiality,
instead of explicitly expressing the computed route, Path-Key
Subobjects (PKSs) [<a href="./rfc5520" title=""Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism"">RFC5520</a>] are carried in the Explicit Route Object
(ERO) in the PCRep Message.
Therefore, during inter-domain diverse path computation, it may be
necessary to request diversity from a path that is not fully known
and where a segment of the path is represented by a PKS. This means
that a PKS may be present as a subobject of the XRO on a PCReq
message.
The format and definition of PKS when it appears as an XRO subobject
are as defined in [<a href="./rfc5520" title=""Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism"">RFC5520</a>], except for the definition of the L bit.
The L bit of the PKS subobject in the XRO MUST be ignored.
<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="./rfc5521">RFC 5521</a> Extensions to PCEP for Route Exclusions April 2009</span>
<span class="h4"><a class="selflink" id="section-3.1.2" href="#section-3.1.2">3.1.2</a>. Processing Rules</span>
Consider that BRPC is applied for both working and backup path
computation in a sequential manner. First, PCC requests PCE for the
computation of a working path. After BRPC processing has completed,
the PCC receives the results of the working-path computation
expressed in an ERO in a PCRep message. The ERO may include PKSs if
certain segments of the path are to be kept confidential.
For backup path computation, when the PCC constructs a PCReq Message,
it includes the entire working-path in the XRO so that the computed
path is node/link disjoint from the working path. The XRO may also
include SRLGs to ensure SRLG diversity from the working path. If the
working path ERO includes PKS subobjects, these are also included in
the XRO to allow the PCE to ensure diversity.
A set of PCEs for backup path computation may be the same as ones for
working path computation, or they may be different.
- Identical PCEs
In the case where the same PCEs are used for both path
computations, the processing is as follows. During the process of
BRPC for backup path computation, a PCE may encounter a PKS as it
processes the XRO when it creates a virtual path tree (VPT) in its
own domain. The PCE retrieves the PCE-ID from the PKS, recognizes
itself, and converts the PKS into a set of XRO subobjects that it
uses for the local calculation to create the VPT. The XRO
subobjects created in this way MUST NOT be shared with other PCEs.
Other operations are the same as BRPC.
- Different PCEs
In the case where a set of PCEs for backup path computation is
different from the ones used for working path computation, the
processing is as follows. If a PCE encounters a PKS in an XRO
when it is creating a virtual path tree in its own domain, the PCE
retrieves the PCE-ID from the PKS and sends a PCReq message to the
identified PCE to expand the PKS. The PCE computing the VPT
treats the path segment in the response as a set of XRO subobjects
in performing its path computation. The XRO subobjects determined
in this way MUST NOT be shared with other PCEs.
<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="./rfc5521">RFC 5521</a> Extensions to PCEP for Route Exclusions April 2009</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. IANA Considerations</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. PCEP Objects</span>
The "PCEP Parameters" registry contains a subregistry "PCEP Objects".
IANA has made the following allocations from this registry.
Object Name Reference
Class
17 XRO [<a href="./rfc5521">RFC5521</a>]
Object-Type
1: Route exclusion
This object should be registered as being allowed to carry the
following subobjects:
Subobject Type Reference
1 IPv4 prefix [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>]
2 IPv6 prefix [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>]
4 Unnumbered Interface ID [<a href="./rfc3477" title=""Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)"">RFC3477</a>]
32 Autonomous system number [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>]
34 SRLG [<a href="./rfc4874" title=""Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)"">RFC4874</a>]
64 Path-Key with 32-bit PCE ID [<a href="./rfc5520" title=""Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism"">RFC5520</a>]
65 Path-Key with 128-bit PCE ID [<a href="./rfc5520" title=""Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism"">RFC5520</a>]
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. New Subobject for the Include Route Object</span>
The "PCEP Parameters" registry contains a subregistry "PCEP Objects"
with an entry for the Include Route Object (IRO).
IANA added a further subobject that can be carried in the IRO as
follows:
Subobject Type Reference
33 Explicit Exclusion Route subobject (EXRS) [<a href="./rfc4874" title=""Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)"">RFC4874</a>]
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Error Object Field Values</span>
The "PCEP Parameters" registry contains a subregistry "Error Types
and Values". IANA made the following allocations from this
subregistry.
Error
Type Meaning Reference
11 Unrecognized EXRS subobject [<a href="./rfc5521">RFC5521</a>]
<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="./rfc5521">RFC 5521</a> Extensions to PCEP for Route Exclusions April 2009</span>
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Exclude Route Flags</span>
IANA created a subregistry of the "PCEP Parameters" for the bits
carried in the Flags field of the Exclude Route Object (XRO). The
subregistry is called "XRO Flag Field".
New bits may be allocated only by an IETF Consensus action.
The field contains 16 bits numbered from bit 0 as the most
significant bit.
Bit Name Description Reference
15 F-bit Fail [<a href="./rfc5221">RFC5221</a>]
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Manageability Considerations</span>
A MIB module for management of the PCEP is being specified in a
separate document [<a href="#ref-PCEP-MIB" title=""PCE Communication Protocol(PCEP) Management Information Base"">PCEP-MIB</a>]. That MIB module allows examination of
individual PCEP messages, in particular requests, responses and
errors.
The MIB module MUST be extended to include the ability to view the
route exclusion extensions defined in this document.
Several local policy decisions should be made at the PCE. Firstly,
the exact behavior with regard to desired exclusions must be
available for examination by an operator and may be configurable.
Second, the behavior on receipt of an unrecognized XRO or EXRS
subobject with the X-bit set should be configurable and must be
available for inspection. The inspection and control of these local
policy choices may be part of the PCEP MIB module.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
The new exclude route mechanisms defined in this document allow finer
and more specific control of the path computed by a PCE. Such
control increases the risk if a PCEP message is intercepted,
modified, or spoofed because it allows the attacker to exert control
over the path that the PCE will compute or to make the path
computation impossible. Therefore, the security techniques described
in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>] are considered more important.
Note, however, that the route exclusion mechanisms also provide the
operator with the ability to route around vulnerable parts of the
network and may be used to increase overall network security.
<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="./rfc5521">RFC 5521</a> Extensions to PCEP for Route Exclusions April 2009</span>
<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-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-RFC5152">RFC5152</a>] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A
Per-Domain Path Computation Method for Establishing
Inter-Domain Traffic Engineering (TE) Label Switched Paths
(LSPs)", <a href="./rfc5152">RFC 5152</a>, February 2008.
[<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>,
March 2009.
[<a id="ref-RFC5441">RFC5441</a>] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
"A Backward-Recursive PCE-Based Computation (BRPC)
Procedure to Compute Shortest Constrained Inter-Domain
Traffic Engineering Label Switched Paths", <a href="./rfc5441">RFC 5441</a>, April
2009.
[<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>,
April 2009.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<a id="ref-PCEP-MIB">PCEP-MIB</a>] Koushik, A. S. K., and E. Stephan, "PCE Communication
Protocol(PCEP) Management Information Base", Work in
Progress, November 2008.
[<a id="ref-RFC3477">RFC3477</a>] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
in Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", <a href="./rfc3477">RFC 3477</a>, January 2003.
[<a id="ref-RFC3812">RFC3812</a>] Srinivasan, C., Viswanathan, A., and T. Nadeau,
"Multiprotocol Label Switching (MPLS) Traffic Engineering
(TE) Management Information Base (MIB)", <a href="./rfc3812">RFC 3812</a>, June
2004.
<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="./rfc5521">RFC 5521</a> Extensions to PCEP for Route Exclusions April 2009</span>
[<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-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-RFC4874">RFC4874</a>] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes -
Extension to Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE)", <a href="./rfc4874">RFC 4874</a>, April 2007.
[<a id="ref-RFC5298">RFC5298</a>] Takeda, T., Ed., Farrel, A., Ed., Ikejiri, Y., and JP.
Vasseur, "Analysis of Inter-Domain Label Switched Path
(LSP) Recovery", <a href="./rfc5298">RFC 5298</a>, August 2008.
Acknowledgements
The authors would like to thank Fabien Verhaeghe for valuable
comments on subobject formats. Thanks to Magnus Westerlund, Dan
Romascanu, Tim Polk, and Dave Ward for comments during IESG review.
Authors' Addresses
Eiji Oki
University of Electro-Communications
1-5-1 Chofugaoka
Chofu, Tokyo 182-8585
JAPAN
EMail: oki@ice.uec.ac.jp
Tomonori Takeda
NTT
3-9-11 Midori-cho,
Musashino-shi, Tokyo 180-8585, Japan
EMail: takeda.tomonori@lab.ntt.co.jp
Adrian Farrel
Old Dog Consulting
EMail: adrian@olddog.co.uk
Oki, et al. Standards Track [Page 16]
</pre>
|
