1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
|
<pre>Network Working Group JP. Vasseur, Ed.
Request for Comments: 5441 Cisco Systems, Inc
Category: Standards Track R. Zhang
BT Infonet
N. Bitar
Verizon
JL. Le Roux
France Telecom
April 2009
<span class="h1">A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute</span>
<span class="h1">Shortest Constrained Inter-Domain Traffic Engineering</span>
<span class="h1">Label Switched Paths</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">Vasseur, 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="./rfc5441">RFC 5441</a> BRPC April 2009</span>
Abstract
The ability to compute shortest constrained Traffic Engineering Label
Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) networks across multiple domains has been
identified as a key requirement. In this context, a domain is a
collection of network elements within a common sphere of address
management or path computational responsibility such as an IGP area
or an Autonomous Systems. This document specifies a procedure
relying on the use of multiple Path Computation Elements (PCEs) to
compute such inter-domain shortest constrained paths across a
predetermined sequence of domains, using a backward-recursive path
computation technique. This technique preserves confidentiality
across domains, which is sometimes required when domains are managed
by different service providers.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Requirements Language . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2">2</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3">3</a>. General Assumptions . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4">4</a>. BRPC Procedure . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4.1">4.1</a>. Domain Path Selection . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.2">4.2</a>. Mode of Operation . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5">5</a>. PCEP Protocol Extensions . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-6">6</a>. VSPT Encoding . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-7">7</a>. Inter-AS TE Links . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-8">8</a>. Usage in Conjunction with Per-Domain Path Computation . . . . <a href="#page-10">10</a>
<a href="#section-9">9</a>. BRPC Procedure Completion Failure . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-10">10</a>. Applicability . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-10.1">10.1</a>. Diverse End-to-End Path Computation . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-10.2">10.2</a>. Path Optimality . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-11">11</a>. Reoptimization of an Inter-Domain TE LSP . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-12">12</a>. Path Computation Failure . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-13">13</a>. Metric Normalization . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-14">14</a>. Manageability Considerations . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-14.1">14.1</a>. Control of Function and Policy . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-14.2">14.2</a>. Information and Data Models . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-14.3">14.3</a>. Liveness Detection and Monitoring . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-14.4">14.4</a>. Verifying Correct Operation . . . . . . . . . . . . . . . <a href="#page-13">13</a>
14.5. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-14.6">14.6</a>. Impact on Network Operation . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-14.7">14.7</a>. Path Computation Chain Monitoring . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-15">15</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-15.1">15.1</a>. New Flag of the RP Object . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-15.2">15.2</a>. New Error-Type and Error-Value . . . . . . . . . . . . . . <a href="#page-14">14</a>
<span class="grey">Vasseur, 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="./rfc5441">RFC 5441</a> BRPC April 2009</span>
<a href="#section-15.3">15.3</a>. New Flag of the NO-PATH-VECTOR TLV . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-16">16</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-17">17</a>. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-18">18</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-18.1">18.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-18.2">18.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The requirements for inter-area and inter-AS MPLS Traffic Engineering
(TE) have been developed by the Traffic Engineering Working Group (TE
WG) and have been stated in [<a href="./rfc4105" title=""Requirements for Inter-Area MPLS Traffic Engineering"">RFC4105</a>] and [<a href="./rfc4216" title=""MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements"">RFC4216</a>], respectively.
The framework for inter-domain Multiprotocol Label Switching (MPLS)
Traffic Engineering (TE) has been provided in [<a href="./rfc4726" title=""A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering"">RFC4726</a>].
[<a id="ref-RFC5152">RFC5152</a>] defines a technique for establishing an inter-domain
Generalized MPLS (GMPLS) TE Label Switched Path (LSP) whereby the
path is computed during the signaling process on a per-domain basis
by the entry boundary node of each domain (each node responsible for
triggering the computation of a section of an inter-domain TE LSP
path is always along the path of such TE LSP). This path computation
technique fulfills some of the requirements stated in [<a href="./rfc4105" title=""Requirements for Inter-Area MPLS Traffic Engineering"">RFC4105</a>] and
[<a href="./rfc4216" title=""MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements"">RFC4216</a>] but not all of them. In particular, it cannot guarantee to
find an optimal (shortest) inter-domain constrained path.
Furthermore, it cannot be efficiently used to compute a set of inter-
domain diversely routed TE LSPs.
The Path Computation Element (PCE) architecture is defined in
[<a href="./rfc4655" title=""A Path Computation Element (PCE)-Based Architecture"">RFC4655</a>]. The aim of this document is to describe a PCE-based path
computation procedure to compute optimal inter-domain constrained
(G)MPLS TE LSPs.
Qualifying a path as optimal requires some clarification. Indeed, a
globally optimal TE LSP placement usually refers to a set of TE LSPs
whose placements optimize the network resources with regards to a
specified objective function (e.g., a placement that reduces the
maximum or average network load while satisfying the TE LSP
constraints). In this document, an optimal inter-domain constrained
TE LSP is defined as the shortest path satisfying the set of required
constraints that would be obtained in the absence of multiple domains
(in other words, in a totally flat IGP network between the source and
destination of the TE LSP). Note that this requires the use of
consistent metric schemes in each domain (see <a href="#section-13">Section 13</a>).
<span class="grey">Vasseur, 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="./rfc5441">RFC 5441</a> BRPC April 2009</span>
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Requirements Language</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "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="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
ABR: Area Border Routers. Routers used to connect two IGP areas
(areas in OSPF or levels in IS-IS).
ASBR: Autonomous System Border Router. Router used to connect
together ASes of the same or different service providers via one or
more inter-AS links.
Boundary Node (BN): a boundary node is either an ABR in the context
of inter-area Traffic Engineering or an ASBR in the context of
inter-AS Traffic Engineering.
Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) along
a determined sequence of domains.
Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along
a determined sequence of domains.
Inter-area TE LSP: A TE LSP that crosses an IGP area boundary.
Inter-AS TE LSP: A TE LSP that crosses an AS boundary.
LSP: Label Switched Path.
LSR: Label Switching Router.
PCC: Path Computation Client. Any client application requesting a
path computation to be performed by a Path Computation Element.
PCE: Path Computation Element. An entity (component, application, or
network node) that is capable of computing a network path or route
based on a network graph and applying computational constraints.
PCE(i) is a PCE with the scope of domain(i).
TED: Traffic Engineering Database.
VSPT: Virtual Shortest Path Tree.
The notion of contiguous, stitched, and nested TE LSPs is defined in
[<a href="./rfc4726" title=""A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering"">RFC4726</a>] and will not be repeated here.
<span class="grey">Vasseur, 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="./rfc5441">RFC 5441</a> BRPC April 2009</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. General Assumptions</span>
In the rest of this document, we make the following set of
assumptions common to inter-area and inter-AS MPLS TE:
o Each IGP area or Autonomous System (AS) is assumed to be Traffic
Engineering enabled.
o No topology or resource information is distributed between domains
(as mandated per [<a href="./rfc4105" title=""Requirements for Inter-Area MPLS Traffic Engineering"">RFC4105</a>] and [<a href="./rfc4216" title=""MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements"">RFC4216</a>]), which is critical to
preserve IGP/BGP scalability and confidentiality.
o While certain constraints like bandwidth can be used across
different domains, other TE constraints (such as resource
affinity, color, metric, etc. [<a href="./rfc2702" title=""Requirements for Traffic Engineering Over MPLS"">RFC2702</a>]) could be translated at
domain boundaries. If required, it is assumed that, at the domain
boundary nodes, there will exist some sort of local mapping based
on policy agreement, in order to translate such constraints across
domain boundaries during the inter-PCE communication process.
o Each AS can be made of several IGP areas. The path computation
procedure described in this document applies to the case of a
single AS made of multiple IGP areas, multiple ASes made of a
single IGP area, or any combination of the above. For the sake of
simplicity, each AS will be considered to be made of a single area
in this document. The case of an inter-AS TE LSP spanning
multiple ASes, where some of those ASes are themselves made of
multiple IGP areas, can be easily derived from this case by
applying the BRPC procedure described in this document,
recursively.
o The domain path (the set of domains traversed to reach the
destination domain) is either administratively predetermined or
discovered by some means that is outside of the scope of this
document.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. BRPC Procedure</span>
The BRPC procedure is a multiple-PCE path computation technique as
described in [<a href="./rfc4655" title=""A Path Computation Element (PCE)-Based Architecture"">RFC4655</a>]. A possible model consists of hosting the PCE
function on boundary nodes (e.g., ABR or ASBR), but this is not
mandated by the BRPC procedure.
The BRPC procedure relies on communication between cooperating PCEs.
In particular, the PCC sends a PCReq to a PCE in its domain. The
request is forwarded between PCEs, domain-by-domain, until the PCE
responsible for the domain containing the LSP destination is reached.
The PCE in the destination domain creates a tree of potential paths
<span class="grey">Vasseur, 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="./rfc5441">RFC 5441</a> BRPC April 2009</span>
to the destination (the Virtual Shortest Path Tree - VSPT) and passes
this back to the previous PCE in a PCRep. Each PCE in turn adds to
the VSPT and passes it back until the PCE in the source domain uses
the VSPT to select an end-to-end path that the PCE sends to the PCC.
The BRPC procedure does not make any assumption with regards to the
nature of the inter-domain TE LSP that could be contiguous, nested,
or stitched.
Furthermore, no assumption is made on the actual path computation
algorithm in use by a PCE (e.g., it can be any variant of Constrained
Shortest Path First (CSPF) or an algorithm based on linear
programming to solve multi-constraint optimization problems).
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Domain Path Selection</span>
The PCE-based BRPC procedure applies to the computation of an optimal
constrained inter-domain TE LSP. The sequence of domains to be
traversed is either administratively predetermined or discovered by
some means that is outside of the scope of this document. The PCC
MAY indicate the sequence of domains to be traversed using the
Include Route Object (IRO) defined in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>] so that it is
available to all PCEs. Note also that a sequence of PCEs MAY be
enforced by policy on the PCC, and this constraint can be carried in
the PCEP path computation request (as defined in [<a href="#ref-PCE-MONITOR" title=""A set of monitoring tools for Path Computation Element based Architecture"">PCE-MONITOR</a>]).
The BRPC procedure guarantees to compute the optimal path across a
specific sequence of traversed domains (which constitutes an
additional constraint). In the case of an arbitrary set of meshed
domains, the BRPC procedure can be used to compute the optimal path
across each domain set in order to get the optimal constrained path
between the source and the destination of the TE LSP. The BRPC
procedure can also be used across a subset of all domain sequences,
and the best path among these sequences can then be selected.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Mode of Operation</span>
Definition of VSPT(i)
In each domain i:
o There is a set of X-en(i) entry BNs noted BN-en(k,i) where
BN-en(k,i) is the kth entry BN of domain(i).
o There is a set of X-ex(i) exit BNs noted BN-ex(k,i) where
BN-ex(k,i) is the kth exit BN of domain(i).
<span class="grey">Vasseur, 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="./rfc5441">RFC 5441</a> BRPC April 2009</span>
VSPT(i): MP2P (multipoint-to-point) tree returned by PCE(i) to
PCE(i-1):
Root (TE LSP destination)
/ | \
BN-en(1,i) BN-en(2,i) ... BN-en(j,i).
where [X-en(i)] is the number of
entry BNs in domain i and j<= [X-en(i)]
Figure 1: MP2P Tree
Each link of tree VSPT(i) represents the shortest constrained path
between BN-en(j,i) and the TE LSP destination that satisfies the set
of required constraints for the TE LSP (bandwidth, affinities, etc.).
These are path segments to reach the TE LSP destination from
BN-en(j,i).
Note that PCE(i) only considers the entry BNs of domain(i), i.e.,
only the BNs that provide connectivity from domain(i-1). In other
words, the set BN-en(k,i) is only made of those BNs that provide
connectivity from domain (i-1) to domain(i). Furthermore, some BNs
may be excluded according to policy constraints (either due to local
policy or policies signaled in the path computation request).
Step 1:
First, the PCC needs to determine the PCE capable of serving its path
computation request (this can be done with local configuration or via
IGP discovery (see [<a href="./rfc5088" title=""OSPF Protocol Extensions for Path Computation Element (PCE) Discovery"">RFC5088</a>] and [<a href="./rfc5089" title=""IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery"">RFC5089</a>])). The path computation
request is then relayed until reaching a PCE(n) such that the TE LSP
destination resides in the domain(n). At each step of the process,
the next PCE can either be statically configured or dynamically
discovered via IGP/BGP extensions. If no next PCE can be found or
the next-hop PCE of choice is unavailable, the procedure stops and a
path computation error is returned (see <a href="#section-9">Section 9</a>). If PCE(i-1)
discovers multiple PCEs for the adjacent domain(i), PCE(i) may select
a subset of these PCEs based on some local policies or heuristics.
The PCE selection process is outside of the scope of this document.
Step 2:
PCE(n) computes VSPT(n), the tree made of the list of shortest
constrained paths between every BN-en(j,n) and the TE LSP destination
using a suitable path computation algorithm (e.g., CSPF) and returns
the computed VSPT(n) to PCE(n-1).
<span class="grey">Vasseur, 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="./rfc5441">RFC 5441</a> BRPC April 2009</span>
Step i:
For i=n-1 to 2: PCE(i) computes VSPT(i), the tree made of the
shortest constrained paths between each BN-en(j,i) and the TE LSP
destination. It does this by considering its own TED and the
information in VSPT(i+1).
In the case of inter-AS TE LSP computation, this also requires adding
the inter-AS TE links that connect the domain(i) to the domain(i+1).
Step n:
Finally, PCE(1) computes the end-to-end shortest constrained path
from the source to the destination and returns the corresponding path
to the requesting PCC in the form of a PCRep message as defined in
[<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>].
Each branch of the VSPT tree (path) may be returned in the form of an
explicit path (in which case, all the hops along the path segment are
listed) or a loose path (in which case, only the BN is specified) so
as to preserve confidentiality along with the respective cost. In
the latter case, various techniques can be used in order to retrieve
the computed explicit paths on a per-domain basis during the
signaling process, thanks to the use of path keys as described in
[<a href="#ref-PATH-KEY" title=""Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Key-Based Mechanism"">PATH-KEY</a>].
A PCE that can compute the requested path for more than one
consecutive domain on the path SHOULD perform this computation for
all such domains before passing the PCRep to the previous PCE in the
sequence.
BRPC guarantees to find the optimal (shortest) constrained inter-
domain TE LSP according to a set of defined domains to be traversed.
Note that other variants of the BRPC procedure relying on the same
principles are also possible.
Note also that in case of Equal Cost Multi-Path (ECMP) paths, more
than one path could be returned to the requesting PCC.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. PCEP Protocol Extensions</span>
The BRPC procedure requires the specification of a new flag of the RP
object carried within the PCReq message (defined in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>]) to
specify that the shortest paths satisfying the constraints from the
destination to the set of entry boundary nodes are requested (such a
set of paths forms the downstream VSPT as specified in <a href="#section-4.2">Section 4.2</a>).
<span class="grey">Vasseur, 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="./rfc5441">RFC 5441</a> BRPC April 2009</span>
The following new flag of the RP object is defined:
VSPT Flag
Bit Number Name Flag
25 VSPT
When set, the VSPT Flag indicates that the PCC requests the
computation of an inter-domain TE LSP using the BRPC procedure
defined in this document.
Because path segments computed by a downstream PCE in the context of
the BRPC procedure MUST be provided along with their respective path
costs, the C flag of the METRIC object carried within the PCReq
message MUST be set. It is the choice of the requester to
appropriately set the O bit of the RP object.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. VSPT Encoding</span>
The VSPT is returned within a PCRep message. The encoding consists
of a non-ordered list of Explicit Route Objects (EROs) where each ERO
represents a path segment from a BN to the destination specified in
the END-POINT object of the corresponding PCReq message.
Example:
<---- area 1 ----><---- area 0 -----><------ area 2 ------>
ABR1-A-B-+
| |
ABR2-----D
| |
ABR3--C--+
Figure 2: An Example of VSPT Encoding Using a Set of EROs
In the simple example shown in Figure 2, if we make the assumption
that a constrained path exists between each ABR and the destination
D, the VSPT computed by a PCE serving area 2 consists of the
following non-ordered set of EROs:
o ERO1: ABR1(TE Router ID)-A(Interface IP address)-B(Interface IP
address)-D(TE Router ID)
o ERO2: ABR2(TE Router ID)-D(TE Router ID)
o ERO3: ABR3(TE Router ID)-C(interface IP address)-D(TE Router ID)
The PCReq message, PCRep message, PCEP END-POINT object, and ERO
object are defined in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>].
<span class="grey">Vasseur, 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="./rfc5441">RFC 5441</a> BRPC April 2009</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Inter-AS TE Links</span>
In the case of inter-AS TE LSP path computation, the BRPC procedure
requires the knowledge of the traffic engineering attributes of the
inter-AS TE links. The process by which the PCE acquires this
information is out of the scope of the BRPC procedure, which is
compliant with the PCE architecture defined in [<a href="./rfc4655" title=""A Path Computation Element (PCE)-Based Architecture"">RFC4655</a>].
That said, a straightforward solution consists of allowing the ASBRs
to flood the TE information related to the inter-ASBR links although
no IGP TE is enabled over those links (there is no IGP adjacency over
the inter-ASBR links). This allows the PCE of a domain to get entire
TE visibility up to the set of entry ASBRs in the downstream domain
(see the IGP extensions defined in [<a href="./rfc5316" title=""ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering"">RFC5316</a>] and [<a href="./rfc5392" title=""OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering"">RFC5392</a>]).
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Usage in Conjunction with Per-Domain Path Computation</span>
The BRPC procedure may be used to compute path segments in
conjunction with other path computation techniques (such as the per-
domain path computation technique defined in [<a href="./rfc5152" title=""A Per- Domain Path Computation Method for Establishing Inter- Domain Traffic Engineering (TE) Label Switched Paths (LSPs)"">RFC5152</a>]) to compute
the end-to-end path. In this case, end-to-end path optimality can no
longer be guaranteed.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. BRPC Procedure Completion Failure</span>
If the BRPC procedure cannot be completed because a PCE along the
domain does not recognize the procedure (VSPT flag of the RP object),
as stated in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>], the PCE sends a PCErr message to the upstream
PCE with an Error-Type=4 (Not supported object), Error-value=4
(Unsupported parameter). The PCE may include the parent object (RP
object) up to and including (but no further than) the unknown or
unsupported parameter. In this case where the unknown or unsupported
parameter is a bit flag (VSPT flag), the included RP object should
contain the whole bit flag field with all bits after the parameter at
issue set to zero. The corresponding path computation request is
then cancelled by the PCE without further notification.
If the BRPC procedure cannot be completed because a PCE along the
domain path recognizes but does not support the procedure, it MUST
return a PCErr message to the upstream PCE with an Error-Type "BRPC
procedure completion failure".
The PCErr message MUST be relayed to the requesting PCC.
PCEP-ERROR objects are used to report a PCEP protocol error and are
characterized by an Error-Type that specifies the type of error and
an Error-value that provides additional information about the error
type. Both the Error-Type and the Error-value are managed by IANA.
<span class="grey">Vasseur, 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="./rfc5441">RFC 5441</a> BRPC April 2009</span>
A new Error-Type is defined that relates to the BRPC procedure.
Error-Type Meaning
13 BRPC procedure completion failure
Error-value
1: BRPC procedure not supported by one or more PCEs
along the domain path
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Applicability</span>
As discussed in <a href="#section-3">Section 3</a>, the requirements for inter-area and
inter-AS MPLS Traffic Engineering have been developed by the Traffic
Engineering Working Group (TE WG) and have been stated in [<a href="./rfc4105" title=""Requirements for Inter-Area MPLS Traffic Engineering"">RFC4105</a>]
and [<a href="./rfc4216" title=""MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements"">RFC4216</a>], respectively. Among the set of requirements, both
documents indicate the need for some solution that provides the
ability to compute an optimal (shortest) constrained inter-domain TE
LSP and to compute a set of diverse inter-domain TE LSPs.
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. Diverse End-to-End Path Computation</span>
PCEP (see [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>]) allows a PCC to request the computation of a set
of diverse TE LSPs by setting the SVEC object's flags L, N, or S to
request link, node, or SRLG (Shared Risk Link Group) diversity,
respectively. Such requests MUST be taken into account by each PCE
along the path computation chain during the VSPT computation. In the
context of the BRPC procedure, a set of diversely routed TE LSPs
between two LSRs can be computed since the path segments of the VSPT
are simultaneously computed by a given PCE. The BRPC procedure
allows for the computation of diverse paths under various objective
functions (such as minimizing the sum of the costs of the N diverse
paths, etc.).
By contrast, with a 2-step approach consisting of computing the first
path followed by computing the second path after having removed the
set of network elements traversed by the first path (if that does not
violate confidentiality preservation), one cannot guarantee that a
solution will be found even if such solution exists. Furthermore,
even if a solution is found, it may not be the most optimal one with
respect to an objective function such as minimizing the sum of the
paths' costs, bounding the path delays of both paths, and so on.
Finally, it must be noted that such a 2-step path computation
approach is usually less efficient in terms of signaling delays since
it requires that two serialized TE LSPs be set up.
<span class="grey">Vasseur, 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="./rfc5441">RFC 5441</a> BRPC April 2009</span>
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Path Optimality</span>
BRPC guarantees that the optimal (shortest) constrained inter-domain
path will always be found, subject to policy constraints. Both in
the case where local path computation techniques are used (such as to
build stitched or nested TE LSPs), and in the case where a domain has
more than one BN-en or more than one BN-ex, it is only possible to
guarantee optimality after some network change within the domain by
completely re-executing the BRPC procedure.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Reoptimization of an Inter-Domain TE LSP</span>
The ability to reoptimize an existing inter-domain TE LSP path has
been explicitly listed as a requirement in [<a href="./rfc4105" title=""Requirements for Inter-Area MPLS Traffic Engineering"">RFC4105</a>] and [<a href="./rfc4216" title=""MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements"">RFC4216</a>].
In the case of a TE LSP reoptimization request, the reoptimization
procedure defined in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>] applies when the path in use (if
available on the head-end) is provided as part of the path
computation request so that the PCEs involved in the reoptimization
request can avoid double bandwidth accounting.
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. Path Computation Failure</span>
If a PCE requires to relay a path computation request according to
the BRPC procedure defined in this document to a downstream PCE and
no such PCE is available, the PCE MUST send a negative path
computation reply to the requester using a PCReq message as specified
in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>] that contains a NO-PATH object. In such case, the
NO-PATH object MUST carry a NO-PATH-VECTOR TLV (defined in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>])
with the newly defined bit named "BRPC path computation chain
unavailable" set.
Bit number Name Flag
28 BRPC path computation chain unavailable
<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a>. Metric Normalization</span>
In the case of inter-area TE, the same IGP/TE metric scheme is
usually adopted for all the IGP areas (e.g., based on the link-speed,
propagation delay, or some other combination of link attributes).
Hence, the proposed set of mechanisms always computes the shortest
path across multiple areas that obey the required set of constraints
with respect to a specified objective function. Conversely, in the
case of inter-AS TE, in order for this path computation to be
meaningful, metric normalization between ASes may be required. One
solution to avoid IGP metric modification would be for the service
providers to agree on a TE metric normalization scheme and use the TE
<span class="grey">Vasseur, 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="./rfc5441">RFC 5441</a> BRPC April 2009</span>
metric for TE LSP path computation (in that case, the use of the TE
metric must be requested in the PCEP path computation request) using
the METRIC object (defined in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>]).
<span class="h2"><a class="selflink" id="section-14" href="#section-14">14</a>. Manageability Considerations</span>
This section follows the guidance of [<a href="#ref-PCE-MANAGE" title=""Inclusion of Manageability Sections in PCE Working Group Drafts"">PCE-MANAGE</a>].
<span class="h3"><a class="selflink" id="section-14.1" href="#section-14.1">14.1</a>. Control of Function and Policy</span>
The only configurable item is the support of the BRPC procedure on a
PCE. The support of the BRPC procedure by the PCE MAY be controlled
by a policy module governing the conditions under which a PCE should
participate in the BRPC procedure (origin of the requests, number of
requests per second, etc.). If the BRPC is not supported/allowed on
a PCE, it MUST send a PCErr message as specified in <a href="#section-9">Section 9</a>.
<span class="h3"><a class="selflink" id="section-14.2" href="#section-14.2">14.2</a>. Information and Data Models</span>
A BRPC MIB module will be specified in a separate document.
<span class="h3"><a class="selflink" id="section-14.3" href="#section-14.3">14.3</a>. Liveness Detection and Monitoring</span>
The BRPC procedure is a multiple-PCE path computation technique and,
as such, a set of PCEs are involved in the path computation chain.
If the path computation chain is not operational either because at
least one PCE does not support the BRPC procedure or because one of
the PCEs that must be involved in the path computation chain is not
available, procedures are defined to report such failures in Sections
9 and 12, respectively. Furthermore, a built-in diagnostic tool to
check the availability and performances of a PCE chain is defined in
[<a href="#ref-PCE-MONITOR" title=""A set of monitoring tools for Path Computation Element based Architecture"">PCE-MONITOR</a>].
<span class="h3"><a class="selflink" id="section-14.4" href="#section-14.4">14.4</a>. Verifying Correct Operation</span>
Verifying the correct operation of BRPC can be performed by
monitoring a set of parameters. A BRPC implementation SHOULD provide
the following parameters:
o Number of successful BRPC procedure completions on a per-PCE-peer
basis
o Number of BRPC procedure completion failures because the VSPT flag
was not recognized (on a per-PCE-peer basis)
o Number of BRPC procedure completion failures because the BRPC
procedure was not supported (on a per-PCE-peer basis)
<span class="grey">Vasseur, 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="./rfc5441">RFC 5441</a> BRPC April 2009</span>
<span class="h3"><a class="selflink" id="section-14.5" href="#section-14.5">14.5</a>. Requirements on Other Protocols and Functional Components</span>
The BRPC procedure does not put any new requirements on other
protocols. That said, since the BRPC procedure relies on the PCEP
protocol, there is a dependency between BRPC and PCEP; consequently,
the BRPC procedure inherently makes use of the management functions
developed for PCEP.
<span class="h3"><a class="selflink" id="section-14.6" href="#section-14.6">14.6</a>. Impact on Network Operation</span>
The BRPC procedure does not have any significant impact on network
operation: indeed, BRPC is a multiple-PCE path computation scheme as
defined in [<a href="./rfc4655" title=""A Path Computation Element (PCE)-Based Architecture"">RFC4655</a>] and does not differ from any other path
computation request.
<span class="h3"><a class="selflink" id="section-14.7" href="#section-14.7">14.7</a>. Path Computation Chain Monitoring</span>
[<a id="ref-PCE-MONITOR">PCE-MONITOR</a>] specifies a set of mechanisms that can be used to
gather PCE state metrics. Because BRPC is a multiple-PCE path
computation technique, such mechanisms could be advantageously used
in the context of the BRPC procedure to check the liveness of the
path computation chain, locate a faulty component, monitor the
overall performance, and so on.
<span class="h2"><a class="selflink" id="section-15" href="#section-15">15</a>. IANA Considerations</span>
<span class="h3"><a class="selflink" id="section-15.1" href="#section-15.1">15.1</a>. New Flag of the RP Object</span>
A new flag of the RP object (specified in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>]) is defined in
this document. IANA maintains a registry of RP object flags in the
"RP Object Flag Field" sub-registry of the "Path Computation Element
Protocol (PCEP) Numbers" registry.
IANA has allocated the following value:
Bit Description Reference
25 VSPT This document
<span class="h3"><a class="selflink" id="section-15.2" href="#section-15.2">15.2</a>. New Error-Type and Error-Value</span>
IANA maintains a registry of Error-Types and Error-values for use in
PCEP messages. This is maintained as the "PCEP-ERROR Object Error
Types and Values" sub-registry of the "Path Computation Element
Protocol (PCEP) Numbers" registry.
<span class="grey">Vasseur, 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="./rfc5441">RFC 5441</a> BRPC April 2009</span>
A new Error-value is defined for the Error-Type "Not supported
object" (type 4).
Error-Type Meaning and error values Reference
4 Not supported object
Error-value=4: Unsupported parameter This document
A new Error-Type is defined in this document as follows:
Error-Type Meaning Reference
13 BRPC procedure completion failure This document
Error-value=1: BRPC procedure not This document
supported by one or more PCEs along
the domain path
<span class="h3"><a class="selflink" id="section-15.3" href="#section-15.3">15.3</a>. New Flag of the NO-PATH-VECTOR TLV</span>
A new flag of the NO-PATH-VECTOR TLV defined in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>]) is
specified in this document.
IANA maintains a registry of flags for the NO-PATH-VECTOR TLV in the
"NO-PATH-VECTOR TLV Flag Field" sub-registry of the "Path Computation
Element Protocol (PCEP) Numbers" registry.
IANA has allocated the following allocation value:
Bit number Meaning Reference
4 BRPC path computation This document
chain unavailable
<span class="h2"><a class="selflink" id="section-16" href="#section-16">16</a>. Security Considerations</span>
The BRPC procedure relies on the use of the PCEP protocol and as such
is subjected to the potential attacks listed in <a href="./rfc5440#section-10">Section 10 of
[RFC5440]</a>. In addition to the security mechanisms described in
[<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>] with regards to spoofing, snooping, falsification, and
denial of service, an implementation MAY support a policy module
governing the conditions under which a PCE should participate in the
BRPC procedure.
The BRPC procedure does not increase the information exchanged
between ASes and preserves topology confidentiality, in compliance
with [<a href="./rfc4105" title=""Requirements for Inter-Area MPLS Traffic Engineering"">RFC4105</a>] and [<a href="./rfc4216" title=""MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements"">RFC4216</a>].
<span class="grey">Vasseur, 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="./rfc5441">RFC 5441</a> BRPC April 2009</span>
<span class="h2"><a class="selflink" id="section-17" href="#section-17">17</a>. Acknowledgments</span>
The authors would like to thank Arthi Ayyangar, Dimitri
Papadimitriou, Siva Sivabalan, Meral Shirazipour, and Mach Chen for
their useful comments. A special thanks to Adrian Farrel for his
useful comments and suggestions.
<span class="h2"><a class="selflink" id="section-18" href="#section-18">18</a>. References</span>
<span class="h3"><a class="selflink" id="section-18.1" href="#section-18.1">18.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-RFC5440">RFC5440</a>] Vasseur, J., Ed. and J. Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)",
<a href="./rfc5440">RFC 5440</a>, April 2009.
<span class="h3"><a class="selflink" id="section-18.2" href="#section-18.2">18.2</a>. Informative References</span>
[<a id="ref-PATH-KEY">PATH-KEY</a>] Bradford, R., Vasseur, J., and A. Farrel, "Preserving
Topology Confidentiality in Inter-Domain Path
Computation Using a Key-Based Mechanism", Work in
Progress, November 2008.
[<a id="ref-PCE-MANAGE">PCE-MANAGE</a>] Farrel, A., "Inclusion of Manageability Sections in
PCE Working Group Drafts", Work in Progress,
January 2009.
[<a id="ref-PCE-MONITOR">PCE-MONITOR</a>] Vasseur, J., Roux, J., and Y. Ikejiri, "A set of
monitoring tools for Path Computation Element based
Architecture", Work in Progress, November 2008.
[<a id="ref-RFC2702">RFC2702</a>] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and
J. McManus, "Requirements for Traffic Engineering Over
MPLS", <a href="./rfc2702">RFC 2702</a>, September 1999.
[<a id="ref-RFC4105">RFC4105</a>] Le Roux, J., Vasseur, J., and J. Boyle, "Requirements
for Inter-Area MPLS Traffic Engineering", <a href="./rfc4105">RFC 4105</a>,
June 2005.
[<a id="ref-RFC4216">RFC4216</a>] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous
System (AS) Traffic Engineering (TE) Requirements",
<a href="./rfc4216">RFC 4216</a>, November 2005.
[<a id="ref-RFC4655">RFC4655</a>] Farrel, A., Vasseur, J., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture",
<a href="./rfc4655">RFC 4655</a>, August 2006.
<span class="grey">Vasseur, et al. Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc5441">RFC 5441</a> BRPC April 2009</span>
[<a id="ref-RFC4726">RFC4726</a>] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework
for Inter-Domain Multiprotocol Label Switching Traffic
Engineering", <a href="./rfc4726">RFC 4726</a>, November 2006.
[<a id="ref-RFC5088">RFC5088</a>] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
"OSPF Protocol Extensions for Path Computation Element
(PCE) Discovery", <a href="./rfc5088">RFC 5088</a>, January 2008.
[<a id="ref-RFC5089">RFC5089</a>] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
"IS-IS Protocol Extensions for Path Computation
Element (PCE) Discovery", <a href="./rfc5089">RFC 5089</a>, January 2008.
[<a id="ref-RFC5152">RFC5152</a>] Vasseur, JP., Ayyangar, A., 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-RFC5316">RFC5316</a>] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
Support of Inter-Autonomous System (AS) MPLS and GMPLS
Traffic Engineering", <a href="./rfc5316">RFC 5316</a>, December 2008.
[<a id="ref-RFC5392">RFC5392</a>] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in
Support of Inter-Autonomous System (AS) MPLS and GMPLS
Traffic Engineering", <a href="./rfc5392">RFC 5392</a>, January 2009.
<span class="grey">Vasseur, et al. Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc5441">RFC 5441</a> BRPC April 2009</span>
Authors' Addresses
JP Vasseur (editor)
Cisco Systems, Inc
1414 Massachusetts Avenue
Boxborough, MA 01719
USA
EMail: jpv@cisco.com
Raymond Zhang
BT Infonet
2160 E. Grand Ave.
El Segundo, CA 90025
USA
EMail: raymond.zhang@bt.com
Nabil Bitar
Verizon
117 West Street
Waltham, MA 02451
USA
EMail: nabil.n.bitar@verizon.com
JL Le Roux
France Telecom
2, Avenue Pierre-Marzin
Lannion, 22307
FRANCE
EMail: jeanlouis.leroux@orange-ftgroup.com
Vasseur, et al. Standards Track [Page 18]
</pre>
|
