summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4875.txt
blob: 8a76296fb28d47473cab62ebc3846b9fdd394eda (plain) (blame)
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
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
2663
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691
2692
2693
2694
2695
2696
2697
2698
2699
2700
2701
2702
2703
2704
2705
2706
2707
2708
2709
2710
2711
2712
2713
2714
2715
2716
2717
2718
2719
2720
2721
2722
2723
2724
2725
2726
2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
2746
2747
2748
2749
2750
2751
2752
2753
2754
2755
2756
2757
2758
2759
2760
2761
2762
2763
2764
2765
2766
2767
2768
2769
2770
2771
2772
2773
2774
2775
2776
2777
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791
2792
2793
2794
2795
2796
2797
2798
2799
2800
2801
2802
2803
2804
2805
2806
2807
2808
2809
2810
2811
2812
2813
2814
2815
2816
2817
2818
2819
2820
2821
2822
2823
2824
2825
2826
2827
2828
2829
2830
2831
2832
2833
2834
2835
2836
2837
2838
2839
2840
2841
2842
2843
2844
2845
2846
2847
2848
2849
2850
2851
2852
2853
2854
2855
2856
2857
2858
2859
2860
2861
2862
2863
2864
2865
2866
2867
2868
2869
2870
2871
2872
2873
2874
2875
2876
2877
2878
2879
2880
2881
2882
2883
2884
2885
2886
2887
2888
2889
2890
2891
2892
2893
2894
2895
2896
2897
2898
2899
2900
2901
2902
2903
2904
2905
2906
2907
2908
2909
2910
2911
2912
2913
2914
2915
2916
2917
2918
2919
2920
2921
2922
2923
2924
2925
2926
2927
2928
2929
2930
2931
2932
2933
2934
2935
2936
2937
2938
2939
2940
2941
2942
2943
2944
2945
2946
2947
2948
2949
2950
2951
2952
2953
2954
2955
2956
2957
2958
2959
2960
2961
2962
2963
2964
2965
2966
2967
2968
2969
2970
2971
Network Working Group                                   R. Aggarwal, Ed.
Request for Comments: 4875                              Juniper Networks
Category: Standards Track                          D. Papadimitriou, Ed.
                                                                 Alcatel
                                                        S. Yasukawa, Ed.
                                                                     NTT
                                                                May 2007


                             Extensions to
     Resource Reservation Protocol - Traffic Engineering (RSVP-TE)
         for Point-to-Multipoint TE Label Switched Paths (LSPs)

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) The IETF Trust (2007).

