1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
|
<pre>Internet Engineering Task Force (IETF) K. Kumaki, Ed.
Request for Comments: 5824 KDDI Corporation
Category: Informational R. Zhang
ISSN: 2070-1721 BT
Y. Kamite
NTT Communications Corporation
April 2010
<span class="h1">Requirements for Supporting</span>
<span class="h1">Customer Resource ReSerVation Protocol (RSVP)</span>
<span class="h1">and RSVP Traffic Engineering (RSVP-TE) over a BGP/MPLS IP-VPN</span>
Abstract
Today, customers expect to run triple-play services through BGP/MPLS
IP-VPNs. Some service providers will deploy services that request
Quality of Service (QoS) guarantees from a local Customer Edge (CE)
to a remote CE across the network. As a result, the application
(e.g., voice, video, bandwidth-guaranteed data pipe, etc.)
requirements for an end-to-end QoS and reserving an adequate
bandwidth continue to increase.
Service providers can use both an MPLS and an MPLS Traffic
Engineering (MPLS-TE) Label Switched Path (LSP) to meet their service
objectives. This document describes service-provider requirements
for supporting a customer Resource ReSerVation Protocol (RSVP) and
RSVP-TE over a BGP/MPLS IP-VPN.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc5824">http://www.rfc-editor.org/info/rfc5824</a>.
<span class="grey">Kumaki, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5824">RFC 5824</a> Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010</span>
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
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">Kumaki, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5824">RFC 5824</a> Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-4">4</a>
<a href="#section-2">2</a>. Requirements Language ...........................................<a href="#page-4">4</a>
<a href="#section-3">3</a>. Terminology .....................................................<a href="#page-5">5</a>
<a href="#section-4">4</a>. Problem Statement ...............................................<a href="#page-5">5</a>
<a href="#section-5">5</a>. Application Scenarios ...........................................<a href="#page-7">7</a>
<a href="#section-5.1">5.1</a>. Scenario I: Fast Recovery over BGP/MPLS IP-VPNs ............<a href="#page-8">8</a>
<a href="#section-5.2">5.2</a>. Scenario II: Strict C-TE LSP QoS Guarantees ................<a href="#page-8">8</a>
<a href="#section-5.3">5.3</a>. Scenario III: Load Balance of CE-to-CE Traffic .............<a href="#page-9">9</a>
<a href="#section-5.4">5.4</a>. Scenario IV: RSVP Aggregation over MPLS-TE Tunnels ........<a href="#page-11">11</a>
<a href="#section-5.5">5.5</a>. Scenario V: RSVP over Non-TE LSPs .........................<a href="#page-12">12</a>
<a href="#section-5.6">5.6</a>. Scenario VI: RSVP-TE over Non-TE LSPs .....................<a href="#page-13">13</a>
<a href="#section-6">6</a>. Detailed Requirements for C-TE LSP Model .......................<a href="#page-14">14</a>
<a href="#section-6.1">6.1</a>. Selective P-TE LSPs .......................................<a href="#page-14">14</a>
<a href="#section-6.2">6.2</a>. Graceful Restart Support for C-TE LSPs ....................<a href="#page-14">14</a>
<a href="#section-6.3">6.3</a>. Rerouting Support for C-TE LSPs ...........................<a href="#page-15">15</a>
<a href="#section-6.4">6.4</a>. FRR Support for C-TE LSPs .................................<a href="#page-15">15</a>
<a href="#section-6.5">6.5</a>. Admission Control Support on P-TE LSP Head-Ends ...........<a href="#page-15">15</a>
6.6. Admission Control Support for C-TE LSPs in
LDP-Based Core Networks ...................................<a href="#page-16">16</a>
<a href="#section-6.7">6.7</a>. Policy Control Support for C-TE LSPs ......................<a href="#page-16">16</a>
<a href="#section-6.8">6.8</a>. PCE Features Support for C-TE LSPs ........................<a href="#page-16">16</a>
<a href="#section-6.9">6.9</a>. Diversely Routed C-TE LSP Support .........................<a href="#page-16">16</a>
<a href="#section-6.10">6.10</a>. Optimal Path Support for C-TE LSPs .......................<a href="#page-17">17</a>
<a href="#section-6.11">6.11</a>. Reoptimization Support for C-TE LSPs .....................<a href="#page-17">17</a>
<a href="#section-6.12">6.12</a>. DS-TE Support for C-TE LSPs ..............................<a href="#page-17">17</a>
<a href="#section-7">7</a>. Detailed Requirements for C-RSVP Path Model ....................<a href="#page-18">18</a>
<a href="#section-7.1">7.1</a>. Admission Control between PE-CE for C-RSVP Paths ..........<a href="#page-18">18</a>
<a href="#section-7.2">7.2</a>. Aggregation of C-RSVP Paths by P-TE LSPs ..................<a href="#page-18">18</a>
<a href="#section-7.3">7.3</a>. Non-TE LSP Support for C-RSVP Paths .......................<a href="#page-18">18</a>
<a href="#section-7.4">7.4</a>. Transparency of C-RSVP Paths ..............................<a href="#page-18">18</a>
<a href="#section-8">8</a>. Commonly Detailed Requirements for Two Models ..................<a href="#page-18">18</a>
<a href="#section-8.1">8.1</a>. CE-PE Routing .............................................<a href="#page-18">18</a>
<a href="#section-8.2">8.2</a>. Complexity and Risks ......................................<a href="#page-19">19</a>
<a href="#section-8.3">8.3</a>. Backward Compatibility ....................................<a href="#page-19">19</a>
<a href="#section-8.4">8.4</a>. Scalability Considerations ................................<a href="#page-19">19</a>
<a href="#section-8.5">8.5</a>. Performance Considerations ................................<a href="#page-19">19</a>
<a href="#section-8.6">8.6</a>. Management Considerations .................................<a href="#page-20">20</a>
<a href="#section-9">9</a>. Security Considerations ........................................<a href="#page-20">20</a>
<a href="#section-10">10</a>. References ....................................................<a href="#page-21">21</a>
<a href="#section-10.1">10.1</a>. Normative References .....................................<a href="#page-21">21</a>
<a href="#section-10.2">10.2</a>. Informative References ...................................<a href="#page-22">22</a>
Acknowledgments....................................................<a href="#page-23">23</a>
<a href="#appendix-A">Appendix A</a>. Reference Model........................................<a href="#page-24">24</a>
<a href="#appendix-A.1">A.1</a> End-to-End C-RSVP Path Model................................<a href="#page-24">24</a>
<a href="#appendix-A.2">A.2</a> End-to-End C-TE LSP Model...................................<a href="#page-25">25</a>
<span class="grey">Kumaki, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5824">RFC 5824</a> Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Some service providers want to build a service that guarantees
Quality of Service (QoS) and a bandwidth from a local Customer Edge
(CE) to a remote CE through the network. A CE includes the network
client equipment owned and operated by the service provider.
However, the CE may not be part of the MPLS provider network.
Today, customers expect to run triple-play services such as Internet
access, telephone, and television through BGP/MPLS IP-VPNs [<a href="./rfc4364" title=""BGP/MPLS IP Virtual Private Networks (VPNs)"">RFC4364</a>].
As these services evolve, the requirements for an end-to-end QoS to
meet the application requirements also continue to grow. Depending
on the application (e.g., voice, video, bandwidth-guaranteed data
pipe, etc.), a native IP using an RSVP and/or an end-to-end
constrained MPLS Traffic Engineering (MPLS-TE) Label Switched Path
(LSP) may be required. The RSVP path may be used to provide QoS
guarantees and reserve an adequate bandwidth for the data. An end-
to-end MPLS-TE LSP may also be used to guarantee a bandwidth, and
provide extended functionality like MPLS fast reroute (FRR) [<a href="./rfc4090" title=""Fast Reroute Extensions to RSVP-TE for LSP Tunnels"">RFC4090</a>]
for maintaining the service continuity around node and link,
including the CE-PE link, failures. It should be noted that an RSVP
session between two CEs may also be mapped and tunneled into an MPLS-
TE LSP across an MPLS provider network.
A number of advantages exist for deploying the model previously
mentioned. The first is that customers can use these network
services while being able to use both private addresses and global
addresses. The second advantage is that the traffic is tunneled
through the service-provider backbone so that customer traffic and
route confidentiality are maintained.
This document defines a reference model, example application
scenarios, and detailed requirements for a solution supporting a
customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN.
A specification for a solution is out of scope in this document.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</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" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="grey">Kumaki, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5824">RFC 5824</a> Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Terminology</span>
This document uses the BGP/MPLS IP-VPN terminology defined in
[<a href="./rfc4364" title=""BGP/MPLS IP Virtual Private Networks (VPNs)"">RFC4364</a>] and also uses Path Computation Element (PCE) terms defined
in [<a href="./rfc4655" title=""A Path Computation Element (PCE)-Based Architecture"">RFC4655</a>].
TE LSP: Traffic Engineering Label Switched Path
MPLS-TE LSP: Multiprotocol Label Switching TE LSP
C-RSVP path: Customer RSVP path: a native RSVP path with the
bandwidth reservation of X for customers
C-TE LSP: Customer Traffic Engineering Label Switched Path: an end-
to-end MPLS-TE LSP for customers
P-TE LSP: Provider Traffic Engineering Label Switched Path: a
transport TE LSP between two Provider Edges (PEs)
LSR: a Label Switched Router
Head-end LSR: an ingress LSR
Tail-end LSR: an egress LSR
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Problem Statement</span>
Service providers want to deliver triple-play services with QoS
guarantees to their customers. Various techniques are available to
achieve this. Some service providers will wish to offer advanced
services using an RSVP signaling for native IP flows (C-RSVP) or an
RSVP-TE signaling for Customer TE LSPs (C-TE LSPs) over BGP/MPLS
IP-VPNs.
The following examples outline each method:
A C-RSVP path with the bandwidth reservation of X can be used to
transport voice traffic. In order to achieve recovery in under 50 ms
during link, node, and Shared Risk Link Group (SRLG) failures, and to
provide strict QoS guarantees, a C-TE LSP with bandwidth X between
data centers or customer sites can be used to carry voice and video
traffic. Thus, service providers or customers can choose a C-RSVP
path or a C-TE LSP to meet their requirements.
When service providers offer a C-RSVP path between hosts or CEs over
BGP/MPLS IP-VPNs, the CE/host requests an end-to-end C-RSVP path with
the bandwidth reservation of X to the remote CE/host. However, if a
C-RSVP signaling is to send within a VPN, the service-provider
<span class="grey">Kumaki, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5824">RFC 5824</a> Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010</span>
network will face scalability issues because routers need to retain
the RSVP state per a customer. Therefore, in order to solve
scalability issues, multiple C-RSVP reservations can be aggregated at
a PE, where a P-TE LSP head-end can perform admission control using
the aggregated C-RSVP reservations. The method that is described in
[<a href="./rfc4804" title=""Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels"">RFC4804</a>] can be considered as a useful approach. In this case, a
reservation request from within the context of a Virtual Routing and
Forwarding (VRF) instance can get aggregated onto a P-TE LSP. The
P-TE LSP can be pre-established, resized based on the request, or
triggered by the request. Service providers, however, cannot provide
a C-RSVP path over the VRF instance as defined in [<a href="./rfc4364" title=""BGP/MPLS IP Virtual Private Networks (VPNs)"">RFC4364</a>]. The
current BGP/MPLS IP-VPN architecture also does not support an RSVP
instance running in the context of a VRF to process RSVP messages and
integrated services (int-serv) ([<a href="./rfc1633" title=""Integrated Services in the Internet Architecture: an Overview"">RFC1633</a>], [<a href="./rfc2210" title=""The Use of RSVP with IETF Integrated Services"">RFC2210</a>]). One solution
is described in [<a href="#ref-RSVP-L3VPN" title=""Support for RSVP in Layer 3 VPNs"">RSVP-L3VPN</a>].
If service providers offer a C-TE LSP from a CE to a CE over the
BGP/MPLS IP-VPN, they require that an MPLS-TE LSP from a local CE to
a remote CE be established. However, if a C-TE LSP signaling is to
send within the VPN, the service-provider network may face the
following scalability issues:
- A C-TE LSP can be aggregated by a P-TE LSP at a PE (i.e.,
hierarchical LSPs). In this case, only a PE maintains the state of
customer RSVP sessions.
- A C-TE LSP cannot be aggregated by a P-TE LSP at a PE, depending on
some policies (i.e., continuous LSPs). In this case, both Ps and
PEs maintain the state of customer RSVP sessions.
- A C-TE LSP can be aggregated by the non-TE LSP (i.e., LDP).
In this case, only a PE maintains the state of customer RSVP-TE
sessions. Note that it is assumed that there is always enough
bandwidth available in the service-provider core network.
Furthermore, if service providers provide the C-TE LSP over the
BGP/MPLS IP-VPN, they currently cannot provide it over the VRF
instance as defined in [<a href="./rfc4364" title=""BGP/MPLS IP Virtual Private Networks (VPNs)"">RFC4364</a>]. Specifically, the current BGP/MPLS
IP-VPN architecture does not support the RSVP-TE instance running in
the context of a VRF to process RSVP messages and trigger the
establishment of the C-TE LSP over the service-provider core network.
If every C-TE LSP is to trigger the establishment or resizing of a
P-TE LSP, the service-provider network will also face scalability
issues that arise from maintaining a large number of P-TE LSPs and/or
<span class="grey">Kumaki, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5824">RFC 5824</a> Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010</span>
the dynamic signaling of these P-TE LSPs. <a href="#section-8.4">Section 8.4</a> of this
document, "Scalability Considerations", provides detailed scalability
requirements.
Two different models have been described above. The differences
between C-RSVP paths and C-TE LSPs are as follows:
- C-RSVP path model: data packets among CEs are forwarded by "native
IP packets" (i.e., not labeled packets).
- C-TE LSP model: data packets among CEs are forwarded by "labeled IP
packets".
Depending on the service level and the need to meet specific
requirements, service providers should be able to choose P-TE LSPs or
non-TE LSPs in the backbone network. The selection may be dependent
on the service provider's policy and the node's capability to support
the mechanisms described.
The items listed below are selectively required to support C-RSVP
paths and C-TE LSPs over BGP/MPLS IP-VPNs based on the service level.
For example, some service providers need all of the following items
to provide a service, and some service providers need only some of
them to provide the service. It depends on the service level and
policy of service providers. Detailed requirements are described in
Sections <a href="#section-6">6</a>, <a href="#section-7">7</a>, and <a href="#section-8">8</a>.
- C-RSVP path QoS guarantees.
- Fast recovery over the BGP/MPLS IP-VPN to protect traffic for the
C-TE LSP against CE-PE link failure and PE node failure.
- Strict C-TE LSP bandwidth and QoS guarantees.
- Resource optimization for C-RSVP paths and C-TE LSPs.
- Scalability for C-RSVP paths and C-TE LSPs.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Application Scenarios</span>
The following sections present a few application scenarios for C-RSVP
paths and C-TE LSPs in BGP/MPLS IP-VPN environments. <a href="#appendix-A">Appendix A</a>,
"Reference Model", describes a C-RSVP path, a C-TE LSP, and a
P-TE LSP.
In all scenarios, it is the responsibility of the service provider to
ensure that enough bandwidth is available to meet the customers'
application requirements.
<span class="grey">Kumaki, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5824">RFC 5824</a> Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Scenario I: Fast Recovery over BGP/MPLS IP-VPNs</span>
In this scenario, as shown in Figure 1, a customer uses a VoIP
application between its sites (i.e., between CE1 and CE2). H0 and H1
represent voice equipment.
In this case, the customer establishes C-TE LSP1 as a primary path
and C-TE LSP2 as a backup path. If the link between PE1 and CE1 or
the node of PE1 fails, C-TE LSP1 needs C-TE LSP2 as a path
protection.
Generally speaking, C-RSVP paths are used by customers, and P-TE LSPs
are used by service providers.
C-TE LSP1
<---------------------------------------------->
P-TE LSP1
<--------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|H0 | |CE1|-----|PE1|----|P1 |-----|P2 |----|PE2|-----|CE2| |H1 |.
. --- --- . --- --- --- --- . --- --- .
.........|... --- --- --- --- ...|.........
+-------|PE3|----|P3 |-----|P4 |----|PE4|-------+
--- --- --- ---
<--------------------------->
P-TE LSP2
<---------------------------------------------->
C-TE LSP2
<--customer--> <--------BGP/MPLS IP-VPN-------> <--customer->
network network
Figure 1. Scenario I
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Scenario II: Strict C-TE LSP QoS Guarantees</span>
In this scenario, as shown in Figure 2, service provider B (SP B)
transports voice and video traffic between its sites (i.e., between
CE1 and CE2). In this case, service provider B establishes C-TE LSP1
with preemption priority 0 and 100-Mbps bandwidth for the voice
traffic, and C-TE LSP2 with preemption priority 1 and 200-Mbps
bandwidth for the unicast video traffic. On the other hand, service
provider A (SP A) also pre-establishes P-TE LSP1 with preemption
priority 0 and 1-Gbps bandwidth for the voice traffic, and P-TE LSP2
with preemption priority 1 and 2-Gbps bandwidth for the video
<span class="grey">Kumaki, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5824">RFC 5824</a> Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010</span>
traffic. In this scenario, P-TE LSP1 and P-TE LSP2 should support
Diffserv-aware MPLS Traffic Engineering (DS-TE) [<a href="./rfc4124" title=""Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering"">RFC4124</a>].
PE1 and PE3 should choose an appropriate P-TE LSP based on the
preemption priority. In this case, C-TE LSP1 must be associated with
P-TE LSP1 at PE1, and C-TE LSP2 must be associated with P-TE LSP2 at
PE3.
Furthermore, PE1 and PE3 head-ends should control the bandwidth of
C-TE LSPs. In this case, PE1 and PE3 can choose C-TE LSPs by the
amount of maximum available bandwidth for each P-TE LSP,
respectively.
C-TE LSP1
<---------------------------------------------->
P-TE LSP1
<--------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|CE0| |CE1|-----|PE1|----|P1 |-----|P2 |----|PE2|-----|CE2| |CE3|.
. --- --- . --- --- --- --- . --- --- .
.........|... --- --- --- --- ...|.........
+-------|PE3|----|P3 |-----|P4 |----|PE4|-------+
--- --- --- ---
<--------------------------->
P-TE LSP2
<---------------------------------------------->
C-TE LSP2
<---SP B----> <--------BGP/MPLS IP-VPN-------> <---SP B--->
network SP A network network
Figure 2. Scenario II
It's possible that the customer and the service provider have
differing preemption priorities. In this case, the PE policy will
override the customers. In the case where the service provider does
not support preemption priorities, then such priorities should be
ignored.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Scenario III: Load Balance of CE-to-CE Traffic</span>
In this scenario, as shown in Figure 3, service provider C (SP C)
uses voice and video traffic between its sites (i.e., between CE0 and
CE5/CE7, between CE2 and CE5/CE7, between CE5 and CE0/CE2, and
between CE7 and CE0/CE2). H0 and H1 represent voice and video
equipment. In this case, service provider C establishes C-TE LSP1,
<span class="grey">Kumaki, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5824">RFC 5824</a> Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010</span>
C-TE LSP3, C-TE LSP5, and C-TE LSP7 with preemption priority 0 and
100-Mbps bandwidth for the voice traffic, and establishes C-TE LSP2,
C-TE LSP4, C-TE LSP6, and C-TE LSP8 with preemption priority 1 and
200-Mbps bandwidth for the video traffic. On the other hand, service
provider A also pre-establishes P-TE LSP1 and P-TE LSP3 with
preemption priority 0 and 1-Gbps bandwidth for the voice traffic, and
P-TE LSP2 and P-TE LSP4 with preemption priority 1 and 2-Gbps
bandwidth for the video traffic. In this scenario, P-TE LSP1,
P-TE LSP2, P-TE LSP3, and P-TE LSP4 should support DS-TE [<a href="./rfc4124" title=""Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering"">RFC4124</a>].
All PEs should choose an appropriate P-TE LSP based on the preemption
priority. To minimize the traffic disruption due to a single network
failure, diversely routed C-TE LSPs are established. In this case,
the FRR [<a href="./rfc4090" title=""Fast Reroute Extensions to RSVP-TE for LSP Tunnels"">RFC4090</a>] is not necessarily required.
Also, unconstrained TE LSPs (i.e., C-TE LSPs/P-TE LSPs with
0 bandwidth) [<a href="./rfc5330" title=""A Link-Type sub-TLV to Convey the Number of Traffic Engineering Label Switched Paths Signalled with Zero Reserved Bandwidth across a Link"">RFC5330</a>] are applicable to this scenario.
Furthermore, the load balancing for any communication between H0 and
H1 can be done by setting up full-mesh C-TE LSPs between CE0/CE2 and
CE5/CE7.
<span class="grey">Kumaki, et al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5824">RFC 5824</a> Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010</span>
C-TE LSP1(P=0),2(P=1) (CE0->CE1->...->CE4->CE5)
(CE0<-CE1<-...<-CE4<-CE5)
<---------------------------------------------->
C-TE LSP3(P=0),4(P=1) (CE2->CE1->...->CE4->CE7)
(CE2<-CE1<-...<-CE4<-CE7)
<---------------------------------------------->
P-TE LSP1 (p=0)
<-------------------->
P-TE LSP2 (p=1)
<-------------------->
.................. ..................
. --- --- . --- --- --- --- . --- --- .
. |CE0|-|CE1|--|PE1|--|P1 |---|P2 |--|PE2|--|CE4|-|CE5| .
. --- /--- --- . --- --- --- --- . --- ---\ --- .
.|H0 | + . + . + |H1 |.
. --- \--- --- . --- --- --- --- . --- ---/ --- .
. |CE2|-|CE3|--|PE3|--|P3 |---|P4 |--|PE4|--|CE6|-|CE7| .
. --- --- . --- --- --- --- . --- --- .
.................. ..................
<-------------------->
P-TE LSP3 (p=0)
<-------------------->
P-TE LSP4 (p=1)
<---------------------------------------------->
C-TE LSP5(P=0),6(P=1) (CE0->CE3->...->CE6->CE5)
(CE0<-CE3<-...<-CE6<-CE5)
<---------------------------------------------->
C-TE LSP7(P=0),8(P=1) (CE2->CE3->...->CE6->CE7)
(CE2<-CE3<-...<-CE6<-CE7)
<-----SP C-----> <----BGP/MPLS IP-VPN----> <-----SP C----->
network SP A network network
Figure 3. Scenario III
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. Scenario IV: RSVP Aggregation over MPLS-TE Tunnels</span>
In this scenario, as shown in Figure 4, the customer has two hosts
connecting to CE1 and CE2, respectively. CE1 and CE2 are connected
to PE1 and PE2, respectively, within a VRF instance belonging to the
same VPN. The requesting host (H1) may request from H2 an RSVP path
with the bandwidth reservation of X. This reservation request from
within the context of VRF will get aggregated onto a pre-established
P-TE/DS-TE LSP based upon procedures similar to [<a href="./rfc4804" title=""Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels"">RFC4804</a>]. As in the
case of [<a href="./rfc4804" title=""Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels"">RFC4804</a>], there may be multiple P-TE LSPs belonging to
different DS-TE class-types. Local policies can be implemented to
<span class="grey">Kumaki, et al. Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5824">RFC 5824</a> Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010</span>
map the incoming RSVP path request from H1 to the P-TE LSP with the
appropriate class-type. Please note that the end-to-end (e2e) RSVP
path request may also be initiated by the CE devices themselves.
C-RSVP path
<----------------------------------------------------->
P-TE LSP
<--------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|H1 | |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |H2 |.
. --- --- . --- --- --- --- . --- --- .
............. .............
^ ^
| |
VRF instance VRF instance
<-customer-> <--------BGP/MPLS IP-VPN-------> <-customer->
network network
Figure 4. Scenario IV
<span class="h3"><a class="selflink" id="section-5.5" href="#section-5.5">5.5</a>. Scenario V: RSVP over Non-TE LSPs</span>
In this scenario, as shown in Figure 5, a customer has two hosts
connecting to CE1 and CE2, respectively. CE1 and CE2 are connected
to PE1 and PE2, respectively, within a VRF instance belonging to the
same VPN. The requesting host (H1) may request from H2 an RSVP path
with the bandwidth reservation of X. In this case, a non-TE LSP
(i.e., LDP, etc.) is provided between PEs and has LDP, which supports
MPLS Diffserv [<a href="./rfc3270" title=""Multi-Protocol Label Switching (MPLS) Support of Differentiated Services"">RFC3270</a>].
Note that this only provides Diffserv, and not the bandwidth
reservation as is done with RSVP-TE.
Local policies can be implemented to map the customer's reserved flow
to the LSP with the appropriate Traffic Class [<a href="./rfc5462" title=""Multiprotocol Label Switching (MPLS) Label Stack Entry: "">RFC5462</a>] at PE1.
<span class="grey">Kumaki, et al. Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc5824">RFC 5824</a> Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010</span>
C-RSVP path
<------------------------------------------>
Non-TE LSP
<--------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|H1 | |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |H2 |.
. --- --- . --- --- --- --- . --- --- .
............. .............
^ ^
| |
VRF instance VRF instance
<-customer-> <-------BGP/MPLS IP-VPN-------> <-customer->
network network
Figure 5. Scenario V
<span class="h3"><a class="selflink" id="section-5.6" href="#section-5.6">5.6</a>. Scenario VI: RSVP-TE over Non-TE LSPs</span>
In this scenario, as shown in Figure 6, a customer uses a VoIP
application between its sites (i.e., between CE1 and CE2). H0 and H1
represent voice equipment. In this case, a non-TE LSP means LDP, and
the customer establishes C-TE LSP1 as a primary path and C-TE LSP2 as
a backup path. If the link between PE1 and CE1 or the node of PE1
fails, C-TE LSP1 needs C-TE LSP2 as a path protection.
<span class="grey">Kumaki, et al. Informational [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc5824">RFC 5824</a> Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010</span>
C-TE LSP1
<----------------------------------------->
Non-TE LSP
<-------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|H0 | |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |H1 |.
. --- --- . --- --- --- --- . --- --- .
.........|... --- --- --- --- ...|.........
+-----|PE3|----|P3 |-----|P4 |----|PE4|-----+
--- --- --- ---
<-------------------------->
Non-TE LSP
<----------------------------------------->
C-TE LSP2
<-customer-> <------BGP/MPLS IP-VPN------> <-customer->
network network
Figure 6. Scenario VI
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Detailed Requirements for the C-TE LSP Model</span>
This section describes detailed requirements for C-TE LSPs in
BGP/MPLS IP-VPN environments.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Selective P-TE LSPs</span>
The solution MUST provide the ability to decide which P-TE LSPs a PE
uses for a C-RSVP path and a C-TE LSP. When a PE receives a native
RSVP and/or a path message from a CE, it MUST be able to decide which
P-TE LSPs it uses. In this case, various kinds of P-TE LSPs exist in
the service-provider network. For example, the PE MUST choose an
appropriate P-TE LSP based on local policies such as:
1. preemption priority
2. affinity
3. class-type
4. on the data plane: (Differentiated Services Code Point (DSCP) or
Traffic Class bits)
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Graceful Restart Support for C-TE LSPs</span>
The solution SHOULD support the graceful restart capability, where
the C-TE LSP traffic continues to be forwarded during a PE graceful
restart. Graceful restart mechanisms related to this architecture
are described in [<a href="./rfc3473" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions"">RFC3473</a>], [<a href="./rfc3623" title=""Graceful OSPF Restart"">RFC3623</a>], and [<a href="./rfc4781" title=""Graceful Restart Mechanism for BGP with MPLS"">RFC4781</a>].
<span class="grey">Kumaki, et al. Informational [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc5824">RFC 5824</a> Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010</span>
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. Rerouting Support for C-TE LSPs</span>
The solution MUST provide the rerouting of a C-TE LSP in case of
link, node, and SRLG failures, or in case of preemption. Such
rerouting may be controlled by a CE or by a PE, depending on the
failure. In a dual-homed environment, the ability to perform
rerouting MUST be provided against a CE-PE link failure or a PE
failure, if another CE-PE link or PE is available between the head-
end and the tail-end of the C-TE LSP.
<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>. FRR Support for C-TE LSPs</span>
The solution MUST support FRR [<a href="./rfc4090" title=""Fast Reroute Extensions to RSVP-TE for LSP Tunnels"">RFC4090</a>] features for a C-TE LSP over
a VRF instance.
In BGP/MPLS IP-VPN environments, a C-TE LSP from a CE traverses
multiple PEs and Ps, albeit tunneled over a P-TE LSP. In order to
avoid PE-CE link/PE node/SRLG failures, a CE (a customer's head-end
router) needs to support link protection or node protection.
The following protection MUST be supported:
1. CE link protection
2. PE node protection
3. CE node protection
<span class="h3"><a class="selflink" id="section-6.5" href="#section-6.5">6.5</a>. Admission Control Support on P-TE LSP Head-Ends</span>
The solution MUST support admission control on a P-TE LSP tunnel
head-end for C-TE LSPs. C-TE LSPs may potentially try to reserve the
bandwidth that exceeds the bandwidth of the P-TE LSP. The P-TE LSP
tunnel head-end SHOULD control the number of C-TE LSPs and/or the
bandwidth of C-TE LSPs. For example, the transport TE LSP head-end
SHOULD have a configurable limit on the maximum number of C-TE LSPs
that it can admit from a CE. As for the amount of bandwidth that can
be reserved by C-TE LSPs, there could be two situations:
1. Let the P-TE LSP do its natural bandwidth admission
2. Set a cap on the amount of bandwidth, and have the configuration
option to:
a. Reserve the minimum cap bandwidth or the C-TE LSP bandwidth on
the P-TE LSP if the required bandwidth is available
b. Reject the C-TE LSP if the required bandwidth by the C-TE LSP
is not available
<span class="grey">Kumaki, et al. Informational [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc5824">RFC 5824</a> Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010</span>
<span class="h3"><a class="selflink" id="section-6.6" href="#section-6.6">6.6</a>. Admission Control Support for C-TE LSPs in LDP-Based Core</span>
<span class="h3"> Networks</span>
The solution MUST support admission control for a C-TE LSP at a PE in
the LDP-based core network. Specifically, PEs MUST have a
configurable limit on the maximum amount of bandwidth that can be
reserved by C-TE LSPs for a given VRF instance (i.e., for a given
customer). Also, a PE SHOULD have a configurable limit on the total
amount of bandwidth that can be reserved by C-TE LSPs between PEs.
<span class="h3"><a class="selflink" id="section-6.7" href="#section-6.7">6.7</a>. Policy Control Support for C-TE LSPs</span>
The solution MUST support the policy control for a C-TE LSP at a PE.
The PE MUST be able to perform the following:
1. Limit the rate of RSVP messages per CE link.
2. Accept and map, or reject, requests for a given affinity.
3. Accept and map, or reject, requests with a specified setup and/or
preemption priorities.
4. Accept or reject requests for fast reroutes.
5. Ignore the requested setup and/or preemption priorities, and
select a P-TE LSP based on a local policy that applies to the
CE-PE link or the VRF.
6. Ignore the requested affinity, and select a P-TE LSP based on a
local policy that applies to the CE-PE link or the VRF.
7. Perform mapping in the data plane between customer Traffic Class
bits and transport P-TE LSP Traffic Class bits, as signaled per
[<a href="./rfc3270" title=""Multi-Protocol Label Switching (MPLS) Support of Differentiated Services"">RFC3270</a>].
<span class="h3"><a class="selflink" id="section-6.8" href="#section-6.8">6.8</a>. PCE Features Support for C-TE LSPs</span>
The solution SHOULD support the PCE architecture for a C-TE LSP
establishment in the context of a VRF instance. When a C-TE LSP is
provided, CEs, PEs, and Ps may support PCE features ([<a href="./rfc4655" title=""A Path Computation Element (PCE)-Based Architecture"">RFC4655</a>],
[<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>]).
In this case, CE routers or PE routers may be Path Computation
Clients (PCCs), and PE routers and/or P routers may be PCEs.
Furthermore, the solution SHOULD support a mechanism for dynamic PCE
discovery. Specifically, all PCEs are not necessarily discovered
automatically, and only specific PCEs that know VPN routes should be
discovered automatically.
<span class="h3"><a class="selflink" id="section-6.9" href="#section-6.9">6.9</a>. Diversely Routed C-TE LSP Support</span>
The solution MUST provide for setting up diversely routed C-TE LSPs
over the VRF instance. These diverse C-TE LSPs MAY be traversing
<span class="grey">Kumaki, et al. Informational [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc5824">RFC 5824</a> Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010</span>
over two different P-TE LSPs that are fully disjoint within a
service-provider network. When a single CE has multiple uplinks that
connect to different PEs, it is desirable that multiple C-TE LSPs
over the VRF instance be established between a pair of LSRs. When
two CEs have multiple uplinks that connect to different PEs, it is
desirable that multiple C-TE LSPs over the VRF instance be
established between two different pairs of LSRs. In these cases, for
example, the following points will be beneficial to customers.
1. load balance of the CE-to-CE traffic across diverse C-TE LSPs so
as to minimize the traffic disruption in case of a single network
element failure
2. path protection (e.g., 1:1, 1:N)
<span class="h3"><a class="selflink" id="section-6.10" href="#section-6.10">6.10</a>. Optimal Path Support for C-TE LSPs</span>
The solution MUST support the optimal path for a C-TE LSP over the
VRF instance. Depending on an application (e.g., voice and video),
an optimal path is needed for a C-TE LSP over the VRF instance. In
the case of a TE LSP, an optimal route may be the shortest path based
on the TE metric applied. For a non-TE LSP using LDP, the IGP metric
may be used to compute optimal paths.
<span class="h3"><a class="selflink" id="section-6.11" href="#section-6.11">6.11</a>. Reoptimization Support for C-TE LSPs</span>
The solution MUST support the reoptimization of a C-TE LSP over the
VRF instance. These LSPs MUST be reoptimized using "make-before-
break" [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>].
In this case, it is desirable for a CE to be configured with regard
to the timer-based or event-driven reoptimization. Furthermore,
customers SHOULD be able to reoptimize a C-TE LSP manually. To
provide for delay-sensitive or jitter-sensitive traffic (i.e., voice
traffic), C-TE LSP path computation and route selection are expected
to be optimal for the specific application.
<span class="h3"><a class="selflink" id="section-6.12" href="#section-6.12">6.12</a>. DS-TE Support for C-TE LSPs</span>
The solution MUST support DS-TE [<a href="./rfc4124" title=""Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering"">RFC4124</a>] for a C-TE LSP over the VRF
instance. In the event that the service provider and the customer
have differing bandwidth constraint models, then only the service-
provider bandwidth model should be supported.
Applications, which have different traffic characteristics, are used
in BGP/MPLS IP-VPN environments. Service providers try to achieve
the fine-grained optimization of transmission resources, efficiency,
and further-enhanced network performance. It may be desirable to
perform TE at a per-class level.
<span class="grey">Kumaki, et al. Informational [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc5824">RFC 5824</a> Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010</span>
By mapping the traffic from a given Diffserv class of service on a
separate C-TE LSP, DS-TE allows this traffic to utilize resources
available to the given class on both shortest paths and non-shortest
paths, and also to follow paths that meet TE constraints that are
specific to the given class.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Detailed Requirements for the C-RSVP Path Model</span>
This section describes detailed requirements for C-RSVP paths in
BGP/MPLS IP-VPN environments.
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Admission Control between PE and CE for C-RSVP Paths</span>
The solution MUST support admission control at the ingress PE. PEs
MUST control RSVP messages per a VRF instance.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Aggregation of C-RSVP Paths by P-TE LSPs</span>
The solution SHOULD support C-RSVP paths aggregated by P-TE LSPs.
P-TE LSPs SHOULD be pre-established manually or dynamically by
operators and MAY be established if triggered by C-RSVP messages.
Also, the P-TE LSP SHOULD support DS-TE.
<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>. Non-TE LSP Support for C-RSVP Paths</span>
The solution SHOULD support non-TE LSPs (i.e., LDP-based LSP, etc.).
Non-TE LSPs are established by LDP [<a href="./rfc5036" title=""LDP Specification"">RFC5036</a>] between PEs and support
MPLS Diffserv [<a href="./rfc3270" title=""Multi-Protocol Label Switching (MPLS) Support of Differentiated Services"">RFC3270</a>]. The solution MAY support local policies to
map the customer's reserved flow to the LSP with the appropriate
Traffic Class at the PE.
<span class="h3"><a class="selflink" id="section-7.4" href="#section-7.4">7.4</a>. Transparency of C-RSVP Paths</span>
The solution SHOULD NOT change RSVP messages from the local CE to the
remote CE (Path, Resv, Path Error, Resv Error, etc.). The solution
SHOULD allow customers to receive RSVP messages transparently between
CE sites.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Commonly Detailed Requirements for Two Models</span>
This section describes commonly detailed requirements for C-TE LSPs
and C-RSVP paths in BGP/MPLS IP-VPN environments.
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. CE-PE Routing</span>
The solution SHOULD support the following routing configuration on
the CE-PE links with either RSVP or RSVP-TE on the CE-PE link:
<span class="grey">Kumaki, et al. Informational [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc5824">RFC 5824</a> Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010</span>
1. static routing
2. BGP routing
3. OSPF
4. OSPF-TE (RSVP-TE case only)
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Complexity and Risks</span>
The solution SHOULD avoid introducing unnecessary complexity to the
current operating network to such a degree that it would affect the
stability and diminish the benefits of deploying such a solution over
SP networks.
<span class="h3"><a class="selflink" id="section-8.3" href="#section-8.3">8.3</a>. Backward Compatibility</span>
The deployment of C-RSVP paths and C-TE LSPs SHOULD avoid impacting
existing RSVP and MPLS-TE mechanisms, respectively, but should allow
for a smooth migration or co-existence.
<span class="h3"><a class="selflink" id="section-8.4" href="#section-8.4">8.4</a>. Scalability Considerations</span>
The solution SHOULD minimize the impact on network scalability from a
C-RSVP path and a C-TE LSP over the VRF instance. As identified in
earlier sections, PCE provides a method for offloading computation of
C-TE LSPs and helps with the solution scalability.
The solution MUST address the scalability of C-RSVP paths and
C-TE LSPs for the following protocols.
1. RSVP (e.g., number of RSVP messages, retained state, etc.).
2. RSVP-TE (e.g., number of RSVP control messages, retained state,
message size, etc.).
3. BGP (e.g., number of routes, flaps, overload events, etc.).
<span class="h3"><a class="selflink" id="section-8.5" href="#section-8.5">8.5</a>. Performance Considerations</span>
The solution SHOULD be evaluated with regard to the following
criteria.
1. Degree of path optimality of the C-TE LSP.
2. TE LSP setup time.
3. Failure and restoration time.
4. Impact and scalability of the control plane due to added overhead.
5. Impact and scalability of the data/forwarding plane due to added
overhead.
<span class="grey">Kumaki, et al. Informational [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc5824">RFC 5824</a> Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010</span>
<span class="h3"><a class="selflink" id="section-8.6" href="#section-8.6">8.6</a>. Management Considerations</span>
The solution MUST address the manageability of C-RSVP paths and
C-TE LSPs for the following considerations.
1. Need for a MIB module for the control plane (including mapping of
P-TE LSPs and C-TE LSPs) and bandwidth monitoring.
2. Need for diagnostic tools (this includes traceroute and Ping).
The solution MUST allow routers to support the MIB module for C-RSVP
paths and C-TE LSPs per a VRF instance. If a CE is managed by
service providers, the solution MUST allow service providers to
collect MIB information for C-RSVP paths and C-TE LSPs from the CE
per a customer.
Diagnostic tools can detect failures of the control plane and data
plane for general MPLS-TE LSPs [<a href="./rfc4379" title=""Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures"">RFC4379</a>]. The solution MUST allow
routers to be able to detect failures of the control plane and the
data plane for C-TE LSPs over a VRF instance.
MPLS Operations, Administration, and Maintenance (OAM) for C-TE LSPs
MUST be supported within the context of VRF, except for the above.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Security Considerations</span>
Any solution should consider the following general security
requirements:
1. The solution SHOULD NOT divulge the service-provider topology
information to the customer network.
2. The solution SHOULD minimize the service-provider network's
vulnerability to Denial of Service (DoS) attacks.
3. The solution SHOULD minimize the misconfiguration of DSCP marking,
preemption, and holding priorities of the customer traffic.
The following additional security issues for C-TE LSPs relate to both
the control plane and the data plane.
In terms of the control plane, in both the C-RSVP path and C-TE LSP
models, a PE receives IPv4 or IPv6 RSVP control packets from a CE.
If the CE is a router that is not trusted by service providers, the
PE MUST be able to limit the rate and number of IPv4 or IPv6 RSVP
control packets.
In terms of the data plane, in the C-TE LSP model, a PE receives
labeled IPv4 or IPv6 data packets from a CE. If the CE is a router
that is not trusted by service providers, the PE MUST be able to
limit the rate of labeled IPv4 or IPv6 data packets. If the CE is a
<span class="grey">Kumaki, et al. Informational [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc5824">RFC 5824</a> Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010</span>
trusted router for service providers, the PE MAY be able to limit the
rate of labeled IPv4 or IPv6 data packets. Specifically, the PE must
drop MPLS-labeled packets if the MPLS label was not assigned over the
PE-CE link on which the packet was received. The PE must also be
able to police traffic to the traffic profile associated with the LSP
on which traffic is received on the PE-CE link.
Moreover, flooding RSVP/RSVP-TE control packets from malicious
customers must be avoided. Therefore, a PE MUST isolate the impact
of such customers' RSVP/RSVP-TE packets from other customers.
In the event that C-TE LSPs are diversely routed over VRF instances,
the VRF should indicate to the CE how such diversity was provided.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. References</span>
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. Normative References</span>
[<a id="ref-RFC1633">RFC1633</a>] Braden, R., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview",
<a href="./rfc1633">RFC 1633</a>, June 1994.
[<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-RFC2210">RFC2210</a>] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", <a href="./rfc2210">RFC 2210</a>, September 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-RFC3270">RFC3270</a>] Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
Vaananen, P., Krishnan, R., Cheval, P., and
J. Heinanen, "Multi-Protocol Label Switching (MPLS)
Support of Differentiated Services", <a href="./rfc3270">RFC 3270</a>,
May 2002.
[<a id="ref-RFC3473">RFC3473</a>] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
<a href="./rfc3473">RFC 3473</a>, January 2003.
[<a id="ref-RFC3623">RFC3623</a>] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful
OSPF Restart", <a href="./rfc3623">RFC 3623</a>, November 2003.
<span class="grey">Kumaki, et al. Informational [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc5824">RFC 5824</a> Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010</span>
[<a id="ref-RFC4090">RFC4090</a>] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed.,
"Fast Reroute Extensions to RSVP-TE for LSP Tunnels",
<a href="./rfc4090">RFC 4090</a>, May 2005.
[<a id="ref-RFC4124">RFC4124</a>] Le Faucheur, F., Ed., "Protocol Extensions for Support
of Diffserv-aware MPLS Traffic Engineering", <a href="./rfc4124">RFC 4124</a>,
June 2005.
[<a id="ref-RFC4364">RFC4364</a>] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", <a href="./rfc4364">RFC 4364</a>, February 2006.
[<a id="ref-RFC4379">RFC4379</a>] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", <a href="./rfc4379">RFC 4379</a>,
February 2006.
[<a id="ref-RFC4655">RFC4655</a>] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture",
<a href="./rfc4655">RFC 4655</a>, August 2006.
[<a id="ref-RFC4781">RFC4781</a>] Rekhter, Y. and R. Aggarwal, "Graceful Restart
Mechanism for BGP with MPLS", <a href="./rfc4781">RFC 4781</a>, January 2007.
[<a id="ref-RFC5036">RFC5036</a>] Andersson, L., Ed., Minei, I., Ed., and B. Thomas,
Ed., "LDP Specification", <a href="./rfc5036">RFC 5036</a>, October 2007.
[<a id="ref-RFC5462">RFC5462</a>] Andersson, L. and R. Asati, "Multiprotocol Label
Switching (MPLS) Label Stack Entry: "EXP" Field
Renamed to "Traffic Class" Field", <a href="./rfc5462">RFC 5462</a>,
February 2009.
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informative References</span>
[<a id="ref-RSVP-L3VPN">RSVP-L3VPN</a>] Davie, B., Le Faucheur, F., and A. Narayanan, "Support
for RSVP in Layer 3 VPNs", Work in Progress,
November 2009.
[<a id="ref-RFC4804">RFC4804</a>] Le Faucheur, F., Ed., "Aggregation of Resource
ReSerVation Protocol (RSVP) Reservations over MPLS
TE/DS-TE Tunnels", <a href="./rfc4804">RFC 4804</a>, February 2007.
[<a id="ref-RFC5330">RFC5330</a>] Vasseur, JP., Ed., Meyer, M., Kumaki, K., and
A. Bonda, "A Link-Type sub-TLV to Convey the Number of
Traffic Engineering Label Switched Paths Signalled
with Zero Reserved Bandwidth across a Link", <a href="./rfc5330">RFC 5330</a>,
October 2008.
<span class="grey">Kumaki, et al. Informational [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc5824">RFC 5824</a> Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010</span>
[<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.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Acknowledgments</span>
The authors would like to express thanks to Nabil Bitar,
David McDysan, and Daniel King for their helpful and useful comments
and feedback.
<span class="grey">Kumaki, et al. Informational [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc5824">RFC 5824</a> Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Reference Model</span>
In this appendix, a C-RSVP path, a C-TE LSP, and a P-TE LSP are
explained.
All scenarios in this appendix assume the following:
- A P-TE LSP is established between PE1 and PE2. This LSP is used by
the VRF instance to forward customer packets within a BGP/MPLS
IP-VPN.
- The service provider has ensured that enough bandwidth is available
to meet the service requirements.
<span class="h3"><a class="selflink" id="appendix-A.1" href="#appendix-A.1">A.1</a>. End-to-End C-RSVP Path Model</span>
A C-RSVP path and a P-TE LSP are shown in Figure 7, in the context of
a BGP/MPLS IP-VPN. A P-TE LSP may be a non-TE LSP (i.e., LDP) in
some cases. In the case of a non-TE mechanism, however, it may be
difficult to guarantee an end-to-end bandwidth, as resources are
shared.
CE0/CE1 requests an e2e C-RSVP path to CE3/CE2 with the bandwidth
reservation of X. At PE1, this reservation request received in the
context of a VRF will get aggregated onto a pre-established P-TE LSP,
or trigger the establishment of a new P-TE LSP. It should be noted
that C-RSVP sessions across different BGP/MPLS IP-VPNs can be
aggregated onto the same P-TE LSP between the same PE pair, achieving
further scalability. [<a href="./rfc4804" title=""Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels"">RFC4804</a>] defines this scenario in more detail.
The RSVP control messages (e.g., an RSVP PATH message and an RSVP
RESV message) exchanged among CEs are forwarded by IP packets through
the BGP/MPLS IP-VPN. After CE0 and/or CE1 receive a reservation
message from CE2 and/or CE3, CE0/CE1 establishes a C-RSVP path
through the BGP/MPLS IP-VPN.
<span class="grey">Kumaki, et al. Informational [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc5824">RFC 5824</a> Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010</span>
C-RSVP path
<------------------------------------------>
P-TE LSP
<--------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|CE0| |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |CE3|.
. --- --- . --- --- --- --- . --- --- .
............. .............
^ ^
| |
VRF instance VRF instance
<-customer-> <------BGP/MPLS IP-VPN------> <-customer->
network network
or or
another another
service-provider service-provider
network network
Figure 7. e2e C-RSVP Path Model
<span class="h3"><a class="selflink" id="appendix-A.2" href="#appendix-A.2">A.2</a>. End-to-End C-TE LSP Model</span>
A C-TE LSP and a P-TE LSP are shown in Figure 8, in the context of a
BGP/MPLS IP-VPN. A P-TE LSP may be a non-TE LSP (i.e., LDP) in some
cases. As described in the previous sub-section, it may be difficult
to guarantee an end-to-end QoS in some cases.
CE0/CE1 requests an e2e TE LSP path to CE3/CE2 with the bandwidth
reservation of X. At PE1, this reservation request received in the
context of a VRF will get aggregated onto a pre-established P-TE LSP,
or trigger the establishment of a new P-TE LSP. It should be noted
that C-TE LSPs across different BGP/MPLS IP-VPNs can be aggregated
onto the same P-TE LSP between the same PE pair, achieving further
scalability.
The RSVP-TE control messages (e.g., an RSVP PATH message and an RSVP
RESV message) exchanged among CEs are forwarded by a labeled packet
through the BGP/MPLS IP-VPN. After CE0 and/or CE1 receive a
reservation message from CE2 and/or CE3, CE0/CE1 establishes a
C-TE LSP through the BGP/MPLS IP-VPN.
A P-TE LSP is established between PE1 and PE2. This LSP is used by
the VRF instance to forward customer packets within the BGP/MPLS
IP-VPN.
<span class="grey">Kumaki, et al. Informational [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc5824">RFC 5824</a> Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010</span>
C-TE LSP
<------------------------------------------------------->
or
C-TE LSP
<----------------------------------------->
P-TE LSP
<--------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|CE0| |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |CE3|.
. --- --- . --- --- --- --- . --- --- .
............. .............
^ ^
| |
VRF instance VRF instance
<-customer-> <-------BGP/MPLS IP-VPN-------> <-customer->
network network
or or
another another
service-provider service-provider
network network
Figure 8. e2e C-TE LSP Model
<span class="grey">Kumaki, et al. Informational [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc5824">RFC 5824</a> Supporting RSVP/RSVP-TE over BGP/MPLS IP-VPN April 2010</span>
Authors' Addresses
Kenji Kumaki (Editor)
KDDI Corporation
Garden Air Tower
Iidabashi, Chiyoda-ku
Tokyo 102-8460, JAPAN
EMail: ke-kumaki@kddi.com
Raymond Zhang
BT
Farady Building, PP1.21
1 Knightrider Street
London EC4V 5BT
UK
EMail: raymond.zhang@bt.com
Yuji Kamite
NTT Communications Corporation
Granpark Tower
3-4-1 Shibaura, Minato-ku
Tokyo 108-8118
Japan
EMail: y.kamite@ntt.com
Kumaki, et al. Informational [Page 27]
</pre>
|