Abstract

   This document describes extensions to Resource Reservation Protocol -
   Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered
   (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi-
   Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
   networks.  The solution relies on RSVP-TE without requiring a
   multicast routing protocol in the Service Provider core.  Protocol
   elements and procedures for this solution are described.

   There can be various applications for P2MP TE LSPs such as IP
   multicast.  Specification of how such applications will use a P2MP TE
   LSP is outside the scope of this document.













Aggarwal, et al.            Standards Track                     [Page 1]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


Table of Contents

   1. Introduction ....................................................4
   2. Conventions Used in This Document ...............................4
   3. Terminology .....................................................4
   4. Mechanism .......................................................5
      4.1. P2MP Tunnels ...............................................5
      4.2. P2MP LSP ...................................................5
      4.3. Sub-Groups .................................................5
      4.4. S2L Sub-LSPs ...............................................6
           4.4.1. Representation of an S2L Sub-LSP ....................6
           4.4.2. S2L Sub-LSPs and Path Messages ......................7
      4.5. Explicit Routing ...........................................7
   5. Path Message ....................................................9
      5.1. Path Message Format ........................................9
      5.2. Path Message Processing ...................................11
           5.2.1. Multiple Path Messages .............................11
           5.2.2. Multiple S2L Sub-LSPs in One Path Message ..........12
           5.2.3. Transit Fragmentation of Path State Information ....14
           5.2.4. Control of Branch Fate Sharing .....................15
      5.3. Grafting ..................................................15
   6. Resv Message ...................................................16
      6.1. Resv Message Format .......................................16
      6.2. Resv Message Processing ...................................17
           6.2.1. Resv Message Throttling ............................18
      6.3. Route Recording ...........................................19
           6.3.1. RRO Processing .....................................19
      6.4. Reservation Style .........................................19
   7. PathTear Message ...............................................20
      7.1. PathTear Message Format ...................................20
      7.2. Pruning ...................................................20
           7.2.1. Implicit S2L Sub-LSP Teardown ......................20
           7.2.2. Explicit S2L Sub-LSP Teardown ......................21
   8. Notify and ResvConf Messages ...................................21
      8.1. Notify Messages ...........................................21
      8.2. ResvConf Messages .........................................23
   9. Refresh Reduction ..............................................24
   10. State Management ..............................................24
      10.1. Incremental State Update .................................25
      10.2. Combining Multiple Path Messages .........................25
   11. Error Processing ..............................................26
      11.1. PathErr Messages .........................................27
      11.2. ResvErr Messages .........................................27
      11.3. Branch Failure Handling ..................................28
   12. Admin Status Change ...........................................29
   13. Label Allocation on LANs with Multiple Downstream Nodes .......29





Aggarwal, et al.            Standards Track                     [Page 2]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


   14. P2MP LSP and Sub-LSP Re-Optimization ..........................29
      14.1. Make-before-Break ........................................29
      14.2. Sub-Group-Based Re-Optimization ..........................29
   15. Fast Reroute ..................................................30
      15.1. Facility Backup ..........................................31
           15.1.1. Link Protection ...................................31
           15.1.2. Node Protection ...................................31
      15.2. One-to-One Backup ........................................32
   16. Support for LSRs That Are Not P2MP Capable ....................33
   17. Reduction in Control Plane Processing with LSP Hierarchy ......34
   18. P2MP LSP Re-Merging and Cross-Over ............................35
      18.1. Procedures ...............................................36
           18.1.1. Re-Merge Procedures ...............................36
   19. New and Updated Message Objects ...............................39
      19.1. SESSION Object ...........................................39
           19.1.1. P2MP LSP Tunnel IPv4 SESSION Object ...............39
           19.1.2. P2MP LSP Tunnel IPv6 SESSION Object ...............40
      19.2. SENDER_TEMPLATE Object ...................................40
           19.2.1. P2MP LSP Tunnel IPv4 SENDER_TEMPLATE Object .......41
           19.2.2. P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object .......42
      19.3. S2L_SUB_LSP Object .......................................43
           19.3.1. S2L_SUB_LSP IPv4 Object ...........................43
           19.3.2. S2L_SUB_LSP IPv6 Object ...........................43
      19.4. FILTER_SPEC Object .......................................43
           19.4.1. P2MP LSP_IPv4 FILTER_SPEC Object ..................43
           19.4.2. P2MP LSP_IPv6 FILTER_SPEC Object ..................44
      19.5. P2MP SECONDARY_EXPLICIT_ROUTE Object (SERO) ..............44
      19.6. P2MP SECONDARY_RECORD_ROUTE Object (SRRO) ................44
   20. IANA Considerations ...........................................44
      20.1. New Class Numbers ........................................44
      20.2. New Class Types ..........................................44
      20.3. New Error Values .........................................45
      20.4. LSP Attributes Flags .....................................46
   21. Security Considerations .......................................46
   22. Acknowledgements ..............................................47
   23. References ....................................................47
      23.1. Normative References .....................................47
      23.2. Informative References ...................................48
   Appendix A. Example of P2MP LSP Setup .............................49
   Appendix B. Contributors ..........................................50











Aggarwal, et al.            Standards Track                     [Page 3]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


1.  Introduction

   [RFC3209] defines a mechanism for setting up point-to-point (P2P)
   Traffic Engineered (TE) Label Switched Paths (LSPs) in Multi-Protocol
   Label Switching (MPLS) networks.  [RFC3473] defines extensions to
   [RFC3209] for setting up P2P TE LSPs in Generalized MPLS (GMPLS)
   networks.  However these specifications do not provide a mechanism
   for building point-to-multipoint (P2MP) TE LSPs.

   This document defines extensions to the RSVP-TE protocol ([RFC3209]
   and [RFC3473]) to support P2MP TE LSPs satisfying the set of
   requirements described in [RFC4461].

   This document relies on the semantics of the Resource Reservation
   Protocol (RSVP) that RSVP-TE inherits for building P2MP LSPs.  A P2MP
   LSP is comprised of multiple source-to-leaf (S2L) sub-LSPs.  These
   S2L sub-LSPs are set up between the ingress and egress LSRs and are
   appropriately combined by the branch LSRs using RSVP semantics to
   result in a P2MP TE LSP.  One Path message may signal one or multiple
   S2L sub-LSPs for a single P2MP LSP.  Hence the S2L sub-LSPs belonging
   to a P2MP LSP can be signaled using one Path message or split across
   multiple Path messages.

   There are various applications for P2MP TE LSPs and the signaling
   techniques described in this document can be used, sometimes in
   combination with other techniques, to support different applications.

   Specification of how applications will use P2MP TE LSPs and how the
   paths of P2MP TE LSPs are computed is outside the scope of this
   document.

2.  Conventions Used in This Document

   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 RFC 2119 [RFC2119].

3.  Terminology

   This document uses terminologies defined in [RFC2205], [RFC3031],
   [RFC3209], [RFC3473], [RFC4090], and [RFC4461].










Aggarwal, et al.            Standards Track                     [Page 4]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


4.  Mechanism

   This document describes a solution that optimizes data replication by
   allowing non-ingress nodes in the network to be replication/branch
   nodes.  A branch node is an LSR that replicates the incoming data on
   to one or more outgoing interfaces.  The solution relies on RSVP-TE
   in the network for setting up a P2MP TE LSP.

   The P2MP TE LSP is set up by associating multiple S2L sub-LSPs and
   relying on data replication at branch nodes.  This is described
   further in the following sub-sections by describing P2MP tunnels and
   how they relate to S2L sub-LSPs.

4.1.  P2MP Tunnels

   The defining feature of a P2MP TE LSP is the action required at
   branch nodes where data replication occurs.  Incoming MPLS labeled
   data is replicated to outgoing interfaces which may use different
   labels for the data.

   A P2MP TE Tunnel comprises one or more P2MP LSPs.  A P2MP TE Tunnel
   is identified by a P2MP SESSION object.  This object contains the
   identifier of the P2MP Session, which includes the P2MP Identifier
   (P2MP ID), a tunnel Identifier (Tunnel ID), and an extended tunnel
   identifier (Extended Tunnel ID).  The P2MP ID is a four-octet number
   and is unique within the scope of the ingress LSR.

   The <P2MP ID, Tunnel ID, Extended Tunnel ID> tuple provides an
   identifier for the set of destinations of the P2MP TE Tunnel.

   The fields of the P2MP SESSION object are identical to those of the
   SESSION object defined in [RFC3209] except that the Tunnel Endpoint
   Address field is replaced by the P2MP ID field.  The P2MP SESSION
   object is defined in section 19.1

4.2.  P2MP LSP

   A P2MP LSP is identified by the combination of the P2MP ID, Tunnel
   ID, and Extended Tunnel ID that are part of the P2MP SESSION object,
   and the tunnel sender address and LSP ID fields of the P2MP
   SENDER_TEMPLATE object.  The new P2MP SENDER_TEMPLATE object is
   defined in section 19.2.

4.3.  Sub-Groups

   As with all other RSVP controlled LSPs, P2MP LSP state is managed
   using RSVP messages.  While the use of RSVP messages is the same,
   P2MP LSP state differs from P2P LSP state in a number of ways.  A



Aggarwal, et al.            Standards Track                     [Page 5]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


   P2MP LSP comprises multiple S2L Sub-LSPs, and as a result of this, it
   may not be possible to represent full state in a single IP packet.
   It must also be possible to efficiently add and remove endpoints to
   and from P2MP TE LSPs.  An additional issue is that the P2MP LSP must
   also handle the state "re-merge" problem, see [RFC4461] and section
   18.

   These differences in P2MP state are addressed through the addition of
   a sub-group identifier (Sub-Group ID) and sub-group originator (Sub-
   Group Originator ID) to the SENDER_TEMPLATE and FILTER_SPEC objects.
   Taken together, the Sub-Group ID and Sub-Group Originator ID are
   referred to as the Sub-Group fields.

   The Sub-Group fields, together with the rest of the SENDER_TEMPLATE
   and SESSION objects, are used to represent a portion of a P2MP LSP's
   state.  This portion of a P2MP LSP's state refers only to signaling
   state and not data plane replication or branching.  For example, it
   is possible for a node to "branch" signaling state for a P2MP LSP,
   but to not branch the data associated with the P2MP LSP.  Typical
   applications for generation and use of multiple sub-groups are (1)
   addition of an egress and (2) semantic fragmentation to ensure that a
   Path message remains within a single IP packet.

4.4.  S2L Sub-LSPs

   A P2MP LSP is constituted of one or more S2L sub-LSPs.

4.4.1.  Representation of an S2L Sub-LSP

   An S2L sub-LSP exists within the context of a P2MP LSP.  Thus, it is
   identified by the P2MP ID, Tunnel ID, and Extended Tunnel ID that are
   part of the P2MP SESSION, the tunnel sender address and LSP ID fields
   of the P2MP SENDER_TEMPLATE object, and the S2L sub-LSP destination
   address that is part of the S2L_SUB_LSP object.  The S2L_SUB_LSP
   object is defined in section 19.3.

   An EXPLICIT_ROUTE Object (ERO) or P2MP_SECONDARY_EXPLICIT_ROUTE
   Object (SERO) is used to optionally specify the explicit route of a
   S2L sub-LSP.  Each ERO or SERO that is signaled corresponds to a
   particular S2L_SUB_LSP object.  Details of explicit route encoding
   are specified in section 4.5.  The SECONDARY_EXPLICIT_ROUTE Object is
   defined in [RFC4873], a new P2MP SECONDARY_EXPLICIT_ROUTE Object
   C-type is defined in section 19.5, and a matching
   P2MP_SECONDARY_RECORD_ROUTE Object C-type is defined in section 19.6.







Aggarwal, et al.            Standards Track                     [Page 6]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


4.4.2.  S2L Sub-LSPs and Path Messages

   The mechanism in this document allows a P2MP LSP to be signaled using
   one or more Path messages.  Each Path message may signal one or more
   S2L sub-LSPs.  Support for multiple Path messages is desirable as one
   Path message may not be large enough to contain all the S2L sub-LSPs;
   and they also allow separate manipulation of sub-trees of the P2MP
   LSP.  The reason for allowing a single Path message to signal
   multiple S2L sub-LSPs is to optimize the number of control messages
   needed to set up a P2MP LSP.

4.5.  Explicit Routing

   When a Path message signals a single S2L sub-LSP (that is, the Path
   message is only targeting a single leaf in the P2MP tree), the
   EXPLICIT_ROUTE object encodes the path to the egress LSR.  The Path
   message also includes the S2L_SUB_LSP object for the S2L sub-LSP
   being signaled.  The < [<EXPLICIT_ROUTE>], <S2L_SUB_LSP> > tuple
   represents the S2L sub-LSP and is referred to as the sub-LSP
   descriptor.  The absence of the ERO should be interpreted as
   requiring hop-by-hop routing for the sub-LSP based on the S2L sub-LSP
   destination address field of the S2L_SUB_LSP object.

   When a Path message signals multiple S2L sub-LSPs, the path of the
   first S2L sub-LSP to the egress LSR is encoded in the ERO.  The first
   S2L sub-LSP is the one that corresponds to the first S2L_SUB_LSP
   object in the Path message.  The S2L sub-LSPs corresponding to the
   S2L_SUB_LSP objects that follow are termed as subsequent S2L sub-
   LSPs.

   The path of each subsequent S2L sub-LSP is encoded in a
   P2MP_SECONDARY_EXPLICIT_ROUTE object (SERO).  The format of the SERO
   is the same as an ERO (as defined in [RFC3209] and [RFC3473]).  Each
   subsequent S2L sub-LSP is represented by tuples of the form < [<P2MP
   SECONDARY_EXPLICIT_ROUTE>], <S2L_SUB_LSP> >.  An SERO for a
   particular S2L sub-LSP includes only the path from a branch LSR to
   the egress LSR of that S2L sub-LSP.  The branch MUST appear as an
   explicit hop in the ERO or some other SERO.  The absence of an SERO
   should be interpreted as requiring hop-by-hop routing for that S2L
   sub-LSP.  Note that the destination address is carried in the S2L
   sub-LSP object.  The encoding of the SERO and S2L_SUB_LSP object is
   described in detail in section 19.

   In order to avoid the potential repetition of path information for
   the parts of S2L sub-LSPs that share hops, this information is
   deduced from the explicit routes of other S2L sub-LSPs using explicit
   route compression in SEROs.




Aggarwal, et al.            Standards Track                     [Page 7]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


                                    A
                                    |
                                    |
                                    B
                                    |
                                    |
                          C----D----E
                          |    |    |
                          |    |    |
                          F    G    H-------I
                               |    |\      |
                               |    | \     |
                               J    K   L   M
                               |    |   |   |
                               |    |   |   |
                               N    O   P   Q--R

                  Figure 1.  Explicit Route Compression

   Figure 1 shows a P2MP LSP with LSR A as the ingress LSR and six
   egress LSRs: (F, N, O, P, Q and R).  When all six S2L sub-LSPs are
   signaled in one Path message, let us assume that the S2L sub-LSP to
   LSR F is the first S2L sub-LSP, and the rest are subsequent S2L sub-
   LSPs.  The following encoding is one way for the ingress LSR A to
   encode the S2L sub-LSP explicit routes using compression:

      S2L sub-LSP-F:   ERO = {B, E, D, C, F},  <S2L_SUB_LSP> object-F
      S2L sub-LSP-N:   SERO = {D, G, J, N}, <S2L_SUB_LSP> object-N
      S2L sub-LSP-O:   SERO = {E, H, K, O}, <S2L_SUB_LSP> object-O
      S2L sub-LSP-P:   SERO = {H, L, P}, <S2L_SUB_LSP> object-P
      S2L sub-LSP-Q:   SERO = {H, I, M, Q}, <S2L_SUB_LSP> object-Q
      S2L sub-LSP-R:   SERO = {Q, R}, <S2L_SUB_LSP> object-R

   After LSR E processes the incoming Path message from LSR B it sends a
   Path message to LSR D with the S2L sub-LSP explicit routes encoded as
   follows:

      S2L sub-LSP-F:   ERO = {D, C, F},  <S2L_SUB_LSP> object-F
      S2L sub-LSP-N:   SERO = {D, G, J, N}, <S2L_SUB_LSP> object-N

   LSR E also sends a Path message to LSR H, and the following is one
   way to encode the S2L sub-LSP explicit routes using compression:

      S2L sub-LSP-O:   ERO = {H, K, O}, <S2L_SUB_LSP> object-O
      S2L sub-LSP-P:   SERO = {H, L, P}, S2L_SUB_LSP object-P
      S2L sub-LSP-Q:   SERO = {H, I, M, Q}, <S2L_SUB_LSP> object-Q
      S2L sub-LSP-R:   SERO = {Q, R}, <S2L_SUB_LSP> object-R




Aggarwal, et al.            Standards Track                     [Page 8]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


   After LSR H processes the incoming Path message from E, it sends a
   Path message to LSR K, LSR L, and LSR I.  The encoding for the Path
   message to LSR K is as follows:

      S2L sub-LSP-O:   ERO  = {K, O}, <S2L_SUB_LSP> object-O

   The encoding of the Path message sent by LSR H to LSR L is as
   follows:

      S2L sub-LSP-P:   ERO = {L, P}, <S2L_SUB_LSP> object-P

   The following encoding is one way for LSR H to encode the S2L sub-LSP
   explicit routes in the Path message sent to LSR I:

      S2L sub-LSP-Q:   ERO = {I, M, Q}, <S2L_SUB_LSP> object-Q
      S2L sub-LSP-R:   SERO = {Q, R}, <S2L_SUB_LSP> object-R

   The explicit route encodings in the Path messages sent by LSRs D and
   Q are left as an exercise for the reader.

   This compression mechanism reduces the Path message size.  It also
   reduces extra processing that can result if explicit routes are
   encoded from ingress to egress for each S2L sub-LSP.  No assumptions
   are placed on the ordering of the subsequent S2L sub-LSPs and hence
   on the ordering of the SEROs in the Path message.  All LSRs need to
   process the ERO corresponding to the first S2L sub-LSP.  An LSR needs
   to process an S2L sub-LSP descriptor for a subsequent S2L sub-LSP
   only if the first hop in the corresponding SERO is a local address of
   that LSR.  The branch LSR that is the first hop of an SERO propagates
   the corresponding S2L sub-LSP downstream.

5.  Path Message

5.1.  Path Message Format

   This section describes modifications made to the Path message format
   as specified in [RFC3209] and [RFC3473].  The Path message is
   enhanced to signal one or more S2L sub-LSPs.  This is done by
   including the S2L sub-LSP descriptor list in the Path message as
   shown below.











Aggarwal, et al.            Standards Track                     [Page 9]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


   <Path Message> ::=     <Common Header> [ <INTEGRITY> ]
                          [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ...]
                          [ <MESSAGE_ID> ]
                          <SESSION> <RSVP_HOP>
                          <TIME_VALUES>
                          [ <EXPLICIT_ROUTE> ]
                          <LABEL_REQUEST>
                          [ <PROTECTION> ]
                          [ <LABEL_SET> ... ]
                          [ <SESSION_ATTRIBUTE> ]
                          [ <NOTIFY_REQUEST> ]
                          [ <ADMIN_STATUS> ]
                          [ <POLICY_DATA> ... ]
                          <sender descriptor>
                          [<S2L sub-LSP descriptor list>]

   The following is the format of the S2L sub-LSP descriptor list.

   <S2L sub-LSP descriptor list> ::= <S2L sub-LSP descriptor>
                                     [ <S2L sub-LSP descriptor list> ]

   <S2L sub-LSP descriptor> ::= <S2L_SUB_LSP>
                                [ <P2MP SECONDARY_EXPLICIT_ROUTE> ]

   Each LSR MUST use the common objects in the Path message and the S2L
   sub-LSP descriptors to process each S2L sub-LSP represented by the
   S2L_SUB_LSP object and the SECONDARY-/EXPLICIT_ROUTE object
   combination.

   Per the definition of <S2L sub-LSP descriptor>, each S2L_SUB_LSP
   object MAY be followed by a corresponding SERO.  The first
   S2L_SUB_LSP object is a special case, and its explicit route is
   specified by the ERO.  Therefore, the first S2L_SUB_LSP object SHOULD
   NOT be followed by an SERO, and if one is present, it MUST be
   ignored.

   The RRO in the sender descriptor contains the upstream hops traversed
   by the Path message and applies to all the S2L sub-LSPs signaled in
   the Path message.

   An IF_ID RSVP_HOP object MUST be used on links where there is not a
   one-to-one association of a control channel to a data channel
   [RFC3471].  An RSVP_HOP object defined in [RFC2205] SHOULD be used
   otherwise.

   Path message processing is described in the next section.





Aggarwal, et al.            Standards Track                    [Page 10]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


5.2.  Path Message Processing

   The ingress LSR initiates the setup of an S2L sub-LSP to each egress
   LSR that is a destination of the P2MP LSP.  Each S2L sub-LSP is
   associated with the same P2MP LSP using common P2MP SESSION object
   and <Sender Address, LSP-ID> fields in the P2MP SENDER_TEMPLATE
   object.  Hence, it can be combined with other S2L sub-LSPs to form a
   P2MP LSP.  Another S2L sub-LSP belonging to the same instance of this
   S2L sub-LSP (i.e., the same P2MP LSP) SHOULD share resources with
   this S2L sub-LSP.  The session corresponding to the P2MP TE tunnel is
   determined based on the P2MP SESSION object.  Each S2L sub-LSP is
   identified using the S2L_SUB_LSP object.  Explicit routing for the
   S2L sub-LSPs is achieved using the ERO and SEROs.

   As mentioned earlier, it is possible to signal S2L sub-LSPs for a
   given P2MP LSP in one or more Path messages, and a given Path message
   can contain one or more S2L sub-LSPs.  An LSR that supports RSVP-TE
   signaled P2MP LSPs MUST be able to receive and process multiple Path
   messages for the same P2MP LSP and multiple S2L sub-LSPs in one Path
   message.  This implies that such an LSR MUST be able to receive and
   process all objects listed in section 19.

5.2.1.  Multiple Path Messages

   As described in section 4, either the < [<EXPLICIT_ROUTE>]
   <S2L_SUB_LSP> > or the < [<P2MP SECONDARY_EXPLICIT_ROUTE>]
   <S2L_SUB_LSP> > tuple is used to specify an S2L sub-LSP.  Multiple
   Path messages can be used to signal a P2MP LSP.  Each Path message
   can signal one or more S2L sub-LSPs.  If a Path message contains only
   one S2L sub-LSP, each LSR along the S2L sub-LSP follows [RFC3209]
   procedures for processing the Path message besides the S2L_SUB_LSP
   object processing described in this document.

   Processing of Path messages containing more than one S2L sub-LSP is
   described in section 5.2.2.

   An ingress LSR MAY use multiple Path messages for signaling a P2MP
   LSP.  This may be because a single Path message may not be large
   enough to signal the P2MP LSP.  Or it may be that when new leaves are
   added to the P2MP LSP, they are signaled in a new Path message.  Or
   an ingress LSR MAY choose to break the P2MP tree into separate
   manageable P2MP trees.  These trees share the same root and may share
   the trunk and certain branches.  The scope of this management
   decomposition of P2MP trees is bounded by a single tree (the P2MP
   Tree) and multiple trees with a single leaf each (S2L sub-LSPs).  Per
   [RFC4461], a P2MP LSP MUST have consistent attributes across all
   portions of a tree.  This implies that each Path message that is used
   to signal a P2MP LSP is signaled using the same signaling attributes



Aggarwal, et al.            Standards Track                    [Page 11]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


   with the exception of the S2L sub-LSP descriptors and Sub-Group
   identifier.

   The resulting sub-LSPs from the different Path messages belonging to
   the same P2MP LSP SHOULD share labels and resources where they share
   hops to prevent multiple copies of the data being sent.

   In certain cases, a transit LSR may need to generate multiple Path
   messages to signal state corresponding to a single received Path
   message.  For instance ERO expansion may result in an overflow of the
   resultant Path message.  In this case, the message can be decomposed
   into multiple Path messages such that each message carries a subset
   of the X2L sub-tree carried by the incoming message.

   Multiple Path messages generated by an LSR that signal state for the
   same P2MP LSP are signaled with the same SESSION object and have the
   same <Source address, LSP-ID> in the SENDER_TEMPLATE object.  In
   order to disambiguate these Path messages, a <Sub-Group Originator
   ID, Sub- Group ID> tuple is introduced (also referred to as the Sub-
   Group fields) and encoded in the SENDER_TEMPLATE object.  Multiple
   Path messages generated by an LSR to signal state for the same P2MP
   LSP have the same Sub-Group Originator ID and have a different sub-
   Group ID.  The Sub-Group Originator ID MUST be set to the TE Router
   ID of the LSR that originates the Path message.  Cases when a transit
   LSR may change the Sub-Group Originator ID of an incoming Path
   message are described below.  The Sub-Group Originator ID is globally
   unique.  The Sub-Group ID space is specific to the Sub-Group
   Originator ID.

5.2.2.  Multiple S2L Sub-LSPs in One Path Message

   The S2L sub-LSP descriptor list allows the signaling of one or more
   S2L sub-LSPs in one Path message.  Each S2L sub-LSP descriptor
   describes a single S2L sub-LSP.

   All LSRs MUST process the ERO corresponding to the first S2L sub-LSP
   if the ERO is present.  If one or more SEROs are present, an ERO MUST
   be present.  The first S2L sub-LSP MUST be propagated in a Path
   message by each LSR along the explicit route specified by the ERO, if
   the ERO is present.  Else it MUST be propagated using hop-by-hop
   routing towards the destination identified by the S2L_SUB_LSP object.

   An LSR MUST process an S2L sub-LSP descriptor for a subsequent S2L
   sub-LSP as follows:

   If the S2L_SUB_LSP object is followed by an SERO, the LSR MUST check
   the first hop in the SERO:




Aggarwal, et al.            Standards Track                    [Page 12]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


      - If the first hop of the SERO identifies a local address of the
        LSR, and the LSR is also the egress identified by the
        S2L_SUB_LSP object, the descriptor MUST NOT be propagated
        downstream, but the SERO may be used for egress control per
        [RFC4003].

      - If the first hop of the SERO identifies a local address of the
        LSR, and the LSR is not the egress as identified by the
        S2L_SUB_LSP object, the S2L sub-LSP descriptor MUST be included
        in a Path message sent to the next-hop determined from the SERO.

      - If the first hop of the SERO is not a local address of the LSR,
        the S2L sub-LSP descriptor MUST be included in the Path message
        sent to the LSR that is the next hop to reach the first hop in
        the SERO.  This next hop is determined by using the ERO or other
        SEROs that encode the path to the SERO's first hop.

   If the S2L_SUB_LSP object is not followed by an SERO, the LSR MUST
   examine the S2L_SUB_LSP object:

      - If this LSR is the egress as identified by the S2L_SUB_LSP
        object, the S2L sub-LSP descriptor MUST NOT be propagated
        downstream.

      - If this LSR is not the egress as identified by the S2L_SUB_LSP
        object, the LSR MUST make a routing decision to determine the
        next hop towards the egress, and MUST include the S2L sub-LSP
        descriptor in a Path message sent to the next-hop towards the
        egress.  In this case, the LSR MAY insert an SERO into the S2L
        sub-LSP descriptor.

   Hence, a branch LSR MUST only propagate the relevant S2L sub-LSP
   descriptors to each downstream hop.  An S2L sub-LSP descriptor list
   that is propagated on a downstream link MUST only contain those S2L
   sub-LSPs that are routed using that hop.  This processing MAY result
   in a subsequent S2L sub-LSP in an incoming Path message becoming the
   first S2L sub-LSP in an outgoing Path message.

   Note that if one or more SEROs contain loose hops, expansion of such
   loose hops MAY result in overflowing the Path message size.  section
   5.2.3 describes how signaling of the set of S2L sub-LSPs can be split
   across more than one Path message.

   The RECORD_ROUTE Object (RRO) contains the hops traversed by the Path
   message and applies to all the S2L sub-LSPs signaled in the Path
   message.  A transit LSR MUST append its address in an incoming RRO
   and propagate it downstream.  A branch LSR MUST form a new RRO for
   each of the outgoing Path messages by copying the RRO from the



Aggarwal, et al.            Standards Track                    [Page 13]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


   incoming Path message and appending its address.  Each such updated
   RRO MUST be formed using the rules in [RFC3209] (and updated by
   [RFC3473]), as appropriate.

   If an LSR is unable to support an S2L sub-LSP in a Path message (for
   example, it is unable to route towards the destination using the
   SERO), a PathErr message MUST be sent for the impacted S2L sub-LSP,
   and normal processing of the rest of the P2MP LSP SHOULD continue.
   The default behavior is that the remainder of the LSP is not impacted
   (that is, all other branches are allowed to set up) and the failed
   branches are reported in PathErr messages in which the
   Path_State_Removed flag MUST NOT be set.  However, the ingress LSR
   may set an LSP Integrity flag to request that if there is a setup
   failure on any branch, the entire LSP should fail to set up.  This is
   described further in sections 5.2.4 and 11.

5.2.3.  Transit Fragmentation of Path State Information

   In certain cases, a transit LSR may need to generate multiple Path
   messages to signal state corresponding to a single received Path
   message.  For instance, ERO expansion may result in an overflow of
   the resultant Path message.  RSVP [RFC2205] disallows the use of IP
   fragmentation, and thus IP fragmentation MUST be avoided in this
   case.  In order to achieve this, the multiple Path messages generated
   by the transit LSR are signaled with the Sub-Group Originator ID set
   to the TE Router ID of the transit LSR and with a distinct Sub-Group
   ID for each Path message.  Thus, each distinct Path message that is
   generated by the transit LSR for the P2MP LSP carries a distinct
   <Sub-Group Originator ID, Sub-Group ID> tuple.

   When multiple Path messages are used by an ingress or transit node,
   each Path message SHOULD be identical with the exception of the S2L
   sub-LSP related descriptor (e.g., SERO), message and hop information
   (e.g., INTEGRITY, MESSAGE_ID, and RSVP_HOP), and the Sub-Group fields
   of the SENDER_TEMPLATE objects.  Except when a make-before-break
   operation is being performed (as specified in section 14.1), the
   tunnel sender address and LSP ID fields MUST be the same in each
   message.  For transit nodes, they MUST be the same as the values in
   the received Path message.

   As described above, one case in which the Sub-Group Originator ID of
   a received Path message is changed is that of fragmentation of a Path
   message at a transit node.  Another case is when the Sub-Group
   Originator ID of a received Path message may be changed in the
   outgoing Path message and set to that of the LSR originating the Path
   message based on a local policy.  For instance, an LSR may decide to





Aggarwal, et al.            Standards Track                    [Page 14]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


   always change the Sub-Group Originator ID while performing ERO
   expansion.  The Sub-Group ID MUST not be changed if the Sub-Group
   Originator ID is not changed.

5.2.4.  Control of Branch Fate Sharing

   An ingress LSR can control the behavior of an LSP if there is a
   failure during LSP setup or after an LSP has been established.  The
   default behavior is that only the branches downstream of the failure
   are not established, but the ingress may request 'LSP integrity' such
   that any failure anywhere within the LSP tree causes the entire P2MP
   LSP to fail.

   The ingress LSP may request 'LSP integrity' by setting bit 3 of the
   Attributes Flags TLV.  The bit is set if LSP integrity is required.

   It is RECOMMENDED to use the LSP_REQUIRED_ATTRIBUTES object
   [RFC4420].

   A branch LSR that supports the Attributes Flags TLV and recognizes
   this bit MUST support LSP integrity or reject the LSP setup with a
   PathErr message carrying the error "Routing Error"/"Unsupported LSP
   Integrity".

5.3.  Grafting

   The operation of adding egress LSR(s) to an existing P2MP LSP is
   termed grafting.  This operation allows egress nodes to join a P2MP
   LSP at different points in time.

   There are two methods to add S2L sub-LSPs to a P2MP LSP.  The first
   is to add new S2L sub-LSPs to the P2MP LSP by adding them to an
   existing Path message and refreshing the entire Path message.  Path
   message processing described in section 4 results in adding these S2L
   sub-LSPs to the P2MP LSP.  Note that as a result of adding one or
   more S2L sub-LSPs to a Path message, the ERO compression encoding may
   have to be recomputed.

   The second is to use incremental updates described in section 10.1.
   The egress LSRs can be added by signaling only the impacted S2L sub-
   LSPs in a new Path message.  Hence, other S2L sub-LSPs do not have to
   be re-signaled.









Aggarwal, et al.            Standards Track                    [Page 15]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


6.  Resv Message

6.1.  Resv Message Format

   The Resv message follows the [RFC3209] and [RFC3473] format:

   <Resv Message> ::=    <Common Header> [ <INTEGRITY> ]
                         [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
                         [ <MESSAGE_ID> ]
                         <SESSION> <RSVP_HOP>
                         <TIME_VALUES>
                         [ <RESV_CONFIRM> ]  [ <SCOPE> ]
                         [ <NOTIFY_REQUEST> ]
                         [ <ADMIN_STATUS> ]
                         [ <POLICY_DATA> ... ]
                         <STYLE> <flow descriptor list>

   <flow descriptor list> ::= <FF flow descriptor list>
                              | <SE flow descriptor>

   <FF flow descriptor list> ::= <FF flow descriptor>
                                 | <FF flow descriptor list>
                                 <FF flow descriptor>

   <SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>

   <SE filter spec list> ::= <SE filter spec>
                            | <SE filter spec list> <SE filter spec>

   The FF flow descriptor and SE filter spec are modified as follows to
   identify the S2L sub-LSPs that they correspond to:

   <FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
                            [ <RECORD_ROUTE> ]
                            [ <S2L sub-LSP flow descriptor list> ]

   <SE filter spec> ::=     <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
                            [ <S2L sub-LSP flow descriptor list> ]

   <S2L sub-LSP flow descriptor list> ::=
                               <S2L sub-LSP flow descriptor>
                               [ <S2L sub-LSP flow descriptor list> ]

   <S2L sub-LSP flow descriptor> ::= <S2L_SUB_LSP>
                                     [ <P2MP_SECONDARY_RECORD_ROUTE> ]

   FILTER_SPEC is defined in section 19.4.




Aggarwal, et al.            Standards Track                    [Page 16]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


   The S2L sub-LSP flow descriptor has the same format as S2L sub-LSP
   descriptor in section 4.1 with the difference that a
   P2MP_SECONDARY_RECORD_ROUTE object is used in place of a P2MP
   SECONDARY_EXPLICIT_ROUTE object.  The P2MP_SECONDARY_RECORD_ROUTE
   objects follow the same compression mechanism as the P2MP
   SECONDARY_EXPLICIT_ROUTE objects.  Note that a Resv message can
   signal multiple S2L sub-LSPs that may belong to the same FILTER_SPEC
   object or different FILTER_SPEC objects.  The same label SHOULD be
   allocated if the <Sender Address, LSP-ID> fields of the FILTER_SPEC
   object are the same.

   However different labels MUST be allocated if the <Sender Address,
   LSP-ID> of the FILTER_SPEC object is different, as that implies that
   the FILTER_SPEC refers to a different P2MP LSP.

6.2.  Resv Message Processing

   The egress LSR MUST follow normal RSVP procedures while originating a
   Resv message.  The format of Resv messages is as defined in section
   6.1.  As usual, the Resv message carries the label allocated by the
   egress LSR.

   A node upstream of the egress node MUST allocate its own label and
   pass it upstream in the Resv message.  The node MAY combine multiple
   flow descriptors, from different Resv messages received from
   downstream, in one Resv message sent upstream.  A Resv message MUST
   NOT be sent upstream until at least one Resv message has been
   received from a downstream neighbor.  When the integrity bit is set
   in the LSP_REQUIRED_ATTRIBUTE object, Resv message MUST NOT be sent
   upstream until all Resv messages have been received from the
   downstream neighbors.

   Each Fixed-Filter (FF) flow descriptor or Shared-Explicit (SE) filter
   spec sent upstream in a Resv message includes an S2L sub-LSP
   descriptor list.  Each such FF flow descriptor or SE filter spec for
   the same P2MP LSP (whether on one or multiple Resv messages) on the
   same Resv MUST be allocated the same label, and FF flow descriptors
   or SE filter specs SHOULD use the same label across multiple Resv
   messages.

   The node that sends the Resv message, for a P2MP LSP, upstream MUST
   associate the label assigned by this node with all the labels
   received from downstream Resv messages, for that P2MP LSP.  Note that
   a transit node may become a replication point in the future when a
   branch is attached to it.  Hence, this results in the setup of a P2MP
   LSP from the ingress LSR to the egress LSRs.





Aggarwal, et al.            Standards Track                    [Page 17]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


   The ingress LSR may need to understand when all desired egresses have
   been reached.  This is achieved using S2L_SUB_LSP objects.

   Each branch node MAY forward a single Resv message upstream for each
   received Resv message from a downstream receiver.  Note that there
   may be a large number of Resv messages at and close to the ingress
   LSR for an LSP with many receivers.  A branch LSR SHOULD combine Resv
   state from multiple receivers into a single Resv message to be sent
   upstream (see section 6.2.1).  However, note that this may result in
   overflowing the Resv message, particularly as the number of receivers
   downstream of any branch LSR increases as the LSR is closer to the
   ingress LSR.  Thus, a branch LSR MAY choose to send more than one
   Resv message upstream and partition the Resv state between the
   messages.

   When a transit node sets the Sub-Group Originator field in a Path
   message, it MUST replace the Sub-Group fields received in the
   FILTER_SPEC objects of any associated Resv messages with the value
   that it originally received in the Sub-Group fields of the Path
   message from the upstream neighbor.

   ResvErr message generation is unmodified.  Nodes propagating a
   received ResvErr message MUST use the Sub-Group field values carried
   in the corresponding Resv message.

6.2.1.  Resv Message Throttling

   A branch node may have to send a revised Resv message upstream
   whenever there is a change in a Resv message for an S2L sub-LSP
   received from one of the downstream neighbors.  This can result in
   excessive Resv messages sent upstream, particularly when the S2L sub-
   LSPs are first established.  In order to mitigate this situation,
   branch nodes can limit their transmission of Resv messages.
   Specifically, in the case where the only change being sent in a Resv
   message is in one or more P2MP_SECONDARY_RECORD_ROUTE objects
   (SRROs), the branch node SHOULD transmit the Resv message only after
   a delay time has passed since the transmission of the previous Resv
   message for the same session.  This delayed Resv message SHOULD
   include SRROs for all branches.  A suggested value for the delay time
   is thirty seconds, and delay times SHOULD generally be longer than 1
   second.  Specific mechanisms for Resv message throttling and delay
   timer settings are implementation dependent and are outside the scope
   of this document.








Aggarwal, et al.            Standards Track                    [Page 18]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


6.3.  Route Recording

6.3.1.  RRO Processing

   A Resv message for a P2P LSP contains a recorded route if the ingress
   LSR requested route recording by including an RRO in the original
   Path message.  The same rule is used during signaling of P2MP LSPs.
   That is, inclusion of an RRO in the Path message used to signal one
   or more S2L sub-LSPs triggers the inclusion of a recorded route for
   each sub-LSP in the Resv message.

   The recorded route of the first S2L sub-LSP is encoded in the RRO.
   Additional recorded routes for the subsequent S2L sub-LSPs are
   encoded in P2MP_SECONDARY_RECORD_ROUTE objects (SRROs).  Their format
   is specified in section 19.5.  Each S2L_SUB_LSP object in a Resv is
   associated with an RRO or SRRO.  The first S2L_SUB_LSP object (for
   the first S2L sub-LSP) is associated with the RRO.  Subsequent
   S2L_SUB_LSP objects (for subsequent S2L sub-LSPs) are each followed
   by an SRRO that contains the recorded route for that S2L sub-LSP from
   the leaf to a branch.  The ingress node can then use the RRO and
   SRROs to determine the end-to-end path for each S2L sub-LSP.

6.4.  Reservation Style

   Considerations about the reservation style in a Resv message apply as
   described in [RFC3209].  The reservation style in the Resv messages
   can be either FF or SE.  All P2MP LSPs that belong to the same P2MP
   Tunnel MUST be signaled with the same reservation style.
   Irrespective of whether the reservation style is FF or SE, the S2L
   sub-LSPs that belong to the same P2MP LSP SHOULD share labels where
   they share hops.  If the S2L sub-LSPs that belong to the same P2MP
   LSP share labels then they MUST share resources.  If the reservation
   style is FF, then S2L sub-LSPs that belong to different P2MP LSPs
   MUST NOT share resources or labels.  If the reservation style is SE,
   then S2L sub-LSPs that belong to different P2MP LSPs and the same
   P2MP tunnel SHOULD share resources where they share hops, but they
   MUST not share labels in packet environments.














Aggarwal, et al.            Standards Track                    [Page 19]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


7.  PathTear Message

7.1.  PathTear Message Format

   The format of the PathTear message is as follows:

   <PathTear Message> ::= <Common Header> [ <INTEGRITY> ]
                           [ [ <MESSAGE_ID_ACK> |
                               <MESSAGE_ID_NACK> ... ]
                           [ <MESSAGE_ID> ]
                           <SESSION> <RSVP_HOP>
                           [ <sender descriptor> ]
                           [ <S2L sub-LSP descriptor list> ]

   <S2L sub-LSP descriptor list> ::= <S2L_SUB_LSP>
                                     [ <S2L sub-LSP descriptor list> ]

   The definition of <sender descriptor> is not changed by this
   document.

7.2.  Pruning

   The operation of removing egress LSR(s) from an existing P2MP LSP is
   termed as pruning.  This operation allows egress nodes to be removed
   from a P2MP LSP at different points in time.  This section describes
   the mechanisms to perform pruning.

7.2.1.  Implicit S2L Sub-LSP Teardown

   Implicit teardown uses standard RSVP message processing.  Per
   standard RSVP processing, an S2L sub-LSP may be removed from a P2MP
   TE LSP by sending a modified message for the Path or Resv message
   that previously advertised the S2L sub-LSP.  This message MUST list
   all S2L sub-LSPs that are not being removed.  When using this
   approach, a node processing a message that removes an S2L sub-LSP
   from a P2MP TE LSP MUST ensure that the S2L sub-LSP is not included
   in any other Path state associated with session before interrupting
   the data path to that egress.  All other message processing remains
   unchanged.

   When implicit teardown is used to delete one or more S2L sub-LSPs, by
   modifying a Path message, a transit LSR may have to generate a
   PathTear message downstream to delete one or more of these S2L sub-
   LSPs.  This can happen if as a result of the implicit deletion of S2L
   sub-LSP(s) there are no remaining S2L sub-LSPs to send in the
   corresponding Path message downstream.





Aggarwal, et al.            Standards Track                    [Page 20]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


7.2.2.  Explicit S2L Sub-LSP Teardown

   Explicit S2L Sub-LSP teardown relies on generating a PathTear message
   for the corresponding Path message.  The PathTear message is signaled
   with the SESSION and SENDER_TEMPLATE objects corresponding to the
   P2MP LSP and the <Sub-Group Originator ID, Sub-Group ID> tuple
   corresponding to the Path message.  This approach SHOULD be used when
   all the egresses signaled by a Path message need to be removed from
   the P2MP LSP.  Other S2L sub-LSPs, from other sub-groups signaled
   using other Path messages, are not affected by the PathTear.

   A transit LSR that propagates the PathTear message downstream MUST
   ensure that it sets the <Sub-Group Originator ID, Sub-Group ID> tuple
   in the PathTear message to the values used in the Path message that
   was used to set up the S2L sub-LSPs being torn down.  The transit LSR
   may need to generate multiple PathTear messages for an incoming
   PathTear message if it had performed transit fragmentation for the
   corresponding incoming Path message.

   When a P2MP LSP is removed by the ingress, a PathTear message MUST be
   generated for each Path message used to signal the P2MP LSP.

8.  Notify and ResvConf Messages

8.1.  Notify Messages

   The Notify Request object and Notify message are described in
   [RFC3473].  Both object and message SHALL be supported for delivery
   of upstream and downstream notification.  Processing not detailed in
   this section MUST comply to [RFC3473].

   1.  Upstream Notification

   If a transit LSR sets the Sub-Group Originator ID in the
   SENDER_TEMPLATE object of a Path message to its own address, and the
   incoming Path message carries a Notify Request object, then this LSR
   MUST change the Notify node address in the Notify Request object to
   its own address in the Path message that it sends.

   If this LSR subsequently receives a corresponding Notify message from
   a downstream LSR, then it MUST:

      - send a Notify message upstream toward the Notify node address
        that the LSR received in the Path message.







Aggarwal, et al.            Standards Track                    [Page 21]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


      - process the Sub-Group fields of the SENDER_TEMPLATE object on
        the received Notify message, and modify their values, in the
        Notify message that is forwarded, to match the Sub-Group field
        values in the original Path message received from upstream.

   The receiver of an (upstream) Notify message MUST identify the state
   referenced in this message based on the SESSION and SENDER_TEMPLATE.

   2.  Downstream Notification

   A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC
   object(s) of a Resv message to the value that was received in the
   corresponding Path message.  If the incoming Resv message carries a
   Notify Request object, then:

      - If there is at least another incoming Resv message that carries
        a Notify Request object, and the LSR merges these Resv messages
        into a single Resv message that is sent upstream, the LSR MUST
        set the Notify node address in the Notify Request object to its
        Router ID.

      - Else if the LSR sets the Sub-Group Originator ID (in the
        outgoing Path message that corresponds to the received Resv
        message) to its own address, the LSR MUST set the Notify node
        address in the Notify Request object to its Router ID.

      - Else the LSR MUST propagate the Notify Request object unchanged,
        in the Resv message that it sends upstream.

   If this LSR subsequently receives a corresponding Notify message from
   an upstream LSR, then it MUST:

      - process the Sub-Group fields of the FILTER_SPEC object in the
        received Notify message, and modify their values, in the Notify
        message that is forwarded, to match the Sub-Group field values
        in the original Path message sent downstream by this LSR.

      - send a Notify message downstream toward the Notify node address
        that the LSR received in the Resv message.

   The receiver of a (downstream) Notify message MUST identify the state
   referenced in the message based on the SESSION and FILTER_SPEC
   objects.

   The consequence of these rules for a P2MP LSP is that an upstream
   Notify message generated on a branch will result in a Notify being
   delivered to the upstream Notify node address.  The receiver of the
   Notify message MUST NOT assume that the Notify message applies to all



Aggarwal, et al.            Standards Track                    [Page 22]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


   downstream egresses, but MUST examine the information in the message
   to determine to which egresses the message applies.

   Downstream Notify messages MUST be replicated at branch LSRs
   according to the Notify Request objects received on Resv messages.
   Some downstream branches might not request Notify messages, but all
   that have requested Notify messages MUST receive them.

8.2.  ResvConf Messages

   ResvConf messages are described in [RFC2205].  ResvConf processing in
   [RFC3473] and [RFC3209] is taken directly from [RFC2205].  An egress
   LSR MAY include a RESV_CONFIRM object that contains the egress LSR's
   address.  The object and message SHALL be supported for the
   confirmation of receipt of the Resv message in P2MP TE LSPs.
   Processing not detailed in this section MUST comply to [RFC2205].

   A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC
   object(s) of a Resv message to the value that was received in the
   corresponding Path message.  If any of the incoming Resv messages
   corresponding to a single Path message carry a RESV_CONFIRM object,
   then the LSR MUST include a RESV_CONFIRM object in the corresponding
   Resv message that it sends upstream.  If the Sub-Group Originator ID
   is its own address, then it MUST set the receiver address in the
   RESV_CONFIRM object to this address, else it MUST propagate the
   object unchanged.

   A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC
   object(s) of a Resv message to the value that was received in the
   corresponding Path message.  If an incoming Resv message
   corresponding to a single Path message carries a RESV_CONFIRM object,
   then the LSR MUST include a RESV_CONFIRM object in the corresponding
   Resv message that it sends upstream and:

      - If there is at least another incoming Resv message that carries
        a RESV_CONFIRM object, and the LSR merges these Resv messages
        into a single Resv message that is sent upstream, the LSR MUST
        set the receiver address in the RESV_CONFIRM object to its
        Router ID.

      - If the LSR sets the Sub-Group Originator ID (in the outgoing
        Path message that corresponds to the received Resv message) to
        its own address, the LSR MUST set the receiver address in the
        RESV_CONFIRM object to its Router ID.

      - Else the LSR MUST propagate the RESV_CONFIRM object unchanged,
        in the Resv message that it sends upstream.




Aggarwal, et al.            Standards Track                    [Page 23]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


   If this LSR subsequently receives a corresponding ResvConf message
   from an upstream LSR, then it MUST:

      - process the Sub-Group fields of the FILTER_SPEC object in the
        received ResvConf message, and modify their values, in the
        ResvConf message that is forwarded, to match the Sub-Group field
        values in the original Path message sent downstream by this LSR.

      - send a ResvConf message downstream toward the receiver address
        that the LSR received in the RESV_CONFIRM object in the Resv
        message.

   The receiver of a ResvConf message MUST identify the state referenced
   in this message based on the SESSION and FILTER_SPEC objects.

   The consequence of these rules for a P2MP LSP is that a ResvConf
   message generated at the ingress will result in a ResvConf message
   being delivered to the branch and then to the receiver address in the
   original RESV_CONFIRM object.  The receiver of a ResvConf message
   MUST NOT assume that the ResvConf message should be sent to all
   downstream egresses, but it MUST replicate the message according to
   the RESV_CONFIRM objects received in Resv messages.  Some downstream
   branches might not request ResvConf messages, and ResvConf messages
   SHOULD NOT be sent on these branches.  All downstream branches that
   requested ResvConf messages MUST be sent such a message.

9.  Refresh Reduction

   The refresh reduction procedures described in [RFC2961] are equally
   applicable to P2MP LSPs described in this document.  Refresh
   reduction applies to individual messages and the state they
   install/maintain, and that continues to be the case for P2MP LSPs.

10.  State Management

   State signaled by a P2MP Path message is identified by a local
   implementation using the <P2MP ID, Tunnel ID, Extended Tunnel ID>
   tuple as part of the SESSION object and the <Tunnel Sender Address,
   LSP ID, Sub-Group Originator ID, Sub-Group ID> tuple as part of the
   SENDER_TEMPLATE object.

   Additional information signaled in the Path/Resv message is part of
   the state created by a local implementation.  This includes PHOP/NHOP
   and SENDER_TSPEC/FILTER_SPEC objects.







Aggarwal, et al.            Standards Track                    [Page 24]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


10.1.  Incremental State Update

   RSVP (as defined in [RFC2205] and as extended by RSVP-TE [RFC3209]
   and GMPLS [RFC3473]) uses the same basic approach to state
   communication and synchronization -- namely, full state is sent in
   each state advertisement message.  Per [RFC2205], Path and Resv
   messages are idempotent.  Also, [RFC2961] categorizes RSVP messages
   into two types (trigger and refresh messages) and improves RSVP
   message handling and scaling of state refreshes, but does not modify
   the full state advertisement nature of Path and Resv messages.  The
   full state advertisement nature of Path and Resv messages has many
   benefits, but also has some drawbacks.  One notable drawback is when
   an incremental modification is being made to a previously advertised
   state.  In this case, there is the message overhead of sending the
   full state and the cost of processing it.  It is desirable to
   overcome this drawback and add/delete S2L sub-LSPs to/from a P2MP LSP
   by incrementally updating the existing state.

   It is possible to use the procedures described in this document to
   allow S2L sub-LSPs to be incrementally added to or deleted from the
   P2MP LSP by allowing a Path or a PathTear message to incrementally
   change the existing P2MP LSP Path state.

   As described in section 5.2, multiple Path messages can be used to
   signal a P2MP LSP.  The Path messages are distinguished by different
   <Sub-Group Originator ID, Sub-Group ID> tuples in the SENDER_TEMPLATE
   object.  In order to perform incremental S2L sub-LSP state addition,
   a separate Path message with a new Sub-Group ID is used to add the
   new S2L sub-LSPs, by the ingress LSR.  The Sub-Group Originator ID
   MUST be set to the TE Router ID [RFC3477] of the node that sets the
   Sub-Group ID.

   This maintains the idempotent nature of RSVP Path messages, avoids
   keeping track of individual S2L sub-LSP state expiration, and
   provides the ability to perform incremental P2MP LSP state updates.

10.2.  Combining Multiple Path Messages

   There is a tradeoff between the number of Path messages used by the
   ingress to maintain the P2MP LSP and the processing imposed by full
   state messages when adding S2L sub-LSPs to an existing Path message.
   It is possible to combine S2L sub-LSPs previously advertised in
   different Path messages in a single Path message in order to reduce
   the number of Path messages needed to maintain the P2MP LSP.  This
   can also be done by a transit node that performed fragmentation and
   that at a later point is able to combine multiple Path messages that
   it generated into a single Path message.  This may happen when one or
   more S2L sub-LSPs are pruned from the existing Path states.



Aggarwal, et al.            Standards Track                    [Page 25]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


   The new Path message is signaled by the node that is combining
   multiple Path messages with all the S2L sub-LSPs that are being
   combined in a single Path message.  This Path message MAY contain new
   Sub-Group ID field values.  When a new Path and Resv message that is
   signaled for an existing S2L sub-LSP is received by a transit LSR,
   state including the new instance of the S2L sub-LSP is created.

   The S2L sub-LSP SHOULD continue to be advertised in both the old and
   new Path messages until a Resv message listing the S2L sub-LSP and
   corresponding to the new Path message is received by the combining
   node.  Hence, until this point, state for the S2L sub-LSP SHOULD be
   maintained as part of the Path state for both the old and the new
   Path message (see section 3.1.3 of [RFC2205]).  At that point the S2L
   sub-LSP SHOULD be deleted from the old Path state using the
   procedures of section 7.

   A Path message with a Sub-Group_ID(n) may signal a set of S2L sub-
   LSPs that belong partially or entirely to an already existing Sub-
   Group_ID(i), or a strictly non-overlapping new set of S2L sub-LSPs.
   A newly received Path message that matches SESSION object and Sender
   Tunnel Address, LSP ID, Sub-Group Originator ID> with existing Path
   state carrying the same or different Sub-Group_ID, referred to Sub-
   Group_ID(n) is processed as follows:

   1) If Sub-Group_ID(i) = Sub-Group_ID(n), then S2L Sub-LSPs that are
      in both Sub-Group_ID(i) and Sub-Group_ID(n) are refreshed.  New
      S2L Sub-LSPs are added to Sub-Group_ID(i) Path state and S2L Sub-
      LSPs that are in Sub-Group_ID(i) but not in Sub-Group_ID(n) are
      deleted from the Sub-Group_ID(i) Path state.

   2) If Sub-Group_ID(i) != Sub-Group_ID(n), then a new Sub-Group_ID(n)
      Path state is created for S2L Sub-LSPs signaled by Sub-
      Group_ID(n).  S2L Sub-LSPs in existing Sub-Group_IDs(i) Path state
      (that are or are not in the newly received Path message Sub-
      Group_ID(n)) are left unmodified (see above).

11.  Error Processing

   PathErr and ResvErr messages are processed as per RSVP-TE procedures.
   Note that an LSR, on receiving a PathErr/ResvErr message for a
   particular S2L sub-LSP, changes the state only for that S2L sub-LSP.
   Hence other S2L sub-LSPs are not impacted.  If the ingress node
   requests 'LSP integrity', an error reported on a branch of a P2MP TE
   LSP for a particular S2L sub-LSP may change the state of any other
   S2L sub-LSP of the same P2MP TE LSP.  This is explained further in
   section 11.3.





Aggarwal, et al.            Standards Track                    [Page 26]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


11.1.  PathErr Messages

   The PathErr message will include one or more S2L_SUB_LSP objects.
   The resulting modified format for a PathErr message is:

   <PathErr Message> ::=    <Common Header> [ <INTEGRITY> ]
                             [ [<MESSAGE_ID_ACK> |
                                <MESSAGE_ID_NACK>] ... ]
                             [ <MESSAGE_ID> ]
                             <SESSION> <ERROR_SPEC>
                             [ <ACCEPTABLE_LABEL_SET> ... ]
                             [ <POLICY_DATA> ... ]
                             <sender descriptor>
                             [ <S2L sub-LSP descriptor list> ]

   PathErr message generation is unmodified, but nodes that set the
   Sub-Group Originator field and propagate a received PathErr message
   upstream MUST replace the Sub-Group fields received in the PathErr
   message with the value that was received in the Sub-Group fields of
   the Path message from the upstream neighbor.  Note the receiver of a
   PathErr message is able to identify the errored outgoing Path
   message, and outgoing interface, based on the Sub-Group fields
   received in the PathErr message.  The S2L sub-LSP descriptor list is
   defined in section 5.1.

11.2.  ResvErr Messages

   The ResvErr message will include one or more S2L_SUB_LSP objects.
   The resulting modified format for a ResvErr Message is:

   <ResvErr Message> ::=    <Common Header> [ <INTEGRITY> ]
                             [ [<MESSAGE_ID_ACK> |
                                <MESSAGE_ID_NACK>] ... ]
                             [ <MESSAGE_ID> ]
                             <SESSION> <RSVP_HOP>
                             <ERROR_SPEC> [ <SCOPE> ]
                             [ <ACCEPTABLE_LABEL_SET> ... ]
                             [ <POLICY_DATA> ... ]
                             <STYLE> <flow descriptor list>

   ResvErr message generation is unmodified, but nodes that set the
   Sub-Group Originator field and propagate a received ResvErr message
   downstream MUST replace the Sub-Group fields received in the ResvErr
   message with the value that was set in the Sub-Group fields of the
   Path message sent to the downstream neighbor.  Note the receiver of a
   ResvErr message is able to identify the errored outgoing Resv





Aggarwal, et al.            Standards Track                    [Page 27]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


   message, and outgoing interface, based on the Sub-Group fields
   received in the ResvErr message.  The flow descriptor list is defined
   in section 6.1.

11.3.  Branch Failure Handling

   During setup and during normal operation, PathErr messages may be
   received at a branch node.  In all cases, a received PathErr message
   is first processed per standard processing rules.  That is, the
   PathErr message is sent hop-by-hop to the ingress/branch LSR for that
   Path message.  Intermediate nodes until this ingress/branch LSR MAY
   inspect this message but take no action upon it.  The behavior of a
   branch LSR that generates a PathErr message is under the control of
   the ingress LSR.

   The default behavior is that the PathErr message does not have the
   Path_State_Removed flag set.  However, if the ingress LSR has set the
   LSP integrity flag on the Path message (see LSP_REQUIRED_ATTRIBUTEs
   object in section 5.2.4), and if the Path_State_Removed flag is
   supported, the LSR generating a PathErr to report the failure of a
   branch of the P2MP LSP SHOULD set the Path_State_Removed flag.

   A branch LSR that receives a PathErr message during LSP setup with
   the Path_State_Removed flag set MUST act according to the wishes of
   the ingress LSR.  The default behavior is that the branch LSR clears
   the Path_State_Removed flag on the PathErr and sends it further
   upstream.  It does not tear any other branches of the LSP.  However,
   if the LSP integrity flag is set on the Path message, the branch LSR
   MUST send PathTear on all other downstream branches and send the
   PathErr message upstream with the Path_State_Removed flag set.

   A branch LSR that receives a PathErr message with the
   Path_State_Removed flag clear MUST act according to the wishes of the
   ingress LSR.  The default behavior is that the branch LSR forwards
   the PathErr upstream and takes no further action.  However, if the
   LSP integrity flag is set on the Path message, the branch LSR MUST
   send PathTear on all downstream branches and send the PathErr
   upstream with the Path_State_Removed flag set (per [RFC3473]).

   In all cases, the PathErr message forwarded by a branch LSR MUST
   contain the S2L sub-LSP identification and explicit routes of all
   branches that are reported by received PathErr messages and all
   branches that are explicitly torn by the branch LSR.








Aggarwal, et al.            Standards Track                    [Page 28]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


12.  Admin Status Change

   A branch node that receives an ADMIN_STATUS object processes it
   normally and also relays the ADMIN_STATUS object in a Path on every
   branch.  All Path messages may be concurrently sent to the downstream
   neighbors.

   Downstream nodes process the change in the ADMIN_STATUS object per
   [RFC3473], including generation of Resv messages.  When the last
   received upstream ADMIN_STATUS object had the R bit set, branch nodes
   wait for a Resv message with a matching ADMIN_STATUS object to be
   received (or a corresponding PathErr or ResvTear message) on all
   branches before relaying a corresponding Resv message upstream.

13.  Label Allocation on LANs with Multiple Downstream Nodes

   A branch LSR of a P2MP LSP on an Ethernet LAN segment SHOULD send one
   copy of the data traffic per downstream LSR connected on that LAN for
   that P2MP LSP.  Procedures for preventing MPLS labeled traffic
   replication in such a case is beyond the scope of this document.

14.  P2MP LSP and Sub-LSP Re-Optimization

   It is possible to change the path used by P2MP LSPs to reach the
   destinations of the P2MP tunnel.  There are two methods that can be
   used to accomplish this.  The first is make-before-break, defined in
   [RFC3209], and the second uses the sub-groups defined above.

14.1.  Make-before-Break

   In this case, all the S2L sub-LSPs are signaled with a different LSP
   ID by the ingress LSR and follow the make-before-break procedure
   defined in [RFC3209].  Thus, a new P2MP LSP is established.  Each S2L
   sub-LSP is signaled with a different LSP ID, corresponding to the new
   P2MP LSP.  After moving traffic to the new P2MP LSP, the ingress can
   tear down the old P2MP LSP.  This procedure can be used to re-
   optimize the path of the entire P2MP LSP or the paths to a subset of
   the destinations of the P2MP LSP.  When modifying just a portion of
   the P2MP LSP, this approach requires the entire P2MP LSP to be re-
   signaled.

14.2.  Sub-Group-Based Re-Optimization

   Any node may initiate re-optimization of a set of S2L sub-LSPs by
   using incremental state update and then, optionally, combining
   multiple path messages.





Aggarwal, et al.            Standards Track                    [Page 29]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


   To alter the path taken by a particular set of S2L sub-LSPs, the node
   initiating the path change initiates one or more separate Path
   messages for the same P2MP LSP, each with a new sub-Group ID.  The
   generation of these Path messages, each with one or more S2L sub-
   LSPs, follows procedures in section 5.2.  As is the case in section
   10.2, a particular egress continues to be advertised in both the old
   and new Path messages until a Resv message listing the egress and
   corresponding to the new Path message is received by the re-
   optimizing node.  At that point, the egress SHOULD be deleted from
   the old Path state using the procedures of section 7.  Sub-tree re-
   optimization is then completed.

   Sub-Group-based re-optimization may result in transient data
   duplication as the new Path messages for a set of S2L sub-LSPs may
   transit one or more nodes with the old Path state for the same set of
   S2L sub-LSPs.

   As is always the case, a node may choose to combine multiple path
   messages as described in section 10.2.

15.  Fast Reroute

   [RFC4090] extensions can be used to perform fast reroute for the
   mechanism described in this document when applied within packet
   networks.  GMPLS introduces other protection techniques that can be
   applied to packet and non-packet environments [RFC4873], but which
   are not discussed further in this document.  This section only
   applies to LSRs that support [RFC4090].

   This section uses terminology defined in [RFC4090], and fast reroute
   procedures defined in [RFC4090] MUST be followed unless specified
   below.  The head-end and transit LSRs MUST follow the
   SESSION_ATTRIBUTE and FAST_REROUTE object processing as specified in
   [RFC4090] for each Path message and S2L sub-LSP of a P2MP LSP.  Each
   S2L sub-LSP of a P2MP LSP MUST have the same protection
   characteristics.  The RRO processing MUST apply to SRRO as well
   unless modified below.

   The sections that follow describe how fast reroute may be applied to
   P2MP MPLS TE LSPs in all of the principal operational scenarios.
   This document does not describe the detailed processing steps for
   every imaginable usage case, and they may be described in future
   documents, as needed.








Aggarwal, et al.            Standards Track                    [Page 30]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


15.1.  Facility Backup

   Facility backup can be used for link or node protection of LSRs on
   the path of a P2MP LSP.  The downstream labels MUST be learned by the
   Point of Local Repair (PLR), as specified in [RFC4090], from the
   label corresponding to the S2L sub-LSP in the RESV message.
   Processing of SEROs signaled in a backup tunnel MUST follow backup
   tunnel ERO processing described in [RFC4090].

15.1.1.  Link Protection

   If link protection is desired, a bypass tunnel MUST be used to
   protect the link between the PLR and next-hop.  Thus all S2L sub-LSPs
   that use the link SHOULD be protected in the event of link failure.
   Note that all such S2L sub-LSPs belonging to a particular instance of
   a P2MP tunnel SHOULD share the same outgoing label on the link
   between the PLR and the next-hop as per section 5.2.1.  This is the
   P2MP LSP label on the link.  Label stacking is used to send data for
   each P2MP LSP into the bypass tunnel.  The inner label is the P2MP
   LSP label allocated by the next-hop.

   During failure, Path messages for each S2L sub-LSP that is affected,
   MUST be sent to the Merge Point (MP) by the PLR.  It is RECOMMENDED
   that the PLR uses the sender template-specific method to identify
   these Path messages.  Hence, the PLR will set the source address in
   the sender template to a local PLR address.

   The MP MUST use the LSP-ID to identify the corresponding S2L sub-
   LSPs.  The MP MUST NOT use the <Sub-Group Originator ID, Sub-Group
   ID> tuple while identifying the corresponding S2L sub-LSPs.  In order
   to further process an S2L sub-LSP the MP MUST determine the protected
   S2L sub-LSP using the LSP-ID and the S2L_SUB_LSP object.

15.1.2.  Node Protection

   If node protection is desired the PLR SHOULD use one or more P2P
   bypass tunnels to protect the set of S2L sub-LSPs that transit the
   protected node.  Each of these P2P bypass tunnels MUST intersect the
   path of the S2L sub-LSPs that they protect on an LSR that is
   downstream from the protected node.  This constrains the set of S2L
   sub-LSPs being backed- up via that bypass tunnel to those S2L sub-
   LSPs that pass through a common downstream MP.  This MP is the
   destination of the bypass tunnel.  When the PLR forwards incoming
   data for a P2MP LSP into the bypass tunnel, the outer label is the
   bypass tunnel label and the inner label is the label allocated by the
   MP to the set of S2L sub-LSPs belonging to that P2MP LSP.





Aggarwal, et al.            Standards Track                    [Page 31]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


   After detecting failure of the protected node the PLR MUST send one
   or more Path messages for all protected S2L sub-LSPs to the MP of the
   protected S2L sub-LSP.  It is RECOMMENDED that the PLR use the sender
   template specific method to identify these Path messages.  Hence the
   PLR will set the source address in the sender template to a local PLR
   address.  The MP MUST use the LSP-ID to identify the corresponding
   S2L sub-LSPs.  The MP MUST NOT use the <Sub-Group Originator ID,
   Sub-Group ID> tuple while identifying the corresponding S2L sub-LSPs
   because the Sub-Group Originator ID might be changed by some LSR that
   is bypassed by the bypass tunnel.  In order to further process an S2L
   sub-LSP the MP MUST determine the protected S2L sub-LSP using the
   LSP-ID and the S2L_SUB_LSP object.

   Note that node protection MAY require the PLR to be branch capable in
   the data plane, as multiple bypass tunnels may be required to back up
   the set of S2L sub-LSPs passing through the protected node.  If the
   PLR is not branch capable, the node protection mechanism described
   here is applicable to only those cases where all the S2L sub-LSPs
   passing through the protected node also pass through a single MP that
   is downstream from the protected node.  A PLR MUST set the Node
   protection flag in the RRO/SRRO as specified in [RFC4090].  If a PLR
   is not branch capable, and one or more S2L sub-LSPs are added to a
   P2MP tree, and these S2L sub-LSPs do not transit the existing MP
   downstream of the protected node, then the PLR MUST reset this flag.

   It is to be noted that procedures in this section require P2P bypass
   tunnels.  Procedures for using P2MP bypass tunnels are for further
   study.

15.2.  One-to-One Backup

   One-to-one backup, as described in [RFC4090], can be used to protect
   a particular S2L sub-LSP against link and next-hop failure.
   Protection may be used for one or more S2L sub-LSPs between the PLR
   and the next-hop.  All the S2L sub-LSPs corresponding to the same
   instance of the P2MP tunnel between the PLR and the next-hop SHOULD
   share the same P2MP LSP label, as per section 5.2.1.  All such S2L
   sub-LSPs belonging to a P2MP LSP MUST be protected.

   The backup S2L sub-LSPs may traverse different next-hops at the PLR.
   Thus, the set of outgoing labels and next-hops for a P2MP LSP, at the
   PLR, may change once protection is triggered.  Consider a P2MP LSP
   that is using a single next-hop and label between the PLR and the
   next-hop of the PLR.  This may no longer be the case once protection
   is triggered.  This MAY require a PLR to be branch capable in the
   data plane.  If the PLR is not branch capable, the one-to-one backup
   mechanisms described here are only applicable to those cases where
   all the backup S2L sub-LSPs pass through the same next-hop downstream



Aggarwal, et al.            Standards Track                    [Page 32]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


   of the PLR.  Procedures for one-to-one backup when a PLR is not
   branch capable and when all the backup S2L sub-LSPs do not pass
   through the same downstream next-hop are for further study.

   It is recommended that the path-specific method be used to identify a
   backup S2L sub-LSP.  Hence, the DETOUR object SHOULD be inserted in
   the backup Path message.  A backup S2L sub-LSP MUST be treated as
   belonging to a different P2MP tunnel instance than the one specified
   by the LSP-ID.  Furthermore multiple backup S2L sub-LSPs MUST be
   treated as part of the same P2MP tunnel instance if they have the
   same LSP-ID and the same DETOUR objects.  Note that, as specified in
   section 4, S2L sub-LSPs between different P2MP tunnel instances use
   different labels.

   If there is only one S2L sub-LSP in the Path message, the DETOUR
   object applies to that sub-LSP.  If there are multiple S2L sub-LSPs
   in the Path message, the DETOUR object applies to all the S2L sub-
   LSPs.

16.  Support for LSRs That Are Not P2MP Capable

   It may be that some LSRs in a network are capable of processing the
   P2MP extensions described in this document, but do not support P2MP
   branching in the data plane.  If such an LSR is requested to become a
   branch LSR by a received Path message, it MUST respond with a PathErr
   message carrying the Error Code "Routing Error" and Error Value
   "Unable to Branch".

   It is also conceivable that some LSRs, in a network deploying P2MP
   capability, may not support the extensions described in this
   document.  If a Path message for the establishment of a P2MP LSP
   reaches such an LSR, it will reject it with a PathErr because it will
   not recognize the C-Type of the P2MP SESSION object.

   LSRs that do not support the P2MP extensions in this document may be
   included as transit LSRs by the use of LSP stitching [LSP-STITCH] and
   LSP hierarchy [RFC4206].  Note that LSRs that are required to play
   any other role in the network (ingress, branch or egress) MUST
   support the extensions defined in this document.

   The use of LSP stitching and LSP hierarchy [RFC4206] allows P2MP LSPs
   to be built in such an environment.  A P2P LSP segment is signaled
   from the last P2MP-capable hop that is upstream of a legacy LSR to
   the first P2MP-capable hop that is downstream of it.  This assumes
   that intermediate legacy LSRs are transit LSRs: they cannot act as
   P2MP branch points.  Transit LSRs along this LSP segment do not
   process control plane messages associated with the P2MP LSP.
   Furthermore, these transit LSRs also do not need to have P2MP data



Aggarwal, et al.            Standards Track                    [Page 33]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


   plane capabilities as they only need to process data belonging to the
   P2P LSP segment.  Hence, these transit LSRs do not need to support
   P2MP MPLS.  This P2P LSP segment is stitched to the incoming P2MP
   LSP.  After the P2P LSP segment is established, the P2MP Path message
   is sent to the next P2MP-capable LSR as a directed Path message.  The
   next P2MP-capable LSR stitches the P2P LSP segment to the outgoing
   P2MP LSP.

   In packet networks, the S2L sub-LSPs may be nested inside the outer
   P2P LSP.  Hence, label stacking can be used to enable use of the same
   LSP segment for multiple P2MP LSPs.  Stitching and nesting
   considerations and procedures are described further in [LSP-STITCH]
   and [RFC4206].

   There maybe overhead for an operator to configure the P2P LSP
   segments in advance, when it is desired to support legacy LSRs.  It
   may be desirable to do this dynamically.  The ingress can use IGP
   extensions to determine P2MP-capable LSRs [TE-NODE-CAP].  It can use
   this information to compute S2L sub-LSP paths such that they avoid
   legacy non-P2MP-capable LSRs.  The explicit route object of an S2L
   sub-LSP path may contain loose hops if there are legacy LSRs along
   the path.  The corresponding explicit route contains a list of
   objects up to the P2MP-capable LSR that is adjacent to a legacy LSR
   followed by a loose object with the address of the next P2MP-capable
   LSR.  The P2MP-capable LSR expands the loose hop using its Traffic
   Engineering Database (TED).  When doing this it determines that the
   loose hop expansion requires a P2P LSP to tunnel through the legacy
   LSR.  If such a P2P LSP exists, it uses that P2P LSP.  Else it
   establishes the P2P LSP.  The P2MP Path message is sent to the next
   P2MP-capable LSR using non-adjacent signaling.

   The P2MP-capable LSR that initiates the non-adjacent signaling
   message to the next P2MP-capable LSR may have to employ a fast
   detection mechanism (such as [BFD] or [BFD-MPLS]) to the next P2MP-
   capable LSR.  This may be needed for the directed Path message head-
   end to use node protection fast reroute when the protected node is
   the directed Path message tail.

   Note that legacy LSRs along a P2P LSP segment cannot perform node
   protection of the tail of the P2P LSP segment.

17.  Reduction in Control Plane Processing with LSP Hierarchy

   It is possible to take advantage of LSP hierarchy [RFC4206] while
   setting up P2MP LSP, as described in the previous section, to reduce
   control plane processing along transit LSRs that are P2MP capable.
   This is applicable only in environments where LSP hierarchy can be
   used.  Transit LSRs along a P2P LSP segment, being used by a P2MP



Aggarwal, et al.            Standards Track                    [Page 34]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


   LSP, do not process control plane messages associated with the P2MP
   LSP.  In fact, they are not aware of these messages as they are
   tunneled over the P2P LSP segment.  This reduces the amount of
   control plane processing required on these transit LSRs.

   Note that the P2P LSPs can be set up dynamically as described in the
   previous section or preconfigured.  For example, in Figure 2 in
   section 24, PE1 can set up a P2P LSP to P1 and use that as a LSP
   segment.  The Path messages for PE3 and PE4 can now be tunneled over
   the LSP segment.  Thus, P3 is not aware of the P2MP LSP and does not
   process the P2MP control messages.

18.  P2MP LSP Re-Merging and Cross-Over

   This section details the procedures for detecting and dealing with
   re-merge and cross-over.  The term "re-merge" refers to the case of
   an ingress or transit node that creates a branch of a P2MP LSP, a re-
   merge branch, that intersects the P2MP LSP at another node farther
   down the tree.  This may occur due to such events as an error in path
   calculation, an error in manual configuration, or network topology
   changes during the establishment of the P2MP LSP.  If the procedures
   detailed in this section are not followed, data duplication will
   result.

   The term "cross-over" refers to the case of an ingress or transit
   node that creates a branch of a P2MP LSP, a cross-over branch, that
   intersects the P2MP LSP at another node farther down the tree.  It is
   unlike re-merge in that, at the intersecting node, the cross-over
   branch has a different outgoing interface as well as a different
   incoming interface.  This may be necessary in certain combinations of
   topology and technology; e.g., in a transparent optical network in
   which different wavelengths are required to reach different leaf
   nodes.

   Normally, a P2MP LSP has a single incoming interface on which all of
   the data for the P2MP LSP is received.  The incoming interface is
   identified by the IF_ID RSVP_HOP object, if present, and by the
   interface over which the Path message was received if the IF_ID
   RSVP_HOP object is not present.  However, in the case of dynamic LSP
   re-routing, the incoming interface may change.

   Similarly, in both the re-merge and cross-over cases, a node will
   receive a Path message for a given P2MP LSP identifying a different
   incoming interface for the data, and the node needs to be able to
   distinguish between dynamic LSP re-routing and the re- merge/cross-
   over cases.





Aggarwal, et al.            Standards Track                    [Page 35]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


   Make-before-break represents yet another similar but different case,
   in that the incoming interface associated with the make-before-break
   P2MP LSP may be different than that associated with the original P2MP
   LSP.  However, the two P2MP LSPs will be treated as distinct (but
   related) LSPs because they will have different LSP ID field values in
   their SENDER_TEMPLATE objects.

18.1.  Procedures

   When a node receives a Path message, it MUST check whether it has
   matching state for the P2MP LSP.  Matching state is identified by
   comparing the SESSION and SENDER_TEMPLATE objects in the received
   Path message with the SESSION and SENDER_TEMPLATE objects of each
   locally maintained P2MP LSP Path state.  The P2MP ID, Tunnel ID, and
   Extended Tunnel ID in the SESSION object and the sender address and
   LSP ID in the SENDER_TEMPLATE object are used for the comparison.  If
   the node has matching state, and the incoming interface for the
   received Path message is different than the incoming interface of the
   matching P2MP LSP Path state, then the node MUST determine whether it
   is dealing with dynamic LSP rerouting or re-merge/cross-over.

   Dynamic LSP rerouting is identified by checking whether there is any
   intersection between the set of S2L_SUB_LSP objects associated with
   the matching P2MP LSP Path state and the set of S2L_SUB_LSP objects
   in the received Path message.  If there is any intersection, then
   dynamic re-routing has occurred.  If there is no intersection between
   the two sets of S2L_SUB_LSP objects, then either re-merge or cross-
   over has occurred.  (Note that in the case of dynamic LSP rerouting,
   Path messages for the non-intersecting members of set of S2L_SUB_LSPs
   associated with the matching P2MP LSP Path state will be received
   subsequently on the new incoming interface.)

   In order to identify the re-merge case, the node processing the
   received Path message MUST identify the outgoing interfaces
   associated with the matching P2MP Path state.  Re-merge has occurred
   if there is any intersection between the set of outgoing interfaces
   associated with the matching P2MP LSP Path state and the set of
   outgoing interfaces in the received Path message.

18.1.1.  Re-Merge Procedures

   There are two approaches to dealing with the re-merge case.  In the
   first, the node detecting the re-merge case, i.e., the re-merge node,
   allows the re-merge case to persist, but data from all but one
   incoming interface is dropped at the re-merge node.  In the second,
   the re-merge node initiates the removal of the re-merge branch(es)
   via signaling.  Which approach is used is a matter of local policy.




Aggarwal, et al.            Standards Track                    [Page 36]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


   A node MUST support both approaches and MUST allow user configuration
   of which approach is to be used.

   When configured to allow a re-merge case to persist, the re-merge
   node MUST validate consistency between the objects included in the
   received Path message and the matching P2MP LSP Path state.  Any
   inconsistencies MUST result in a PathErr message sent to the previous
   hop of the received Path message.  The Error Code is set to "Routing
   Problem", and the Error Value is set to "P2MP Re-Merge Parameter
   Mismatch".

   If there are no inconsistencies, the node logically merges, from the
   downstream perspective, the control state of incoming Path message
   with the matching P2MP LSP Path state.  Specifically, procedures
   related to processing of messages received from upstream MUST NOT be
   modified from the upstream perspective; this includes processing
   related to refresh and state timeout.  In addition to the standard
   upstream related procedures, the node MUST ensure that each object
   received from upstream is appropriately represented within the set of
   Path messages sent downstream.  For example, the received <S2L sub-
   LSP descriptor list> MUST be included in the set of outgoing Path
   messages.  If there are any NOTIFY_REQUEST objects present, then the
   procedures defined in section 8 MUST be followed for all Path and
   Resv messages.  Special processing is also required for Resv
   processing.  Specifically, any Resv message received from downstream
   MUST be mapped into an outgoing Resv message that is sent to the
   previous hop of the received Path message.  In practice, this
   translates to decomposing the complete <S2L sub-LSP descriptor list>
   into subsets that match the incoming Path messages, and then
   constructing an outgoing Resv message for each incoming Path message.

   When configured to allow a re-merge case to persist, the re-merge
   node receives data associated with the P2MP LSP on multiple incoming
   interfaces, but it MUST only send the data from one of these
   interfaces to its outgoing interfaces.  That is, the node MUST drop
   data from all but one incoming interface.  This ensures that
   duplicate data is not sent on any outgoing interface.  The mechanism
   used to select the incoming interface is implementation specific and
   is outside the scope of this document.

   When configured to correct the re-merge branch via signaling, the re-
   merge node MUST send a PathErr message corresponding to the received
   Path message.  The PathErr message MUST include all of the objects
   normally included in a PathErr message, as well as one or more
   S2L_SUB_LSP objects from the set of sub-LSPs associated with the
   matching P2MP LSP Path state.  A minimum of three S2L_SUB_LSP objects
   is RECOMMENDED.  This will allow the node that caused the re-merge to
   identify the outgoing Path state associated with the valid portion of



Aggarwal, et al.            Standards Track                    [Page 37]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


   the P2MP LSP.  The set of S2L_SUB_LSP objects in the received Path
   message MUST also be included.  The PathErr message MUST include the
   Error Code "Routing Problem" and Error Value of "P2MP Re-Merge
   Detected".  The node MAY set the Path_State_Removed flag [RFC3473].
   As is always the case, the PathErr message is sent to the previous
   hop of the received Path message.

   A node that receives a PathErr message that contains the Error Value
   "Routing Problem/P2MP Re-Merge Detected" MUST determine if it is the
   node that created the re-merge case.  This is done by checking
   whether there is any intersection between the set of S2L_SUB_LSP
   objects associated with the matching P2MP LSP Path state and the set
   of other-branch S2L_SUB_LSP objects in the received PathErr message.
   If there is, then the node created the re-merge case.  Other-branch
   S2L_SUB_LSP objects are those S2L_SUB_LSP objects included, by the
   node detecting the re-merge case, in the PathErr message that were
   taken from the matching P2MP LSP Path state.  Such S2L_SUB_LSP
   objects are identifiable as they will not be included in the Path
   message associated with the received PathErr message.  See section
   11.1 for more details on how such an association is identified.

   The node SHOULD remove the re-merge case by moving the S2L_SUB_LSP
   objects included in the Path message associated with the received
   PathErr message to the outgoing interface associated with the
   matching P2MP LSP Path state.  A trigger Path message for the moved
   S2L_SUB_LSP objects is then sent via that outgoing interface.  If the
   received PathErr message did not have the Path_State_Removed flag
   set, the node SHOULD send a PathTear via the outgoing interface
   associated with the re-merge branch.

   If use of a new outgoing interface violates one or more SERO
   constraints, then a PathErr message containing the associated
   egresses and any identified S2L_SUB_LSP objects SHOULD be generated
   with the Error Code "Routing Problem" and Error Value of "ERO
   Resulted in Re-Merge".

   The only case where this process will fail is when all the listed
   S2L_SUB_LSP objects are deleted prior to the PathErr message
   propagating to the ingress.  In this case, the whole process will be
   corrected on the next (refresh or trigger) transmission of the
   offending Path message.










Aggarwal, et al.            Standards Track                    [Page 38]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


19.  New and Updated Message Objects

   This section presents the RSVP object formats as modified by this
   document.

19.1.  SESSION Object

   A P2MP LSP SESSION object is used.  This object uses the existing
   SESSION C-Num.  New C-Types are defined to accommodate a logical P2MP
   destination identifier of the P2MP tunnel.  This SESSION object has a
   similar structure as the existing point-to-point RSVP-TE SESSION
   object.  However the destination address is set to the P2MP ID
   instead of the unicast Tunnel Endpoint address.  All S2L sub-LSPs
   that are part of the same P2MP LSP share the same SESSION object.
   This SESSION object identifies the P2MP tunnel.

   The combination of the SESSION object, the SENDER_TEMPLATE object and
   the S2L_SUB_LSP object identifies each S2L sub-LSP.  This follows the
   existing P2P RSVP-TE notion of using the SESSION object for
   identifying a P2P Tunnel, which in turn can contain multiple LSPs,
   each distinguished by a unique SENDER_TEMPLATE object.

19.1.1.  P2MP LSP Tunnel IPv4 SESSION Object

   Class = SESSION, P2MP_LSP_TUNNEL_IPv4 C-Type = 13

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       P2MP ID                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  MUST be zero                 |      Tunnel ID                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Extended Tunnel ID                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   P2MP ID
      A 32-bit identifier used in the SESSION object that remains
      constant over the life of the P2MP tunnel.  It encodes the P2MP
      Identifier that is unique within the scope of the ingress LSR.

   Tunnel ID
      A 16-bit identifier used in the SESSION object that remains
      constant over the life of the P2MP tunnel.







Aggarwal, et al.            Standards Track                    [Page 39]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


   Extended Tunnel ID
      A 32-bit identifier used in the SESSION object that remains
      constant over the life of the P2MP tunnel.  Ingress LSRs that wish
      to have a globally unique identifier for the P2MP tunnel SHOULD
      place their tunnel sender address here.  A combination of this
      address, P2MP ID, and Tunnel ID provides a globally unique
      identifier for the P2MP tunnel.

19.1.2.  P2MP LSP Tunnel IPv6 SESSION Object

   This is the same as the P2MP IPv4 LSP SESSION object with the
   difference that the extended tunnel ID may be set to a 16-byte
   identifier [RFC3209].

   Class = SESSION, P2MP_LSP_TUNNEL_IPv6 C-Type = 14

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       P2MP ID                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  MUST be zero                 |      Tunnel ID                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Extended Tunnel ID (16 bytes)            |
      |                                                               |
      |                             .......                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

19.2.  SENDER_TEMPLATE Object

   The SENDER_TEMPLATE object contains the ingress LSR source address.
   The LSP ID can be changed to allow a sender to share resources with
   itself.  Thus, multiple instances of the P2MP tunnel can be created,
   each with a different LSP ID.  The instances can share resources with
   each other.  The S2L sub-LSPs corresponding to a particular instance
   use the same LSP ID.

   As described in section 4.2, it is necessary to distinguish different
   Path messages that are used to signal state for the same P2MP LSP by
   using a <Sub-Group ID Originator ID, Sub-Group ID> tuple.  The
   SENDER_TEMPLATE object is modified to carry this information as shown
   below.









Aggarwal, et al.            Standards Track                    [Page 40]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


19.2.1.  P2MP LSP Tunnel IPv4 SENDER_TEMPLATE Object

   Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv4 C-Type = 12

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   IPv4 tunnel sender address                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Reserved                |            LSP ID             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Sub-Group Originator ID                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Reserved                |            Sub-Group ID       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv4 tunnel sender address
      See [RFC3209].

   Sub-Group Originator ID
      The Sub-Group Originator ID is set to the TE Router ID of the LSR
      that originates the Path message.  This is either the ingress LSR
      or an LSR which re-originates the Path message with its own Sub-
      Group Originator ID.

   Sub-Group ID
      An identifier of a Path message used to differentiate multiple
      Path messages that signal state for the same P2MP LSP.  This may
      be seen as identifying a group of one or more egress nodes
      targeted by this Path message.

   LSP ID
      See [RFC3209].


















Aggarwal, et al.            Standards Track                    [Page 41]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


19.2.2.  P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object

   Class = SENDER_TEMPLATE, P2MP_LSP_TUNNEL_IPv6 C-Type = 13

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                   IPv6 tunnel sender address                  |
      +                                                               +
      |                            (16 bytes)                         |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Reserved                |            LSP ID             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                   Sub-Group Originator ID                     |
      +                                                               +
      |                            (16 bytes)                         |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Reserved                |            Sub-Group ID       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv6 tunnel sender address
      See [RFC3209].

   Sub-Group Originator ID
      The Sub-Group Originator ID is set to the IPv6 TE Router ID of the
      LSR that originates the Path message.  This is either the ingress
      LSR or an LSR which re-originates the Path message with its own
      Sub-Group Originator ID.

   Sub-Group ID
      As above in section 19.2.1.

   LSP ID
      See [RFC3209].









Aggarwal, et al.            Standards Track                    [Page 42]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


19.3.  S2L_SUB_LSP Object

   An S2L_SUB_LSP object identifies a particular S2L sub-LSP belonging
   to the P2MP LSP.

19.3.1.  S2L_SUB_LSP IPv4 Object

   S2L_SUB_LSP Class = 50, S2L_SUB_LSP_IPv4 C-Type = 1

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   IPv4 S2L Sub-LSP destination address        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv4 Sub-LSP destination address
      IPv4 address of the S2L sub-LSP destination.

19.3.2.  S2L_SUB_LSP IPv6 Object

   S2L_SUB_LSP Class = 50, S2L_SUB_LSP_IPv6 C-Type = 2

   This is the same as the S2L IPv4 Sub-LSP object, with the difference
   that the destination address is a 16-byte IPv6 address.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        IPv6 S2L Sub-LSP destination address (16 bytes)        |
      |                        ....                                   |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

19.4.  FILTER_SPEC Object

   The FILTER_SPEC object is canonical to the P2MP SENDER_TEMPLATE
   object.

19.4.1.  P2MP LSP_IPv4 FILTER_SPEC Object

   Class = FILTER_SPEC, P2MP LSP_IPv4 C-Type = 12

   The format of the P2MP LSP_IPv4 FILTER_SPEC object is identical to
   the P2MP LSP_IPv4 SENDER_TEMPLATE object.







Aggarwal, et al.            Standards Track                    [Page 43]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


19.4.2.  P2MP LSP_IPv6 FILTER_SPEC Object

   Class = FILTER_SPEC, P2MP LSP_IPv6 C-Type = 13

   The format of the P2MP LSP_IPv6 FILTER_SPEC object is identical to
   the P2MP LSP_IPv6 SENDER_TEMPLATE object.

19.5.  P2MP SECONDARY_EXPLICIT_ROUTE Object (SERO)

   The P2MP SECONDARY_EXPLICIT_ROUTE Object (SERO) is defined as
   identical to the ERO.  The class of the P2MP SERO is the same as the
   SERO defined in [RFC4873].  The P2MP SERO uses a new C-Type = 2.  The
   sub-objects are identical to those defined for the ERO.

19.6.  P2MP SECONDARY_RECORD_ROUTE Object (SRRO)

   The P2MP SECONDARY_RECORD_ROUTE Object (SRRO) is defined as identical
   to the ERO.  The class of the P2MP SRRO is the same as the SRRO
   defined in [RFC4873].  The P2MP SRRO uses a new C-Type = 2.  The
   sub-objects are identical to those defined for the RRO.

20.  IANA Considerations

20.1.  New Class Numbers

   IANA has assigned the following Class Numbers for the new object
   classes introduced.  The Class Types for each of them are to be
   assigned via standards action.  The sub-object types for the P2MP
   SECONDARY_EXPLICIT_ROUTE and P2MP_SECONDARY_RECORD_ROUTE follow the
   same IANA considerations as those of the ERO and RRO [RFC3209].

   50  Class Name = S2L_SUB_LSP

   C-Type
      1   S2L_SUB_LSP_IPv4 C-Type
      2   S2L_SUB_LSP_IPv6 C-Type

20.2.  New Class Types

   IANA has assigned the following C-Type values:

   Class Name = SESSION

   C-Type
     13    P2MP_LSP_TUNNEL_IPv4 C-Type
     14    P2MP_LSP_TUNNEL_IPv6 C-Type





Aggarwal, et al.            Standards Track                    [Page 44]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


   Class Name = SENDER_TEMPLATE

   C-Type
     12    P2MP_LSP_TUNNEL_IPv4 C-Type
     13    P2MP_LSP_TUNNEL_IPv6 C-Type

   Class Name = FILTER_SPEC

   C-Type
     12    P2MP LSP_IPv4 C-Type
     13    P2MP LSP_IPv6 C-Type

   Class Name = SECONDARY_EXPLICIT_ROUTE (Defined in [RFC4873])

   C-Type
      2  P2MP SECONDARY_EXPLICIT_ROUTE C-Type

   Class Name = SECONDARY_RECORD_ROUTE (Defined in [RFC4873])

   C-Type
      2  P2MP_SECONDARY_RECORD_ROUTE C-Type

20.3.  New Error Values

   Five new Error Values are defined for use with the Error Code
   "Routing Problem".  IANA has assigned values for them as follows.

   The Error Value "Unable to Branch" indicates that a P2MP branch
   cannot be formed by the reporting LSR.  IANA has assigned value 23 to
   this Error Value.

   The Error Value "Unsupported LSP Integrity" indicates that a P2MP
   branch does not support the requested LSP integrity function.  IANA
   has assigned value 24 to this Error Value.

   The Error Value "P2MP Re-Merge Detected" indicates that a node has
   detected re-merge.  IANA has assigned value 25 to this Error Value.

   The Error Value "P2MP Re-Merge Parameter Mismatch" is described in
   section 18.  IANA has assigned value 26 to this Error Value.

   The Error Value "ERO Resulted in Re-Merge" is described in section
   18.  IANA has assigned value 27 to this Error Value.








Aggarwal, et al.            Standards Track                    [Page 45]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


20.4.  LSP Attributes Flags

   IANA has been asked to manage the space of flags in the Attributes
   Flags TLV carried in the LSP_REQUIRED_ATTRIBUTES object [RFC4420].
   This document defines a new flag as follows:

   Bit Number:                       3
   Meaning:                          LSP Integrity Required
   Used in Attributes Flags on Path: Yes
   Used in Attributes Flags on Resv: No
   Used in Attributes Flags on RRO:  No
   Referenced Section of this Doc:   5.2.4

21.  Security Considerations

   In principle this document does not introduce any new security issues
   above those identified in [RFC3209], [RFC3473], and [RFC4206].
   [RFC2205] specifies the message integrity mechanisms for hop-by-hop
   RSVP signaling.  These mechanisms apply to the hop-by-hop P2MP RSVP-
   TE signaling in this document.  Further, [RFC3473] and [RFC4206]
   specify the security mechanisms for non hop-by-hop RSVP-TE signaling.
   These mechanisms apply to the non hop-by-hop P2MP RSVP-TE signaling
   specified in this document, particularly in sections 16 and 17.

   An administration may wish to limit the domain over which P2MP TE
   tunnels can be established.  This can be accomplished by setting
   filters on various ports to deny action on a RSVP path message with a
   SESSION object of type P2MP_LSP_IPv4 or P2MP_LSP_IPv6.

   The ingress LSR of a P2MP TE LSP determines the leaves of the P2MP TE
   LSP based on the application of the P2MP TE LSP.  The specification
   of how such applications will use a P2MP TE LSP is outside the scope
   of this document.  Applications MUST provide a mechanism to notify
   the ingress LSR of the appropriate leaves for the P2MP LSP.
   Specifications of applications within the IETF MUST specify this
   mechanism in sufficient detail that an ingress LSR from one vendor
   can be used with an application implementation provided by another
   vendor.  Manual configuration of security parameters when other
   parameters are auto-discovered is generally not sufficient to meet
   security and interoperability requirements of IETF specifications.











Aggarwal, et al.            Standards Track                    [Page 46]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


22.  Acknowledgements

   This document is the product of many people.  The contributors are
   listed in Appendix B.

   Thanks to Yakov Rekhter, Der-Hwa Gan, Arthi Ayyanger, and Nischal
   Sheth for their suggestions and comments.  Thanks also to Dino
   Farninacci and Benjamin Niven for their comments.

23.  References

23.1.  Normative References

   [RFC4206]     Kompella, K. and Y. Rekhter, "Label Switched Paths
                 (LSP) Hierarchy with Generalized Multi-Protocol Label
                 Switching (GMPLS) Traffic Engineering (TE)", RFC 4206,
                 October 2005.

   [RFC4420]     Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and
                 A. Ayyangar, "Encoding of Attributes for Multiprotocol
                 Label Switching (MPLS) Label Switched Path (LSP)
                 Establishment Using Resource ReserVation Protocol-
                 Traffic Engineering (RSVP-TE)", RFC 4420, February
                 2006.

   [RFC3209]     Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
                 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
                 LSP Tunnels", RFC 3209, December 2001.

   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2205]     Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and
                 S. Jamin, "Resource ReSerVation Protocol (RSVP) --
                 Version 1 Functional Specification", RFC 2205,
                 September 1997.

   [RFC3471]     Berger, L., Ed., "Generalized Multi-Protocol Label
                 Switching (GMPLS) Signaling Functional Description",
                 RFC 3471, January 2003.

   [RFC3473]     Berger, L., Ed., "Generalized Multi-Protocol Label
                 Switching (GMPLS) Signaling Resource ReserVation
                 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
                 3473, January 2003.






Aggarwal, et al.            Standards Track                    [Page 47]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


   [RFC2961]     Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
                 and S. Molendini, "RSVP Refresh Overhead Reduction
                 Extensions", RFC 2961, April 2001.

   [RFC3031]     Rosen, E., Viswanathan, A., and R. Callon,
                 "Multiprotocol Label Switching Architecture", RFC 3031,
                 January 2001.

   [RFC4090]     Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed.,
                 "Fast Reroute Extensions to RSVP-TE for LSP Tunnels",
                 RFC 4090, May 2005.

   [RFC3477]     Kompella, K. and Y. Rekhter, "Signalling Unnumbered
                 Links in Resource ReSerVation Protocol - Traffic
                 Engineering (RSVP-TE)", RFC 3477, January 2003.

   [RFC4873]     Berger, L., Bryskin, I., Papadimitriou, D., and A.
                 Farrel, "GMPLS Segment Recovery", RFC 4873, April 2007.

23.2. Informative References

   [RFC4461]     Yasukawa, S., Ed., "Signaling Requirements for Point-
                 to-Multipoint Traffic-Engineered MPLS Label Switched
                 Paths (LSPs)", RFC 4461, April 2006.

   [BFD]         Katz, D. and D. Ward, "Bidirectional Forwarding
                 Detection", Work in Progress, March 2007.

   [BFD-MPLS]    Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
                 "BFD for MPLS LSPs", Work in Progress, March 2007.

   [LSP-STITCH]  Ayyanger, A., Kompella, K., Vasseur, JP., and A.
                 Farrel, "Label Switched Path Stitching with Generalized
                 Multiprotocol Label Switching Traffic Engineering
                 (GMPLS TE)", Work in Progress, March 2007.

   [TE-NODE-CAP] Vasseur, JP., Ed., Le Roux, JL., Ed., "IGP Routing
                 Protocol Extensions for Discovery of Traffic
                 Engineering Node Capabilities", Work in Progress, April
                 2007.

   [RFC4003]     Berger, L., "GMPLS Signaling Procedure for Egress
                 Control", RFC 4003, February 2005.








Aggarwal, et al.            Standards Track                    [Page 48]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


Appendix A.  Example of P2MP LSP Setup

   The Following is one example of setting up a P2MP LSP using the
   procedures described in this document.

                   Source 1 (S1)
                     |
                    PE1
                   |   |
                   |L5 |
                   P3  |
                   |   |
                L3 |L1 |L2
       R2----PE3--P1   P2---PE2--Receiver 1 (R1)
                  | L4
          PE5----PE4----R3
                  |
                  |
                 R4

                Figure 2.

   The mechanism is explained using Figure 2.  PE1 is the ingress LSR.
   PE2, PE3, and PE4 are egress LSRs.

   a) PE1 learns that PE2, PE3, and PE4 are interested in joining a P2MP
      tree with a P2MP ID of P2MP ID1.  We assume that PE1 learns of the
      egress LSRs at different points in time.

   b) PE1 computes the P2P path to reach PE2.

   c) PE1 establishes the S2L sub-LSP to PE2 along <PE1, P2, PE2>.

   d) PE1 computes the P2P path to reach PE3 when it discovers PE3.
      This path is computed to share the same links where possible with
      the sub-LSP to PE2 as they belong to the same P2MP session.

   e) PE1 establishes the S2L sub-LSP to PE3 along <PE1, P3, P1, PE3>.

   f) PE1 computes the P2P path to reach PE4 when it discovers PE4.
      This path is computed to share the same links where possible with
      the sub-LSPs to PE2 and PE3 as they belong to the same P2MP
      session.

   g) PE1 signals the Path message for PE4 sub-LSP along <PE1, P3, P1,
      PE4>.





Aggarwal, et al.            Standards Track                    [Page 49]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


   h) P1 receives a Resv message from PE4 with label L4.  It had
      previously received a Resv message from PE3 with label L3.  It had
      allocated a label L1 for the sub-LSP to PE3.  It uses the same
      label and sends the Resv messages to P3.  Note that it may send
      only one Resv message with multiple flow descriptors in the flow
      descriptor list.  If this is the case, and FF style is used, the
      FF flow descriptor will contain the S2L sub-LSP descriptor list
      with two entries: one for PE4 and the other for PE3.  For SE
      style, the SE filter spec will contain this S2L sub-LSP descriptor
      list.  P1 also creates a label mapping of (L1 -> {L3, L4}).  P3
      uses the existing label L5 and sends the Resv message to PE1, with
      label L5.  It reuses the label mapping of {L5 -> L1}.

Appendix B.  Contributors

   John Drake
   Boeing
   EMail: john.E.Drake2@boeing.com

   Alan Kullberg
   Motorola Computer Group
   120 Turnpike Road 1st Floor
   Southborough, MA  01772
   EMail: alan.kullberg@motorola.com

   Lou Berger
   LabN Consulting, L.L.C.
   EMail: lberger@labn.net

   Liming Wei
   Redback Networks
   350 Holger Way
   San Jose, CA 95134
   EMail: lwei@redback.com

   George Apostolopoulos
   Redback Networks
   350 Holger Way
   San Jose, CA 95134
   EMail: georgeap@redback.com

   Kireeti Kompella
   Juniper Networks
   1194 N. Mathilda Ave
   Sunnyvale, CA 94089
   EMail: kireeti@juniper.net





Aggarwal, et al.            Standards Track                    [Page 50]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


   George Swallow
   Cisco Systems, Inc.
   300 Beaver Brook Road
   Boxborough , MA - 01719
   USA
   EMail: swallow@cisco.com

   JP Vasseur
   Cisco Systems, Inc.
   300 Beaver Brook Road
   Boxborough , MA - 01719
   USA
   EMail: jpv@cisco.com
   Dean Cheng
   Cisco Systems Inc.
   170 W Tasman Dr.
   San Jose, CA 95134
   Phone 408 527 0677
   EMail:  dcheng@cisco.com

   Markus Jork
   Avici Systems
   101 Billerica Avenue
   N. Billerica, MA 01862
   Phone: +1 978 964 2142
   EMail: mjork@avici.com

   Hisashi Kojima
   NTT Corporation
   9-11, Midori-Cho 3-Chome
   Musashino-Shi, Tokyo 180-8585 Japan
   Phone: +81 422 59 6070
   EMail: kojima.hisashi@lab.ntt.co.jp

   Andrew G. Malis
   Tellabs
   2730 Orchard Parkway
   San Jose, CA 95134
   Phone: +1 408 383 7223
   EMail: Andy.Malis@tellabs.com

   Koji Sugisono
   NTT Corporation
   9-11, Midori-Cho 3-Chome
   Musashino-Shi, Tokyo 180-8585 Japan
   Phone: +81 422 59 2605
   EMail: sugisono.koji@lab.ntt.co.jp




Aggarwal, et al.            Standards Track                    [Page 51]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


   Masanori Uga
   NTT Corporation
   9-11, Midori-Cho 3-Chome
   Musashino-Shi, Tokyo 180-8585 Japan
   Phone: +81 422 59 4804
   EMail: uga.masanori@lab.ntt.co.jp

   Igor Bryskin
   Movaz Networks, Inc.
   7926 Jones Branch Drive
   Suite 615
   McLean VA, 22102
   ibryskin@movaz.com
   Adrian Farrel
   Old Dog Consulting
   Phone: +44 0 1978 860944
   EMail: adrian@olddog.co.uk

   Jean-Louis Le Roux
   France Telecom
   2, avenue Pierre-Marzin
   22307 Lannion Cedex
   France
   EMail: jeanlouis.leroux@francetelecom.com

Editors' Addresses

   Rahul Aggarwal
   Juniper Networks
   1194 North Mathilda Ave.
   Sunnyvale, CA 94089
   EMail: rahul@juniper.net

   Seisho Yasukawa
   NTT Corporation
   9-11, Midori-Cho 3-Chome
   Musashino-Shi, Tokyo 180-8585 Japan
   Phone: +81 422 59 4769
   EMail: yasukawa.seisho@lab.ntt.co.jp

   Dimitri Papadimitriou
   Alcatel
   Francis Wellesplein 1,
   B-2018 Antwerpen, Belgium
   Phone: +32 3 240-8491
   EMail: Dimitri.Papadimitriou@alcatel-lucent.be





Aggarwal, et al.            Standards Track                    [Page 52]
^L
RFC 4875         Extensions to RSVP-TE for P2MP TE LSPs         May 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.







Aggarwal, et al.            Standards Track                    [Page 53]
^L