File: rfc2362.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (3699 lines) | stat: -rw-r--r-- 159,833 bytes parent folder | download | duplicates (5)
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
2972
2973
2974
2975
2976
2977
2978
2979
2980
2981
2982
2983
2984
2985
2986
2987
2988
2989
2990
2991
2992
2993
2994
2995
2996
2997
2998
2999
3000
3001
3002
3003
3004
3005
3006
3007
3008
3009
3010
3011
3012
3013
3014
3015
3016
3017
3018
3019
3020
3021
3022
3023
3024
3025
3026
3027
3028
3029
3030
3031
3032
3033
3034
3035
3036
3037
3038
3039
3040
3041
3042
3043
3044
3045
3046
3047
3048
3049
3050
3051
3052
3053
3054
3055
3056
3057
3058
3059
3060
3061
3062
3063
3064
3065
3066
3067
3068
3069
3070
3071
3072
3073
3074
3075
3076
3077
3078
3079
3080
3081
3082
3083
3084
3085
3086
3087
3088
3089
3090
3091
3092
3093
3094
3095
3096
3097
3098
3099
3100
3101
3102
3103
3104
3105
3106
3107
3108
3109
3110
3111
3112
3113
3114
3115
3116
3117
3118
3119
3120
3121
3122
3123
3124
3125
3126
3127
3128
3129
3130
3131
3132
3133
3134
3135
3136
3137
3138
3139
3140
3141
3142
3143
3144
3145
3146
3147
3148
3149
3150
3151
3152
3153
3154
3155
3156
3157
3158
3159
3160
3161
3162
3163
3164
3165
3166
3167
3168
3169
3170
3171
3172
3173
3174
3175
3176
3177
3178
3179
3180
3181
3182
3183
3184
3185
3186
3187
3188
3189
3190
3191
3192
3193
3194
3195
3196
3197
3198
3199
3200
3201
3202
3203
3204
3205
3206
3207
3208
3209
3210
3211
3212
3213
3214
3215
3216
3217
3218
3219
3220
3221
3222
3223
3224
3225
3226
3227
3228
3229
3230
3231
3232
3233
3234
3235
3236
3237
3238
3239
3240
3241
3242
3243
3244
3245
3246
3247
3248
3249
3250
3251
3252
3253
3254
3255
3256
3257
3258
3259
3260
3261
3262
3263
3264
3265
3266
3267
3268
3269
3270
3271
3272
3273
3274
3275
3276
3277
3278
3279
3280
3281
3282
3283
3284
3285
3286
3287
3288
3289
3290
3291
3292
3293
3294
3295
3296
3297
3298
3299
3300
3301
3302
3303
3304
3305
3306
3307
3308
3309
3310
3311
3312
3313
3314
3315
3316
3317
3318
3319
3320
3321
3322
3323
3324
3325
3326
3327
3328
3329
3330
3331
3332
3333
3334
3335
3336
3337
3338
3339
3340
3341
3342
3343
3344
3345
3346
3347
3348
3349
3350
3351
3352
3353
3354
3355
3356
3357
3358
3359
3360
3361
3362
3363
3364
3365
3366
3367
3368
3369
3370
3371
3372
3373
3374
3375
3376
3377
3378
3379
3380
3381
3382
3383
3384
3385
3386
3387
3388
3389
3390
3391
3392
3393
3394
3395
3396
3397
3398
3399
3400
3401
3402
3403
3404
3405
3406
3407
3408
3409
3410
3411
3412
3413
3414
3415
3416
3417
3418
3419
3420
3421
3422
3423
3424
3425
3426
3427
3428
3429
3430
3431
3432
3433
3434
3435
3436
3437
3438
3439
3440
3441
3442
3443
3444
3445
3446
3447
3448
3449
3450
3451
3452
3453
3454
3455
3456
3457
3458
3459
3460
3461
3462
3463
3464
3465
3466
3467
3468
3469
3470
3471
3472
3473
3474
3475
3476
3477
3478
3479
3480
3481
3482
3483
3484
3485
3486
3487
3488
3489
3490
3491
3492
3493
3494
3495
3496
3497
3498
3499
3500
3501
3502
3503
3504
3505
3506
3507
3508
3509
3510
3511
3512
3513
3514
3515
3516
3517
3518
3519
3520
3521
3522
3523
3524
3525
3526
3527
3528
3529
3530
3531
3532
3533
3534
3535
3536
3537
3538
3539
3540
3541
3542
3543
3544
3545
3546
3547
3548
3549
3550
3551
3552
3553
3554
3555
3556
3557
3558
3559
3560
3561
3562
3563
3564
3565
3566
3567
3568
3569
3570
3571
3572
3573
3574
3575
3576
3577
3578
3579
3580
3581
3582
3583
3584
3585
3586
3587
3588
3589
3590
3591
3592
3593
3594
3595
3596
3597
3598
3599
3600
3601
3602
3603
3604
3605
3606
3607
3608
3609
3610
3611
3612
3613
3614
3615
3616
3617
3618
3619
3620
3621
3622
3623
3624
3625
3626
3627
3628
3629
3630
3631
3632
3633
3634
3635
3636
3637
3638
3639
3640
3641
3642
3643
3644
3645
3646
3647
3648
3649
3650
3651
3652
3653
3654
3655
3656
3657
3658
3659
3660
3661
3662
3663
3664
3665
3666
3667
3668
3669
3670
3671
3672
3673
3674
3675
3676
3677
3678
3679
3680
3681
3682
3683
3684
3685
3686
3687
3688
3689
3690
3691
3692
3693
3694
3695
3696
3697
3698
3699






Network Working Group                                       D.  Estrin
Request for Comments: 2362                                         USC
Obsoletes: 2117                                           D. Farinacci
Category: Experimental                                           CISCO
                                                              A. Helmy
                                                                   USC
                                                             D. Thaler
                                                                 UMICH
                                                            S. Deering
                                                                 XEROX
                                                            M. Handley
                                                                   UCL
                                                           V. Jacobson
                                                                   LBL
                                                                C. Liu
                                                                   USC
                                                             P. Sharma
                                                                   USC
                                                                L. Wei
                                                                 CISCO
                                                             June 1998


     Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol
                             Specification

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.















Estrin, et. al.               Experimental                      [Page 1]

RFC 2362                         PIM-SM                        June 1998


1 Introduction

   This document describes a protocol for efficiently routing to
   multicast groups that may span wide-area (and inter-domain)
   internets.  We refer to the approach as Protocol Independent
   Multicast--Sparse Mode (PIM-SM) because it is not dependent on any
   particular unicast routing protocol, and because it is designed to
   support sparse groups as defined in [1][2]. This document describes
   the protocol details. For the motivation behind the design and a
   description of the architecture, see [1][2]. Section 2 summarizes
   PIM-SM operation.  It describes the protocol from a network
   perspective, in particular, how the participating routers interact to
   create and maintain the multicast distribution tree.  Section 3
   describes PIM-SM operations from the perspective of a single router
   implementing the protocol; this section constitutes the main body of
   the protocol specification.  It is organized according to PIM-SM
   message type; for each message type we describe its contents, its
   generation, and its processing.

   Sections 3.8 and 3.9 summarize the timers and flags referred to
   throughout this document. Section 4 provides packet format details.

   The most significant functional changes since the January '95 version
   involve the Rendezvous Point-related mechanisms, several resulting
   simplifications to the protocol, and removal of the PIM-DM protocol
   details to a separate document [3] (for clarity).

2 PIM-SM Protocol Overview

   In this section we provide an overview of the architectural
   components of PIM-SM.

   A router receives explicit Join/Prune messages from those neighboring
   routers that have downstream group members. The router then forwards
   data packets addressed to a multicast group, G, only onto those
   interfaces on which explicit joins have been received. Note that all
   routers mentioned in this document are assumed to be PIM-SM capable,
   unless otherwise specified.

   A Designated Router (DR) sends periodic Join/Prune messages toward a
   group-specific Rendezvous Point (RP) for each group for which it has
   active members. Each router along the path toward the RP builds a
   wildcard (any-source) state for the group and sends Join/Prune
   messages on toward the RP. We use the term route entry to refer to
   the state maintained in a router to represent the distribution tree.
   A route entry may include such fields as the source address, the
   group address, the incoming interface from which packets are
   accepted, the list of outgoing interfaces to which packets are sent,



Estrin, et. al.               Experimental                      [Page 2]

RFC 2362                         PIM-SM                        June 1998


   timers, flag bits, etc. The wildcard route entry's incoming interface
   points toward the RP; the outgoing interfaces point to the
   neighboring downstream routers that have sent Join/Prune messages
   toward the RP. This state creates a shared, RP-centered, distribution
   tree that reaches all group members. When a data source first sends
   to a group, its DR unicasts Register messages to the RP with the
   source's data packets encapsulated within. If the data rate is high,
   the RP can send source-specific Join/Prune messages back towards the
   source and the source's data packets will follow the resulting
   forwarding state and travel unencapsulated to the RP.  Whether they
   arrive encapsulated or natively, the RP forwards the source's
   decapsulated data packets down the RP-centered distribution tree
   toward group members.  If the data rate warrants it, routers with
   local receivers can join a source-specific, shortest path,
   distribution tree, and prune this source's packets off of the shared
   RP-centered tree. For low data rate sources, neither the RP, nor
   last-hop routers need join a source-specific shortest path tree and
   data packets can be delivered via the shared, RP-tree.

   The following subsections describe SM operation in more detail, in
   particular, the control messages, and the actions they trigger.

2.1 Local hosts joining a group

   In order to join a multicast group, G, a host conveys its membership
   information through the Internet Group Management Protocol (IGMP), as
   specified in [4][5], (see figure 1). From this point on we refer to
   such a host as a receiver, R, (or member) of the group G.

   Note that all figures used in this section are for illustration and
   are not intended to be complete. For complete and detailed protocol
   action see Section 3.

           [Figures are present only in the postscript version]
       Fig. 1 Example: how a receiver joins, and sets up shared tree

   When a DR (e.g., router A in figure 1) gets a membership indication
   from IGMP for a new group, G, the DR looks up the associated RP. The
   DR creates a wildcard multicast route entry for the group, referred
   to here as a (*,G) entry; if there is no more specific match for a
   particular source, the packet will be forwarded according to this
   entry.

   The RP address is included in a special field in the route entry and
   is included in periodic upstream Join/Prune messages. The outgoing
   interface is set to that included in the IGMP membership indication
   for the new member. The incoming interface is set to the interface
   used to send unicast packets to the RP.



Estrin, et. al.               Experimental                      [Page 3]

RFC 2362                         PIM-SM                        June 1998


   When there are no longer directly connected members for the group,
   IGMP notifies the DR.  If the DR has neither local members nor
   downstream receivers, the (*,G) state is deleted.

2.2 Establishing the RP-rooted shared tree

   Triggered by the (*,G) state, the DR creates a Join/Prune message
   with the RP address in its join list and the the wildcard bit (WC-
   bit) and RP-tree bit (RPT-bit) set to 1. The WC-bit indicates that
   any source may match and be forwarded according to this entry if
   there is no longer match; the RPT-bit indicates that this join is
   being sent up the shared, RP-tree. The prune list is left empty. When
   the RPT-bit is set to 1 it indicates that the join is associated with
   the shared RP-tree and therefore the Join/Prune message is propagated
   along the RP-tree. When the WC-bit is set to 1 it indicates that the
   address is an RP and the downstream receivers expect to receive
   packets from all sources via this (shared tree) path. The term RPT-
   bit is used to refer to both the RPT-bit flags associated with route
   entries, and the RPT-bit included in each encoded address in a
   Join/Prune message.

   Each upstream router creates or updates its multicast route entry for
   (*,G) when it receives a Join/Prune with the RPT-bit and WC-bit set.
   The interface on which the Join/Prune message arrived is added to the
   list of outgoing interfaces (oifs) for (*,G). Based on this entry
   each upstream router between the receiver and the RP sends a
   Join/Prune message in which the join list includes the RP. The packet
   payload contains Multicast-Address=G, Join=RP,WC-bit,RPT-bit,
   Prune=NULL.

2.3 Hosts sending to a group

   When a host starts sending multicast data packets to a group,
   initially its DR must deliver each packet to the RP for distribution
   down the RP-tree (see figure 2).  The sender's DR initially
   encapsulates each data packet in a Register message and unicasts it
   to the RP for that group. The RP decapsulates each Register message
   and forwards the enclosed data packet natively to downstream members
   on the shared RP-tree.

           [Figures are present only in the postscript version]
                Fig. 2  Example: a host sending to a group

   If the data rate of the source warrants the use of a source-specific
   shortest path tree (SPT), the RP may construct a new multicast route
   entry that is specific to the source, hereafter referred to as (S,G)
   state, and send periodic Join/Prune messages toward the source. Note
   that over time, the rules for when to switch can be modified without



Estrin, et. al.               Experimental                      [Page 4]

RFC 2362                         PIM-SM                        June 1998


   global coordination.  When and if the RP does switch to the SPT, the
   routers between the source and the RP build and maintain (S,G) state
   in response to these messages and send (S,G) messages upstream toward
   the source.

   The source's DR must stop encapsulating data packets in Registers
   when (and so long as) it receives Register-Stop messages from the RP.
   The RP triggers Register-Stop messages in response to Registers, if
   the RP has no downstream receivers for the group (or for that
   particular source), or if the RP has already joined the (S,G) tree
   and is receiving the data packets natively.  Each source's DR
   maintains, per (S,G), a Register-Suppression-timer.  The Register-
   Suppression-timer is started by the Register-Stop message; upon
   expiration, the source's DR resumes sending data packets to the RP,
   encapsulated in Register messages.

2.4 Switching from shared tree (RP-tree)  to  shortest  path  tree
   (SP-tree)}

   A router with directly-connected members first joins the shared RP-
   tree.  The router can switch to a source's shortest path tree (SP-
   tree) after receiving packets from that source over the shared RP-
   tree. The recommended policy is to initiate the switch to the SP-tree
   after receiving a significant number of data packets during a
   specified time interval from a particular source. To realize this
   policy the router can monitor data packets from sources for which it
   has no source-specific multicast route entry and initiate such an
   entry when the data rate exceeds the configured threshold.  As shown
   in figure 3, router `A' initiates a (S,G) state.

           [Figures are present only in the postscript version]
     Fig. 3 Example: Switching from shared tree to shortest path tree

   When a (S,G) entry is activated (and periodically so long as the
   state exists), a Join/Prune message is sent upstream towards the
   source, S, with S in the join list. The payload contains Multicast-
   Address=G, Join=S, Prune=NULL. When the (S,G) entry is created, the
   outgoing interface list is copied from (*,G), i.e., all local shared
   tree branches are replicated in the new shortest path tree. In this
   way when a data packet from S arrives and matches on this entry, all
   receivers will continue to receive the source's packets along this
   path. (In more complicated scenarios, other entries in the router
   have to be considered, as described in Section 3). Note that (S,G)
   state must be maintained in each last-hop router that is responsible
   for initiating and maintaining an SP-tree. Even when (*,G) and (S,G)
   overlap, both states are needed to trigger the source-specific
   Join/Prune messages.  (S,G) state is kept alive by data packets
   arriving from that source. A timer, Entry-timer, is set for the (S,G)



Estrin, et. al.               Experimental                      [Page 5]

RFC 2362                         PIM-SM                        June 1998


   entry and this timer is restarted whenever data packets for (S,G) are
   forwarded out at least one oif, or Registers are sent.  When the
   Entry-timer expires, the state is deleted. The last-hop router is the
   router that delivers the packets to their ultimate end-system
   destination.  This is the router that monitors if there is group
   membership and joins or prunes the appropriate distribution trees in
   response.  In general the last-hop router is the Designated Router
   (DR) for the LAN. However, under various conditions described later,
   a parallel router connected to the same LAN may take over as the
   last-hop router in place of the DR.

   Only the RP and routers with local members can initiate switching to
   the SP-tree; intermediate routers do not. Consequently, last-hop
   routers create (S,G) state in response to data packets from the
   source, S; whereas intermediate routers only create (S,G) state in
   response to Join/Prune messages from downstream that have S in the
   Join list.

   The (S,G) entry is initialized with the SPT-bit cleared, indicating
   that the shortest path tree branch from S has not yet been setup
   completely, and the router can still accept packets from S that
   arrive on the (*,G) entry's indicated incoming interface (iif). Each
   PIM multicast entry has an associated incoming interface on which
   packets are expected to arrive.

   When a router with a (S,G) entry and a cleared SPT-bit starts to
   receive packets from the new source S on the iif for the (S,G) entry,
   and that iif differs from the (*,G) entry's iif, the router sets the
   SPT-bit, and sends a Join/Prune message towards the RP, indicating
   that the router no longer wants to receive packets from S via the
   shared RP-tree. The Join/Prune message sent towards the RP includes S
   in the prune list, with the RPT-bit set indicating that S's packets
   must not be forwarded down this branch of the shared tree. If the
   router receiving the Join/Prune message has (S,G) state (with or
   without the route entry's RPT-bit flag set), it deletes the arriving
   interface from the (S,G) oif list.  If the router has only (*,G)
   state, it creates an entry with the RPT-bit flag set to 1. For
   brevity we refer to an (S,G) entry that has the RPT-bit flag set to 1
   as an (S,G)RPT-bit entry. This notational distinction is useful to
   point out the different actions taken for (S,G) entries depending on
   the setting of the RPT-bit flag. Note that a router can have no more
   than one active (S,G) entry for any particular S and G, at any
   particular time; whether the RPT-bit flag is set or not. In other
   words, a router never has both an (S,G) and an (S,G)RPT-bit entry for
   the same S and G at the same time. The Join/Prune message payload
   contains Multicast-Address=G, Join=NULL, Prune=S,RPT-bit.





Estrin, et. al.               Experimental                      [Page 6]

RFC 2362                         PIM-SM                        June 1998


   A new receiver may join an existing RP-tree on which source-specific
   prune state has been established (e.g., because downstream receivers
   have switched to SP-trees). In this case the prune state must be
   eradicated upstream of the new receiver to bring all sources' data
   packets down to the new receiver. Therefore, when a (*,G) Join
   arrives at a router that has any (Si,G)RPT-bit entries (i.e., entries
   that cause the router to send source-specific prunes toward the RP),
   these entries must be updated upstream of the router so as to bring
   all sources' packets down to the new member. To accomplish this, each
   router that receives a (*,G) Join/Prune message updates all existing
   (S,G)RPT-bit entries. The router may also trigger a (*,G) Join/Prune
   message upstream to cause the same updating of RPT-bit settings
   upstream and pull down all active sources' packets. If the arriving
   (*,G) join has some sources included in its prune list, then the
   corresponding (S,G)RPT-bit entries are left unchanged (i.e., the
   RPT-bit remains set and no oif is added).

2.5 Steady state maintenance of distribution tree (i.e., router state)}

   In the steady state each router sends periodic Join/Prune messages
   for each active PIM route entry; the Join/Prune messages are sent to
   the neighbor indicated in the corresponding entry. These messages are
   sent periodically to capture state, topology, and membership changes.
   A Join/Prune message is also sent on an event-triggered basis each
   time a new route entry is established for some new source (note that
   some damping function may be applied, e.g., a short delay to allow
   for merging of new Join information). Join/Prune messages do not
   elicit any form of explicit acknowledgment; routers recover from lost
   packets using the periodic refresh mechanism.

2.6 Obtaining RP information

   To obtain the RP information, all routers within a PIM domain collect
   Bootstrap messages. Bootstrap messages are sent hop-by-hop within the
   domain; the domain's bootstrap router (BSR) is responsible for
   originating the Bootstrap messages. Bootstrap messages are used to
   carry out a dynamic BSR election when needed and to distribute RP
   information in steady state.

   A domain in this context is a contiguous set of routers that all
   implement PIM and are configured to operate within a common boundary
   defined by PIM Multicast Border Routers (PMBRs). PMBRs connect each
   PIM domain to the rest of the internet.

   Routers use a set of available RPs (called the RP-Set) distributed in
   Bootstrap messages to get the proper Group to RP mapping. The
   following paragraphs summarize the mechanism; details of the
   mechanism may be found in Sections 3.6 and Appendix 6.2. A (small)



Estrin, et. al.               Experimental                      [Page 7]

RFC 2362                         PIM-SM                        June 1998


   set of routers, within a domain, are configured as candidate BSRs
   and, through a simple election mechanism, a single BSR is selected
   for that domain. A set of routers within a domain are also configured
   as candidate RPs (C-RPs); typically these will be the same routers
   that are configured as C-BSRs.  Candidate RPs periodically unicast
   Candidate-RP-Advertisement messages (C-RP-Advs) to the BSR of that
   domain. C-RP-Advs include the address of the advertising C-RP, as
   well as an optional group address and a mask length field, indicating
   the group prefix(es) for which the candidacy is advertised. The BSR
   then includes a set of these Candidate-RPs (the RP-Set), along with
   the corresponding group prefixes, in Bootstrap messages it
   periodically originates.  Bootstrap messages are distributed hop-by-
   hop throughout the domain.

   Routers receive and store Bootstrap messages originated by the BSR.
   When a DR gets a membership indication from IGMP for (or a data
   packet from) a directly connected host, for a group for which it has
   no entry, the DR uses a hash function to map the group address to one
   of the C-RPs whose Group-prefix includes the group (see Section 3.7).
   The DR then sends a Join/Prune message towards (or unicasts Registers
   to) that RP.

   The Bootstrap message indicates liveness of the RPs included therein.
   If an RP is included in the message, then it is tagged as `up' at the
   routers; while RPs not included in the message are removed from the
   list of RPs over which the hash algorithm acts. Each router continues
   to use the contents of the most recently received Bootstrap message
   until it receives a new Bootstrap message.

   If a PIM domain partitions, each area separated from the old BSR will
   elect its own BSR, which will distribute an RP-Set containing RPs
   that are reachable within that partition. When the partition heals,
   another election will occur automatically and only one of the BSRs
   will continue to send out Bootstrap messages. As is expected at the
   time of a partition or healing, some disruption in packet delivery
   may occur. This time will be on the order of the region's round-trip
   time and the bootstrap router timeout value.

2.7 Interoperation with dense mode  protocols such as DVMRP

   In order to interoperate with networks that run dense-mode, broadcast
   and prune, protocols, such as DVMRP, all packets generated within a
   PIM-SM region must be pulled out to that region's PIM Multicast
   Border Routers (PMBRs) and injected (i.e., broadcast) into the DVMRP
   network. A PMBR is a router that sits at the boundary of a PIM-SM
   domain and interoperates with other types of multicast routers such
   as those that run DVMRP.  Generally a PMBR would speak both protocols
   and implement interoperability functions not required by regular PIM



Estrin, et. al.               Experimental                      [Page 8]

RFC 2362                         PIM-SM                        June 1998


   routers. To support interoperability, a special entry type, referred
   to as (*,*,RP), must be supported by all PIM routers.  For this
   reason we include details about (*,*,RP) entry handling in this
   general PIM specification.

   A data packet will match on a (*,*,RP) entry if there is no more
   specific entry (such as (S,G) or (*,G)) and the destination group
   address in the packet maps to the RP listed in the (*,*,RP) entry. In
   this sense, a (*,*,RP) entry represents an aggregation of all the
   groups that hash to that RP. PMBRs initialize (*,*,RP) state for each
   RP in the domain's RPset. The (*,*,RP) state causes the PMBRs to send
   (*,*,RP) Join/Prune messages toward each of the active RPs in the
   domain.  As a result distribution trees are built that carry all data
   packets originated within the PIM domain (and sent to the RPs) down
   to the PMBRs.

   PMBRs are also responsible for delivering externally-generated
   packets to routers within the PIM domain. To do so, PMBRs initially
   encapsulate externally-originated packets (i.e., received on DVMRP
   interfaces) in Register messages and unicast them to the
   corresponding RP within the PIM domain. The Register message has a
   bit indicating that it was originated by a border router and the RP
   caches the originating PMBR's address in the route entry so that
   duplicate Registers from other PMBRs can be declined with a
   Register-Stop message.

   All PIM routers must be capable of supporting (*,*,RP) state and
   interpreting associated Join/Prune messages. We describe the handling
   of (*,*,RP) entries and messages throughout this document; however,
   detailed PIM Multicast Border Router (PMBR) functions will be
   specified in a separate interoperability document (see directory,
   http://catarina.usc.edu/pim/interop/).

2.8 Multicast data packet processing

   Data packets are processed in a manner similar to other multicast
   schemes.  A router first performs a longest match on the source and
   group address in the data packet. A (S,G) entry is matched first if
   one exists; a (*,G) entry is matched otherwise. If neither state
   exists, then a (*,*,RP) entry match is attempted as follows: the
   router hashes on G to identify the RP for group G, and looks for a
   (*,*,RP) entry that has this RP address associated with it. If none
   of the above exists, then the packet is dropped. If a state is
   matched, the router compares the interface on which the packet
   arrived to the incoming interface field in the matched route entry.
   If the iif check fails the packet is dropped, otherwise the packet is
   forwarded to all interfaces listed in the outgoing interface list.




Estrin, et. al.               Experimental                      [Page 9]

RFC 2362                         PIM-SM                        June 1998


   Some special actions are needed to deliver packets continuously while
   switching from the shared to shortest-path tree. In particular, when
   a (S,G) entry is matched, incoming packets are forwarded as follows:

      1 If the SPT-bit is set, then:

           1 if the incoming interface is the same as a matching
             (S,G) iif, the packet is forwarded to the oif-list of
             (S,G).

           2 if the incoming interface is different than a matching
             (S,G) iif , the packet is discarded.

      2 If the SPT-bit is cleared, then:

           1 if the incoming interface is the same as a matching
             (S,G) iif, the packet is forwarded to the oif-list of
             (S,G). In addition, the SPT bit is set for that entry if
             the incoming interface differs from the incoming interface
             of the (*,G) or (*,*,RP) entry.

           2 if the incoming interface is different than a matching
             (S,G) iif, the incoming interface is tested against a
             matching (*,G) or (*,*,RP) entry. If the iif is the same as
             one of those, the packet is forwarded to the oif-list of
             the matching entry.

           3 Otherwise the iif does not match any entry for G and
             the packet is discarded.

   Data packets never trigger prunes.  However, data packets may trigger
   actions that in turn trigger prunes. For example, when router B in
   figure 3 decides to switch to SP-tree at step 3, it creates a (S,G)
   entry with SPT-bit set to 0. When data packets from S arrive at
   interface 2 of B, B sets the SPT-bit to 1 since the iif for (*,G) is
   different than that for (S,G). This triggers the sending of prunes
   towards the RP.














Estrin, et. al.               Experimental                     [Page 10]

RFC 2362                         PIM-SM                        June 1998


2.9 Operation over Multi-access Networks

   This section describes a few additional protocol mechanisms needed to
   operate PIM over multi-access networks: Designated Router election,
   Assert messages to resolve parallel paths, and the Join/Prune-
   Suppression-Timer to suppress redundant Joins on multi-access
   networks.

   Designated router election:

   When there are multiple routers connected to a multi-access network,
   one of them must be chosen to operate as the designated router (DR)
   at any point in time.  The DR is responsible for sending triggered
   Join/Prune and Register messages toward the RP.

   A simple designated router (DR) election mechanism is used for both
   SM and traditional IP multicast routing.  Neighboring routers send
   Hello messages to each other. The sender with the largest network
   layer address assumes the role of DR. Each router connected to the
   multi-access LAN sends the Hellos periodically in order to adapt to
   changes in router status.

   Parallel paths to a source or the RP--Assert process:

   If a router receives a multicast datagram on a multi-access LAN from
   a source whose corresponding (S,G) outgoing interface list includes
   the interface to that LAN, the packet must be a duplicate.  In this
   case a single forwarder must be elected.  Using Assert messages
   addressed to `224.0.0.13' (ALL-PIM-ROUTERS group) on the LAN,
   upstream routers can resolve which one will act as the forwarder.
   Downstream routers listen to the Asserts so they know which one was
   elected, and therefore where to send subsequent Joins. Typically this
   is the same as the downstream router's RPF (Reverse Path Forwarding)
   neighbor; but there are circumstances where this might not be the
   case, e.g., when using multiple unicast routing protocols on that
   LAN. The RPF neighbor for a particular source (or RP) is the next-hop
   router to which packets are forwarded en route to that source (or
   RP); and therefore is considered a good path via which to accept
   packets from that source.

   The upstream router elected is the one that has the shortest distance
   to the source. Therefore, when a packet is received on an outgoing
   interface a router sends an Assert message on the multi-access LAN
   indicating what metric it uses to reach the source of the data
   packet. The router with the smallest numerical metric (with ties
   broken by highest address) will become the forwarder. All other





Estrin, et. al.               Experimental                     [Page 11]

RFC 2362                         PIM-SM                        June 1998


   upstream routers will delete the interface from their outgoing
   interface list. The downstream routers also do the comparison in case
   the forwarder is different than the RPF neighbor.

   Associated with the metric is a metric preference value. This is
   provided to deal with the case where the upstream routers may run
   different unicast routing protocols. The numerically smaller metric
   preference is always preferred. The metric preference is treated as
   the high-order part of an assert metric comparison.  Therefore, a
   metric value can be compared with another metric value provided both
   metric preferences are the same.  A metric preference can be assigned
   per unicast routing protocol and needs to be consistent for all
   routers on the multi-access network.

   Asserts are also needed for (*,G) entries since an RP-Tree and an
   SP-Tree for the same group may both cross the same multi-access
   network. When an assert is sent for a (*,G) entry, the first bit in
   the metric preference (RPT-bit) is always set to 1 to indicate that
   this path corresponds to the RP tree, and that the match must be done
   on (*,G) if it exists. Furthermore, the RPT-bit is always cleared for
   metric preferences that refer to SP-tree entries; this causes an SP-
   tree path to always look better than an RP-tree path. When the SP-
   tree and RPtree cross the same LAN, this mechanism eliminates the
   duplicates that would otherwise be carried over the LAN.

   In case the packet, or the Assert message, matches on oif for
   (*,*,RP) entry, a (*,G) entry is created, and asserts take place as
   if the matching state were (*,G).

   The DR may lose the (*,G) Assert process to another router on the LAN
   if there are multiple paths to the RP through the LAN.  From then on,
   the DR is no longer the last-hop router for local receivers and
   removes the LAN from its (*,G) oif list. The winning router becomes
   the last-hop router and is responsible for sending (*,G) join
   messages to the RP.

   Join/Prune suppression:

   Join/Prune suppression may be used on multi-access LANs to reduce
   duplicate control message overhead; it is not required for correct
   performance of the protocol. If a Join/Prune message arrives and
   matches on the incoming interface for an existing (S,G), (*,G), or
   (*,*,RP) route entry, and the Holdtime included in the Join/Prune
   message is greater than the recipient's own [Join/Prune-Holdtime]
   (with ties resolved in favor of the higher network layer address), a
   timer (the Join/Prune-Suppression-timer) in the recipient's route
   entry may be started to suppress further Join/Prune messages. After
   this timer expires, the recipient triggers a Join/Prune message, and



Estrin, et. al.               Experimental                     [Page 12]

RFC 2362                         PIM-SM                        June 1998


   resumes sending periodic Join/Prunes, for this entry. The
   Join/Prune-Suppression-timer should be restarted each time a
   Join/Prune message is received with a higher Holdtime.

2.10 Unicast Routing Changes

   When unicast routing changes, an RPF check is done on all active
   (S,G), (*,G) and (*,*,RP) entries, and all affected expected incoming
   interfaces are updated.  In particular, if the new incoming interface
   appears in the outgoing interface list, it is deleted from the
   outgoing interface list. The previous incoming interface may be added
   to the outgoing interface list by a subsequent Join/Prune from
   downstream.  Join/Prune messages received on the current incoming
   interface are ignored.  Join/Prune messages received on new
   interfaces or existing outgoing interfaces are not ignored. Other
   outgoing interfaces are left as is until they are explicitly pruned
   by downstream routers or are timed out due to lack of appropriate
   Join/Prune messages. If the router has a (S,G) entry with the SPT-bit
   set, and the updated iif(S,G) does not differ from iif(*,G) or
   iif(*,*,RP), then the router resets the SPT-bit.

   The router must send a Join/Prune message with S in the Join list out
   any new incoming interfaces to inform upstream routers that it
   expects multicast datagrams over the interface.  It may also send a
   Join/Prune message with S in the Prune list out the old incoming
   interface, if the link is operational, to inform upstream routers
   that this part of the distribution tree is going away.

2.11 PIM-SM for Inter-Domain Multicast

   Future documents will address the use of PIM-SM as a backbone inter-
   domain multicast routing protocol. Design choices center primarily
   around the distribution and usage of RP information for wide area,
   inter-domain groups.

2.12 Security

   All PIM control messages may use IPsec [6] to address security
   concerns.  Security mechanisms are likely to be enhanced in the near
   future.

3 Detailed Protocol Description

   This section describes the protocol operations from the perspective
   of an individual router implementation.  In particular, for each
   message type we describe how it is generated and processed.





Estrin, et. al.               Experimental                     [Page 13]

RFC 2362                         PIM-SM                        June 1998


3.1 Hello

   Hello messages are sent so neighboring routers can discover each
   other.

3.1.1 Sending Hellos

   Hello messages are sent periodically between PIM neighbors, every
   [Hello-Period] seconds.  This informs routers what interfaces have
   PIM neighbors.  Hello messages are multicast using address 224.0.0.13
   (ALL-PIM-ROUTERS group). The packet includes a Holdtime, set to
   [Hello-Holdtime], for neighbors to keep the information valid. Hellos
   are sent on all types of communication links.

3.1.2 Receiving Hellos

   When a router receives a Hello message, it stores the network layer
   address for that neighbor, sets its Neighbor-timer for the Hello
   sender to the Holdtime included in the Hello, and determines the
   Designated Router (DR) for that interface. The highest addressed
   system is elected DR.  Each Hello received causes the DR's address to
   be updated.

   When a router that is the active DR receives a Hello from a new
   neighbor (i.e., from an address that is not yet in the DRs neighbor
   table), the DR unicasts its most recent RP-set information to the new
   neighbor.

3.1.3 Timing out neighbor entries

   A periodic process is run to time out PIM neighbors that have not
   sent Hellos. If the DR has gone down, a new DR is chosen by scanning
   all neighbors on the interface and selecting the new DR to be the one
   with the highest network layer address. If an interface has gone
   down, the router may optionally time out all PIM neighbors associated
   with the interface.

3.2 Join/Prune

   Join/Prune messages are sent to join or prune a branch off of the
   multicast distribution tree. A single message contains both a join
   and prune list, either one of which may be null.  Each list contains
   a set of source addresses, indicating the source-specific trees or
   shared tree that the router wants to join or prune.







Estrin, et. al.               Experimental                     [Page 14]

RFC 2362                         PIM-SM                        June 1998


3.2.1 Sending Join/Prune Messages

   Join/Prune messages are merged such that a message sent to a
   particular upstream neighbor, N, includes all of the current joined
   and pruned sources that are reached via N; according to unicast
   routing Join/Prune messages are multicast to all routers on multi-
   access networks with the target address set to the next hop router
   towards S or RP. Join/Prune messages are sent every [Join/Prune-
   Period] seconds. In the future we will introduce mechanisms to rate-
   limit this control traffic on a hop by hop basis, in order to avoid
   excessive overhead on small links.  In addition, certain events cause
   triggered Join/Prune messages to be sent.

   Periodic Join/Prune Messages:

   A router sends a periodic Join/Prune message to each distinct RPF
   neighbor associated with each (S,G), (*,G) and (*,*,RP) entry.
   Join/Prune messages are only sent if the RPF neighbor is a PIM
   neighbor.  A periodic Join/Prune message sent to a particular RPF
   neighbor is constructed as follows:

      1 Each router determines the RP for a (*,G) entry by using
        the hash function described. The RP address (with RPT and WC
        bits set) is included in the join list of a periodic Join/Prune
        message under the following conditions:

           1 The Join/Prune message is being sent to the RPF
             neighbor toward the RP for an active (*,G) or (*,*,RP)
             entry, and

           2 The outgoing interface list in the (*,G) or (*,*,RP)
             entry is non-NULL, or the router is the DR on the same
             interface as the RPF neighbor.

      2 A particular source address, S, is included in the join
        list with the RPT and WC bits cleared under the following
        conditions:

           1 The Join/Prune message is being sent to the RPF
             neighbor toward S, and

           2 There exists an active (S,G) entry with the RPT-bit
             flag cleared, and

           3 The oif list in the (S,G) entry is not null.






Estrin, et. al.               Experimental                     [Page 15]

RFC 2362                         PIM-SM                        June 1998


      3 A particular source address, S, is included in the prune
        list with the RPT and WC bits cleared under the following
        conditions:

           1 The Join/Prune message is being sent to the RPF
             neighbor toward S, and

           2 There exists an active (S,G) entry with the RPT-bit
             flag cleared, and

           3 The oif list in the (S,G) entry is null.

      4 A particular source address, S, is included in the prune
        list with the RPT-bit set and the WC bit cleared under the
        following conditions:

           1 The Join/Prune message is being sent to the RPF
             neighbor  toward the RP and there exists a (S,G) entry with
             the RPT-bit flag   set and null oif list, or

           2 The Join/Prune message is being sent to the RPF
             neighbor toward the RP, there exists a (S,G) entry with the
             RPT-bit flag cleared and SPT-bit set, and the incoming
             interface toward S is different than the incoming interface
             toward the RP, or

           3 The Join/Prune message is being sent to the RPF
             neighbor toward the RP, and there exists a (*,G) entry and
             (S,G) entry for a directly connected source.

      5 The RP address (with RPT and WC bits set) is included in
        the prune list if:

           1 The Join/Prune message is being sent to the RPF
             neighbor toward the RP and there exists a (*,G) entry with
             a null oif list (see Section 3.5.2).

      Triggered Join/Prune Messages:

      In addition to periodic messages, the following events will
      trigger Join/Prune messages if as a result, a) a new entry is
      created, or b) the oif list changes from null to non-null or non-
      null to null. The contents of triggered messages are the same as
      the periodic, described above.

      1 Receipt of an indication from IGMP that the state of
        directly-connected-membership has changed (i.e., new members
        have just joined `membership indication' or all members have



Estrin, et. al.               Experimental                     [Page 16]

RFC 2362                         PIM-SM                        June 1998


        left), for a group G, may cause the last-hop router to build or
        modify corresponding (*,G) state.  When IGMP indicates that
        there are no longer directly connected members, the oif is
        removed from the oif list if the oif-timer is not running. A
        Join/Prune message is triggered if and only if a) a new entry is
        created, or b) the oif list changes from null to non-null or
        non-null to null, as follows:

           1 If the receiving router does not have a route entry
             for G the router creates a (*,G) entry, copies the oif list
             from the corresponding (*,*,RP) entry (if it exists), and
             includes the interface included in the IGMP membership
             indication in the oif list; as always, the router never
             includes the entry's iif in the oif list. The router sends
             a Join/Prune message towards the RP with the RP address and
             RPT-bit and WC-bits set in the join list. Or,

           2 If a (S,G)RPT-bit or (*,G) entry already exists, the
             interface included in the IGMP membership indication is
             added to the oif list (if it was not included already).

      2 Receipt of a Join/Prune message for (S,G), (*,G) or
        (*,*,RP) will cause building or modifying corresponding state,
        and subsequent triggering of upstream Join/Prune messages, in
        the following cases:

           1 When there is no current route entry, the RP address
             included in the Join/Prune message is checked against the
             local RP-Set information. If it matches, an entry will be
             created and the new entry will in turn trigger an upstream
             Join/Prune message. If the router has no RP-Set information
             it may discard the message, or optionally use the RP
             address included in the message.

           2 When the outgoing interface list of an (S,G)RPT-bit
             entry becomes null, the triggered Join/Prune message will
             contain S in the prune list.

           3 When there exists a (S,G)RPT-bit with null oif list,
             and an (*,G) Join/Prune message is received, the arriving
             interface is added to the oif list and a (*,G) Join/Prune
             message is triggered upstream.

           4 When there exists a (*,G) with null oif list, and a
             (*,*,RP) Join/Prune message is received, the receiving
             interface is added to the oif list and a (*,*,RP)
             Join/Prune message is triggered upstream.




Estrin, et. al.               Experimental                     [Page 17]

RFC 2362                         PIM-SM                        June 1998


      3 Receipt of a packet that matches on a (S,G) entry whose
        SPT-bit is cleared triggers the following if the packet arrived
        on the correct incoming interface and there is a (*,G) or
        (*,*,RP) entry with a different incoming interface: a) the
        router sets the SPT-bit on the (S,G) entry, and b) the router
        sends a Join/Prune message towards the RP with S in the prune
        list and the RPT-bit set.

      4 Receipt of a packet at the DR from a directly connected
        source S, on the subnet containing the address S, triggers a
        Join/Prune message towards the RP with S in the prune list and
        the RPT-bit set under the following conditions: a) there is no
        matching (S,G) state, and b) there exists a (*,G) or (*,*,RP)
        for which the DR is not the RP.

      5 When a Join/Prune message is received for a group G, the
        prune list is checked. If the prune list contains a source or RP
        for which the receiving router has a corresponding active (S,G),
        (*,G) or (*,*,RP) entry, and whose iif is that on which the
        Join/Prune was received, then a join for (S,G), (*,G) or
        (*,*,RP) is triggered to override the prune, respectively. (This
        is necessary in the case of parallel downstream routers
        connected to a multi-access network.)

      6 When the RP fails, the RP will not be included in the
        Bootstrap messages sent to all routers in that domain. This
        triggers the DRs to send (*,G) Join/Prune messages towards the
        new RP for the group, as determined by the RP-Set and the hash
        function.  As described earlier, PMBRs trigger (*,*,RP) joins
        towards each RP in the RP-Set.

      7 When an entry's Join/Prune-Suppression timer expires, a
        Join/Prune message is triggered upstream corresponding to that
        entry, even if the outgoing interface has not transitioned
        between null and non-null states.

      8 When the RPF neighbor changes (whether due to an Assert or
        changes in unicast routing), the router sets a random delay
        timer (the Random-Delay-Join-Timer) whose expiration triggers
        sending of a Join/Prune message for the asserted route entry to
        the Assert winner (if the Join/Prune Suppression timer has
        expired.)

   We do not trigger prunes onto interfaces based on data packets.  Data
   packets that arrive on the wrong incoming interface are silently
   dropped.  However, on point-to-point interfaces triggered prunes may
   be sent as an optimization.




Estrin, et. al.               Experimental                     [Page 18]

RFC 2362                         PIM-SM                        June 1998


   aragraphFragmentation It is possible that a Join/Prune message
   constructed according to the preceding rules could exceed the MTU of
   a network. In this case, the message can undergo semantic
   fragmentation whereby information corresponding to different groups
   can be sent in different messages.  However, if a Join/Prune message
   must be fragmented the complete prune list corresponding to a group G
   must be included in the same Join/Prune message as the associated
   RP-tree Join for G. If such semantic fragmentation is not possible,
   IP fragmentation should be used between the two neighboring hops.

3.2.2 Receiving  Join/Prune  Messages  When  a  router  receives
      Join/Prune message, it processes it as follows.

   The receiver of the Join/Prune notes the interface on which the PIM
   message arrived, call it I. The receiver then checks to see if the
   Join/Prune message was addressed to the receiving router itself
   (i.e., the router's address appears in the Unicast Upstream Neighbor
   Router field of the Join/Prune message).  (If the router is connected
   to a multiaccess LAN, the message could be intended for a different
   router.) If the Join/Prune is for this router the following actions
   are taken.

   For each group address G, in the Join/Prune message, the associated
   join list is processed as follows. We refer to each address in the
   join list as Sj; Sj refers to the RP if the RPT-bit and WC-bit are
   both set. For each Sj in the join list of the Join/Prune message:

      1 If an address, Sj, in the join list of the Join/Prune
        message has the RPT-bit and WC-bit set, then Sj is the RP
        address used by the downstream router(s) and the following
        actions are taken:

           1 If Sj is not the same as the receiving router's RP
             mapping for G, the receiving router may ignore the
             Join/Prune message with respect to that group entry.  If
             the router does not have any RP-Set information, it may use
             the address Sj included in the Join/Prune message as the RP
             for the group.

           2 If Sj is the same as the receiving router's RP mapping
             for G, the receiving router adds I to the outgoing
             interface list of the (*,G) route entry (if there is no
             (*,G) entry, the router creates one first) and sets the
             Oif-timer for that interface to the Holdtime specified in
             the Join/Prune message. In addition, the Oif-Deletion-Delay
             for that interface is set to 1/3rd the Holdtime specified





Estrin, et. al.               Experimental                     [Page 19]

RFC 2362                         PIM-SM                        June 1998


             in the Join/Prune message. If a (*,*,RP) entry exists, for
             the RP associated with G, then the oif list of the newly
             created (*,G) entry is copied from that (*,*,RP) entry.

           3 For each (Si,G) entry associated with group G: i) if
             Si is not included in the prune list, ii) if I is not on
             the same subnet as the address Si, and iii) if I is not the
             iif, then interface I is added to the oif list and the
             Oif-timer for that interface in each affected entry is
             increased (never decreased) to the Holdtime included in the
             Join/Prune message.  In addition, if the Oif-timer for that
             interface is increased, the Oif-Deletion-Delay for that
             interface is set to 1/3rd the Holdtime specified in the
             Join/Prune message.

             If the group address in the Join/Prune message is `*' then
             every (*,G) and (S,G) entry, whose group address hashes to
             the RP indicated in the (*,*,RP) Join/Prune message, is
             updated accordingly. A `*' in the group field of the
             Join/Prune is represented by a group address 224.0.0.0 and
             a group mask length of 4, indicating a (*,*,RP) Join.

           4 If the (Si,G) entry has its RPT-bit flag set to 1, and
             its oif list is the same as the (*,G) oif list, then the
             (Si,G)RPT-bit entry is deleted,

           5 The incoming interface is set to the interface used to
             send unicast packets to the RP in the (*,G) route entry,
             i.e., RPF interface toward the RP.

      2 For each address, Sj, in the join list whose RPT-bit and
        WC-bit are not set, and for which there is no existing (Sj,G)
        route entry, the router initiates one.  The router creates a
        (S,G) entry and copies all outgoing interfaces from the
        (S,G)RPT-bit entry, if it exists. If there is no (S,G) entry,
        the oif list is copied from the (*,G) entry; and if there is no
        (*,G) entry, the oif list is copied from the (*,*,RP) entry, if
        it exists. In all cases, the iif of the (S,G) entry is always
        excluded from the oif list.

           1 The outgoing interface for (Sj,G) is set to I.  The
             incoming interface for (Sj,G) is set to the interface used
             to send unicast packets to Sj (i.e., the RPF neighbor).

           2 If the interface used to reach Sj, is the same as I,
             this represents an error (or a unicast routing change) and
             the Join/Prune must not be processed.




Estrin, et. al.               Experimental                     [Page 20]

RFC 2362                         PIM-SM                        June 1998


      3 For each address, Sj, in the join list of the Join/Prune
        message, for which there is an existing (Sj,G) route entry,

           1 If the RPT-bit is not set for Sj listed in the
             Join/Prune message, but the RPT-bit flag is set on the
             existing (Sj,G) entry, the router clears the RPT-bit flag
             on the (Sj,G) entry, sets the incoming interface to point
             towards Sj for that (Sj,G) entry, and sends a Join/Prune
             message corresponding to that entry through the new
             incoming interface; and

           2 If I is not the same as the existing incoming
             interface, the router adds I to the list of outgoing
             interfaces.

           3 The Oif-timer for I is increased (never decreased) to
             the Holdtime included in the Join/Prune message. In
             addition, if the Oif-timer for that interface is increased,
             the Oif-Deletion-Delay for that interface is set to 1/3rd
             the Holdtime specified in the Join/Prune message.

           4 The (Sj,G) entry's SPT bit is cleared until data comes
             down the shortest path tree.

      For each group address G, in the Join/Prune message, the
      associated prune list is processed as follows. We refer to each
      address in the prune list as Sp; Sp refers to the RP if the RPT-
      bit and WC-bit are both set. For each Sp in the prune list of the
      Join/Prune message:

      1 For each address, Sp, in the prune list whose RPT-bit and
        WC-bit are cleared:

           1 If there is an existing (Sp,G) route entry, the router
             lowers the entry's Oif-timer for I to its Oif-Deletion-
             Delay, allowing for other downstream routers on a multi-
             access LAN to override the prune. However, on point-to-
             point links, the oif-timer is expired immediately.

           2 If the router has a current (*,G), or (*,*,RP), route
             entry, and if the existing (Sp,G) entry has its RPT-bit
             flag set to 1, then this (Sp,G)RPT-bit entry is maintained
             (not deleted) even if its outgoing interface list is null.

      2 For each address, Sp, in the prune list whose RPT-bit is
        set and whose WC-bit cleared:





Estrin, et. al.               Experimental                     [Page 21]

RFC 2362                         PIM-SM                        June 1998


           1 If there is an existing (Sp,G) route entry, the router
             lowers the entry's Oif-timer for I to its Oif-Deletion-
             Delay, allowing for other downstream routers on a multi-
             access LAN to override the prune. However, on point-to-
             point links, the oif-timer is expired immediately.

           2 If the router has a current (*,G), or (*,*,RP), route
             entry, and if the existing (Sp,G) entry has its RPT-bit
             flag set to 1, then this (Sp,G)RPT-bit entry is not
             deleted, and the Entry-timer is restarted, even if its
             outgoing interface list is null.

           3 If (*,G), or corresponding (*,*,RP), state exists, but
             there is no (Sp,G) entry, an (Sp,G)RPT-bit entry is created
             . The outgoing interface list is copied from the (*,G), or
             (*,*,RP), entry, with the interface, I, on which the prune
             was received, is deleted.  Packets from the pruned source,
             Sp, match on this state and are not forwarded toward the
             pruned receivers.

           4 If there exists a (Sp,G) entry, with or without the
             RPT-bit set, the oif-timer for I is expired, and the
             Entry-timer is restarted.

      3 For each address, Sp, in the prune list whose RPT-bit and
        WC-bit are both set:

           1 If there is an existing (*,G) entry, with Sp as the RP
             for G, the router lowers the entry's Oif-timer for I to its
             Oif-Deletion-Delay, allowing for other downstream routers
             on a multi-access LAN to override the prune. However, on
             point-to-point links, the oif-timer is expired immediately.

           2 If the corresponding (*,*,RP) state exists, but there
             is no (*,G) entry, a (*,G) entry is created. The outgoing
             interface list is copied from (*,*,RP) entry, with the
             interface, I, on which the prune was received, deleted.

           For any new (S,G), (*,G) or (*,*,RP) entry created by an
           incoming Join/Prune message, the SPT-bit is cleared (and if a
           Join/Prune-Suppression timer is used, it is left off.)

   If the entry has a Join/Prune-Suppression timer associated with it,
   and if the received Join/Prune does not indicate the router as its
   target, then the receiving router examines the join and prune lists
   to see if any addresses in the list `completely-match' existing
   (S,G), (*,G), or (*,*,RP) state for which the receiving router
   currently schedules Join/Prune messages. An element on the join or



Estrin, et. al.               Experimental                     [Page 22]

RFC 2362                         PIM-SM                        June 1998


   prune list `completely-matches' a route entry only if both the
   addresses and RPT-bit flag are the same.  If the incoming Join/Prune
   message completely matches an existing (S,G), (*,G), or (*,*,RP)
   entry and the Join/Prune arrived on the iif for that entry, then the
   router compares the Holdtime included in the Join/Prune message, to
   its own [Join/Prune-Holdtime]. If its own [Join/Prune-Holdtime] is
   lower, the Join/Prune-Suppression-timer is started at the
   [Join/Prune-Suppression-Timeout]. If the [Join/Prune-Holdtime] is
   equal, the tie is resolved in favor of the Join/Prune Message
   originator that has the higher network layer address.  When the
   Join/Prune timer expires, the router triggers a Join/Prune message
   for the corresponding entry(ies).

3.3 Register and Register-Stop

   When a source first starts sending to a group its packets are
   encapsulated in Register messages and sent to the RP. If the data
   rate warrants source-specific paths, the RP sets up source specific
   state and starts sending (S,G) Join/Prune messages toward the source,
   with S in the join list.

3.3.1 Sending Registers and Receiving Register-Stops

   Register messages are sent as follows:

      1 When a DR receives a packet from a directly connected
        source, S, on the subnet containing the address S,

           1 If there is no corresponding (S,G) entry, and the
             router has RP-Set information, and the DR is not the RP for
             G, the DR creates an (S,G) entry with the Register-
             Suppression-timer turned off and the RP address set
             according to the hash function mapping for the
             corresponding group. The oif list is copied from existing
             (*,G) or (*,*,RP) entries, if they exist. The iif of the
             (S,G) entry is always excluded from the oif list. If there
             exists a (*,G) or (*,*,RP) entry, the DR sends a Join/Prune
             message towards the RP with S in the prune list and the
             RPT-bit set.

           2 If there is a (S,G) entry in existence, the DR simply
             restarts the corresponding Entry-timer.

           When a PMBR (e.g., a router that connects the PIM-SM region
           to a dense mode region running DVMRP or PIM-DM) receives a
           packet from a source in the dense mode region, the router





Estrin, et. al.               Experimental                     [Page 23]

RFC 2362                         PIM-SM                        June 1998


           treats the packet as if it were from a directly connected
           source. A separate document will describe the details of
           interoperability.

      2 If the new or previously-existing (S,G) entry's Register-
        Suppression-timer is not running, the data packet is
        encapsulated in a Register message and unicast to the RP for
        that group. The data packet is also forwarded according to (S,G)
        state in the DR if the oif list is not null; since a receiver
        may join the SP-tree while the DR is still registering to the
        RP.

      3 If the (S,G) entry's Register-Suppression-timer is running,
        the data packet is not sent in a Register message, it is just
        forwarded according to the (S,G) oif list.

   When the DR receives a Register-Stop message, it restarts the
   Register-Suppression-timer in the corresponding (S,G) entry(ies) at
   [Register-Suppression-Timeout] seconds. If there is data to be
   registered, the DR may send a null Register (a Register message with
   a zero-length data portion in the inner packet) to the RP, [Probe-
   Time] seconds before the Register-Suppression-timer expires, to avoid
   sending occasional bursts of traffic to an RP unnecessarily.

3.3.2 Receiving Register Messages and Sending Register-Stops

   When a router (i.e., the RP) receives a Register message, the router
   does the following:

      1 Decapsulates the data packet, and checks for a
        corresponding (S,G) entry.

           1 If a (S,G) entry with cleared (0) SPT bit exists, and
             the received Register does not have the Null-Register-Bit
             set to 1, the packet is forwarded; and the SPT bit is left
             cleared (0). If the SPT bit is 1, the packet is dropped,
             and Register-Stop messages are triggered.  Register-Stops
             should be rate-limited (in an implementation-specific
             manner) so that no more than a few are sent per round trip
             time. This prevents a high datarate stream of packets from
             triggering a large number of Register-Stop messages between
             the time that the first packet is received and the time
             when the source receives the first Register-Stop.

           2 If there is no (S,G) entry, but there is a (*,G)
             entry, and the received Register does not have the Null-
             Register-Bit set to 1, the packet is forwarded according to
             the (*,G) entry.



Estrin, et. al.               Experimental                     [Page 24]

RFC 2362                         PIM-SM                        June 1998


           3 If there is a (*,*,RP) entry but no (*,G) entry, and
             the Register received does not have the Null-Register-Bit
             set to 1, a (*,G) or (S,G) entry is created and the oif
             list is copied from the (*,*,RP) entry to the new entry.
             The packet is forwarded according to the created entry.

           4 If there is no G or (*,*,RP) entry corresponding to G,
             the packet is dropped, and a Register-Stop is triggered.

           5 A "Border bit" bit is added to the Register message,
             to  facilitate  interoperability mechanisms. PMBRs set this
             bit when   registering for  external  sources  (see Section
             2.7).  If  the  "Border bit" is set in the Register,
             the   RP does the following:

                1 If there is no matching (S,G) state, but there
                  exists (*,G) or (*,*,RP) entry, the RP creates a (S,G)
                  entry, with a `PMBR' field.  This field holds the
                  source of the Register (i.e. the outer network layer
                  address of the register packet).  The RP triggers a
                  (S,G) join towards the source of the data packet, and
                  clears the SPT bit for the (S,G) entry. If the
                  received Register is not a `null Register' the packet
                  is forwarded according to the created state. Else,

                2 If the `PMBR' field for the corresponding (S,G)
                  entry matches the source of the Register packet, and
                  the received Register is not a `null Register', the
                  decapsulated packet is forwarded to the oif list of
                  that entry. Else,

                3 If the `PMBR' field for the corresponding (S,G)
                  entry matches the source of the Register packet, the
                  decapsulated packet is forwarded to the oif list of
                  that entry, else

                4 The packet is dropped, and a Register-stop is
                  triggered towards the source of the Register.

        The (S,G) Entry-timer is restarted by Registers arriving from
        that source to that group.

      2 If the matching (S,G) or (*,G) state contains a null oif
        list, the RP unicasts a Register-Stop message to the source of
        the Register message; in the latter case, the source-address
        field, within the Register-Stop message, is set to the wildcard





Estrin, et. al.               Experimental                     [Page 25]

RFC 2362                         PIM-SM                        June 1998


        value (all 0's). This message is not processed by intermediate
        routers, hence no (S,G) state is constructed between the RP and
        the source.

      3 If the Register message arrival rate warrants it and there
        is no existing (S,G) entry, the RP sets up a (S,G) route entry
        with the outgoing interface list, excluding iif(S,G), copied
        from the (*,G) outgoing interface list, its SPT-bit is
        initialized to 0. If a (*,G) entry does not exist, but there
        exists a (*,*,RP) entry with the RP corresponding to G , the oif
        list for (S,G) is copied - excluding the iif - from that
        (*,*,RP) entry.

        A timer (Entry-timer) is set for the (S,G) entry and this timer
        is restarted by receipt of data packets for (S,G).  The (S,G)
        entry causes the RP to send a Join/Prune message for the
        indicated group towards the source of the register message.

        If the (S,G) oif list becomes null, Join/Prune messages will not
        be sent towards the source, S.

3.4 Multicast Data Packet Forwarding

   Processing a multicast data packet involves the following steps:

      1 Lookup route state based on a longest match of the source
        address, and an exact match of the destination address in the
        data packet. If neither S, nor G, find a longest match entry,
        and the RP for the packet's destination group address has a
        corresponding (*,*,RP) entry, then the longest match does not
        require an exact match on the destination group address. In
        summary, the longest match is performed in the following order:
        (1) (S,G), (2) (*,G). If neither is matched, then a lookup is
        performed on (*,*,RP) entries.

      2 If the packet arrived on the interface found in the
        matching-entry's iif field, and the oif list is not null:

           1 Forward the packet to the oif list for that entry,
             excluding the subnet containing S, and restart the Entry-
             timer if the matching entry is (S,G).  Optionally, the
             (S,G) Entry-timer may be restarted by periodic checking of
             the matching packet count.








Estrin, et. al.               Experimental                     [Page 26]

RFC 2362                         PIM-SM                        June 1998


           2 If the entry is a (S,G) entry with a cleared SPT-bit,
             and a (*,G) or associated (*,*,RP) also exists whose
             incoming interface is different than that for (S,G), set
             the SPT-bit for the (S,G) entry and trigger an (S,G) RPT-
             bit prune towards the RP.

           3 If the source of the packet is a directly-connected
             host and the router is the DR on the receiving interface,
             check the Register-Suppression-timer associated with the
             (S,G) entry. If it is not running, then the router
             encapsulates the data packet in a register message and
             sends it to the RP.

             This covers the common case of a packet arriving on the RPF
             interface to the source or RP and being forwarded to all
             joined branches. It also detects when packets arrive on the
             SP-tree, and triggers their pruning from the RP-tree. If it
             is the DR for the source, it sends data packets
             encapsulated in Registers to the RPs.

           3 If the packet matches to an entry but did not arrive on the
             interface found in the entry's iif field, check the SPT-bit
             of the entry. If the SPT-bit is set, drop the packet.  If
             the SPT-bit is cleared, then lookup the (*,G), or (*,*,RP),
             entry for G. If the packet arrived on the iif found in
             (*,G), or the corresponding (*,*,RP), forward the packet to
             the oif list of the matching entry. This covers the case
             when a data packet matches on a (S,G) entry for which the
             SP-tree has not yet been completely established upstream.

           4 If the packet does not match any entry, but the source of
             the data packet is a local, directly-connected host, and
             the router is the DR on a multi-access LAN and has RP-Set
             information, the DR uses the hash function to determine the
             RP associated with the destination group, G. The DR creates
             a (S,G) entry, with the Register-Suppression-timer not
             running, encapsulates the data packet in a Register message
             and unicasts it to the RP.

           5 If the packet does not match to any entry, and it is not a
             local host or the router is not the DR, drop the packet.

3.4.1 Data triggered switch to shortest path tree (SP-tree)

   Different criteria can be applied to trigger switching over from the
   RP-based shared tree to source-specific, shortest path trees.





Estrin, et. al.               Experimental                     [Page 27]

RFC 2362                         PIM-SM                        June 1998


   One proposed example is to do so based on data rate.  For example,
   when a (*,G), or corresponding (*,*,RP), entry is created, a data
   rate counter may be initiated at the last-hop routers.  The counter
   is incremented with every data packet received for directly connected
   members of an SM group, if the longest match is (*,G) or (*,*,RP). If
   and when the data rate for the group exceeds a certain configured
   threshold (t1), the router initiates `source-specific' data rate
   counters for the following data packets. Then, each counter for a
   source, is incremented when packets matching on (*,G), or (*,*,RP),
   are received from that source. If the data rate from the particular
   source exceeds a configured threshold (t2), a (S,G) entry is created
   and a Join/Prune message is sent towards the source.  If the RPF
   interface for (S,G) is not the same as that for (*,G) -or (*,*,RP),
   then the SPT-bit is cleared in the (S,G) entry.

   Other configured rules may be enforced to cause or prevent
   establishment of (S,G) state.

3.5 Assert

   Asserts are used to resolve which of the parallel routers connected
   to a multi-access LAN is responsible for forwarding packets onto the
   LAN.

3.5.1 Sending Asserts

   The following Assert rules are provided when a multicast packet is
   received on an outgoing multi-access interface "I" of an existing
   active (S,G), (*,G) or (*,*,RP) entry:

      1 Do unicast routing table lookup on source address from data
        packet, and send assert on interface "I" for source address in
        data packet; include metric preference of routing protocol and
        metric from routing table lookup.

      2 If route is not found, use metric preference of 0x7fffffff
        and metric 0xffffffff.

   When an assert is sent for a (*,G) entry, the first bit in the metric
   preference (the RPT-bit) is set to 1, indicating the data packet is
   routed down the RP-tree.

   Asserts should be rate-limited in an implementation-specific manner.








Estrin, et. al.               Experimental                     [Page 28]

RFC 2362                         PIM-SM                        June 1998


3.5.2 Receiving Asserts

   When an Assert is received the router performs a longest match on the
   source and group address in the Assert message, only active entries
   -- that have packet forwarding state -- are matched.  The router
   checks the first bit of the metric preference (RPT-bit).

      1 If the RPT-bit is set, the router first does a match on
        (*,G), or (*,*,RP), entries; if no matching entry is found, it
        ignores the Assert.

      2 If the RPT-bit is not set in the Assert, the router first
        does a match on (S,G) entries; if no matching entry is found,
        the router matches (*,G) or (*,*,RP) entries.

      Receiving Asserts on an entry's outgoing interface:

      If the interface that received the Assert message is in the oif
      list of the matched entry, then this Assert is processed by this
      router as follows:

      1 If the Assert's RPT-bit is set and the matching entry is
        (*,*,RP), the router creates a (*,G) entry. If the Assert's
        RPT-bit is cleared and the matching entry is (*,G), or (*,*,RP),
        the router creates a (S,G)RPT-bit entry.  Otherwise, no new
        entry is created in response to the Assert.

      2 The router then compares the metric values received in the
        Assert with the metric values associated with the matched entry.
        The RPT-bit and metric preference (in that order) are treated as
        the high-order part of an Assert metric comparison. If the value
        in the Assert is less than the router's value (with ties broken
        by the IP address, where higher network layer address wins),
        delete the interface from the entry. When the deletion occurs
        for a (*,G) or (*,*,RP) entry , the interface is also deleted
        from any associated (S,G)RPT-bit or (*,G) entries, respectively.
        The Entry-timer for the affected entries is restarted.

      3 If the router has won the election the router keeps the
        interface in its outgoing interface list. It acts as the
        forwarder for the LAN.

   The winning router sends an Assert message containing its own metric
   to that outgoing interface. This will cause other routers on the LAN
   to prune that interface from their route entries. The winning router
   sets the RPT-bit in the Assert message if a (*,G) or (S,G)RPT-bit
   entry was matched.




Estrin, et. al.               Experimental                     [Page 29]

RFC 2362                         PIM-SM                        June 1998


   Receiving Asserts on an entry's incoming interface

   If the Assert arrived on the incoming interface of an existing (S,G),
   (*,G), or (*,*,RP) entry, the Assert is processed as follows.  If the
   Assert message does not match the entry, exactly, it is ignored; i.e,
   longest-match is not used in this case. If the Assert message does
   match exactly, then:

      1 Downstream routers will select the upstream router with the
        smallest metric preference and metric as their RPF neighbor. If
        two metrics are the same, the highest network layer address is
        chosen to break the tie. This is important so that downstream
        routers send subsequent Joins/Prunes (in SM) to the correct
        neighbor. An Assert-timer is initiated when changing the RPF
        neighbor to the Assert winner.  When the timer expires, the
        router resets its RPF neighbor according to its unicast routing
        tables to capture network dynamics and router failures.

      2 If the downstream routers have downstream members, and if
        the Assert caused the RPF neighbor to change, the downstream
        routers must trigger a Join/Prune message to inform the upstream
        router that packets are to be forwarded on the multi-access
        network.

3.6 Candidate-RP-Advertisements and Bootstrap messages

   Candidate-RP-Advertisements (C-RP-Advs) are periodic PIM messages
   unicast to the BSR by those routers that are configured as
   Candidate-RPs (C-RPs).

   Bootstrap messages are periodic PIM messages originated by the
   Bootstrap router (BSR) within a domain, and forwarded hop-by-hop to
   distribute the current RP-set to all routers in that domain.

   The Bootstrap messages also support a simple mechanism by which the
   Candidate BSR (C-BSR) with the highest BSR-priority and address
   (referred to as the preferred BSR) is elected as the BSR for the
   domain.  We recommend that each router configured as a C-RP also be
   configured as a C-BSR. Sections 3.6.2 and 3.6.3 describe the combined
   function of Bootstrap messages as the vehicle for BSR election and
   RP-Set distribution.

   A Finite State Machine description of the BSR election and RP-Set
   distribution mechanisms is included in Appendix II.







Estrin, et. al.               Experimental                     [Page 30]

RFC 2362                         PIM-SM                        June 1998


3.6.1 Sending Candidate-RP-Advertisements

   C-RPs periodically unicast C-RP-Advs to the BSR for that domain.  The
   interval for sending these messages is subject to local configuration
   at the C-RP.

   Candidate-RP-Advertisements carry group address and group mask
   fields.  This enables the advertising router to limit the
   advertisement to certain prefixes or scopes of groups.  The
   advertising router may enforce this scope acceptance when receiving
   Registers or Join/Prune messages.  C-RPs should send C-RP-Adv
   messages with the `Priority' field set to `0'.

3.6.2 Receiving C-RP-Advs and Originating Bootstrap

   Upon receiving a C-RP-Adv, a router does the following:

      1 If the router is not the elected BSR, it ignores the
        message, else

      2 The BSR adds the RP address to its local pool of candidate
        RPs, according to the associated group prefix(es) in the C-RP-
        Adv message. The Holdtime in the C-RP-Adv message is also stored
        with the corresponding RP, to be included later in the Bootstrap
        message. The BSR may apply a local policy to limit the number of
        Candidate RPs included in the Bootstrap message.  The BSR may
        override the prefix indicated in a C-RP-Adv unless the
        `Priority' field is not zero.

   The BSR keeps an RP-timer per RP in its local RP-set. The RP-timer is
   initialized to the Holdtime in the RP's C-RP-Adv. When the timer
   expires, the corresponding RP is removed from the RP-set.  The RP-
   timer is restarted by the C-RP-Advs from the corresponding RP.

   The BSR also uses its Bootstrap-timer to periodically send Bootstrap
   messages.  In particular, when the Bootstrap-timer expires, the BSR
   originates a Bootstrap message on each of its PIM interfaces. To
   reduce the bootstrap message overhead during partition healing, the
   BSR should set a random time (as a function of the priority and
   address) after which the Bootstrap message is originated only if no
   other preferred Bootstrap message is received. For details see
   appendix 6.2. The message is sent with a TTL of 1 to the `ALL-PIM-
   ROUTERS' group.  In steady state, the BSR originates Bootstrap
   messages periodically.  At startup, the Bootstrap-timer is
   initialized to [Bootstrap-Timeout], causing the first Bootstrap
   message to be originated only when and if the timer expires. For





Estrin, et. al.               Experimental                     [Page 31]

RFC 2362                         PIM-SM                        June 1998


   timer details, see Section 3.6.3. A DR unicasts a Bootstrap message
   to each new PIM neighbor, i.e., after the DR receives the neighbor's
   Hello message (it does so even if the new neighbor becomes the DR).

   The Bootstrap message is subdivided into sets of group-prefix,RP-
   Count,RP-addresses.  For each RP-address, the corresponding Holdtime
   is included in the "RP-Holdtime" field.  The format of the Bootstrap
   message allows `semantic fragmentation', if the length of the
   original Bootstrap message exceeds the packet maximum boundaries (see
   Section 4). However, we recommend against configuring a large number
   of routers as C-RPs, to reduce the semantic fragmentation required.

3.6.3 Receiving and Forwarding Bootstrap

   Each router keeps a Bootstrap-timer, initialized to [Bootstrap-
   Timeout] at startup.

   When a router receives Bootstrap message sent to `ALL-PIM-ROUTERS'
   group, it performs the following:

      1 If the message was not sent by the RPF neighbor towards the
        BSR address included, the message is dropped. Else

      2 If the included BSR is not preferred over, and not equal
        to, the currently active BSR:

           1 If the Bootstrap-timer has not yet expired, or if the
             receiving router is a C-BSR, then the Bootstrap message is
             dropped. Else

           2 If the Bootstrap-timer has expired and the receiving
             router is not a C-BSR, the receiving router stores the RP-
             Set and BSR address and priority found in the message, and
             restarts the timer by setting it to [Bootstrap-Timeout].
             The Bootstrap message is then forwarded out all PIM
             interfaces, excluding the one over which the message
             arrived, to `ALL-PIM-ROUTERS' group, with a TTL of 1.

      3 If the Bootstrap message includes a BSR address that is
        preferred over, or equal to, the currently active BSR, the
        router restarts its Bootstrap-timer at [Bootstrap-Timeout]
        seconds. and stores the BSR address and RP-Set information.

        The Bootstrap message is then forwarded out all PIM interfaces,
        excluding the one over which the message arrived, to `ALL-PIM-
        ROUTERS' group, with a TTL of 1.





Estrin, et. al.               Experimental                     [Page 32]

RFC 2362                         PIM-SM                        June 1998


      4 If the receiving router has no current RP set information
        and the Bootstrap was unicast to it from a directly connected
        neighbor, the router stores the information as its new RP-set.
        This covers the startup condition when a newly booted router
        obtains the RP-Set and BSR address from its DR.

   When a router receives a new RP-Set, it checks if each of the RPs
   referred to by existing state (i.e., by (*,G), (*,*,RP), or
   (S,G)RPT-bit entries) is in the new RP-Set. If an RP is not in the
   new RP-set, that RP is considered unreachable and the hash algorithm
   (see below) is re-performed for each group with locally active state
   that previously hashed to that RP. This will cause those groups to be
   distributed among the remaining RPs. When the new RP-Set contains a
   new RP, the value of the new RP is calculated for each group covered
   by that C-RP's Group-prefix.  Any group for which the new RP's value
   is greater than the previously active RP's value is switched over to
   the new RP.

3.7 Hash Function

   The hash function is used by all routers within a domain, to map a
   group to one of the C-RPs from the RP-Set. For a particular group, G,
   the hash function uses only those C-RPs whose Group-prefix covers G.
   The algorithm takes as input the group address, and the addresses of
   the Candidate RPs, and gives as output one RP address to be used.

   The protocol requires that all routers hash to the same RP within a
   domain (except for transients). The following hash function must be
   used in each router:

      1 For RP addresses in the RP-Set, whose Group-prefix covers
        G, select the RPs with the highest priority (i.e. lowest
        `Priority' value), and compute a value:

   Value(G,M,C(i))=
   (1103515245 * ((1103515245 * (G&M)+12345) XOR C(i)) + 12345) mod 2^31

        where C_i is the RP address and M is a hash-mask included in
        Bootstrap messages.  The hash-mask allows a small number of
        consecutive groups (e.g., 4) to always hash to the same RP. For
        instance, hierarchically-encoded data can be sent on consecutive
        group addresses to get the same delay and fate-sharing
        characteristics.

        For address families other than IPv4, a 32-bit digest to be used
        as C_i must first be derived from the actual RP address. Such a
        digest method must be used consistently throughout the PIM




Estrin, et. al.               Experimental                     [Page 33]

RFC 2362                         PIM-SM                        June 1998


        domain. For IPv6 addresses, we recommend using the equivalent
        IPv4 address for an IPv4-compatible address, and the CRC-32
        checksum [7] of all other IPv6 addresses.

      2 From the RPs with the highest priority (i.e.  lowest
        `Priority' value), the candidate with the highest resulting
        value is then chosen as the RP for that group, and its identity
        and hash value are stored with the entry created.

        Ties between RPs having the same hash value and priority, are
        broken in advantage of the highest address.

   The hash function algorithm is invoked by a DR, upon reception of a
   packet, or IGMP membership indication, for a group, for which the DR
   has no entry. It is invoked by any router that has (*,*,RP) state
   when a packet is received for which there is no corresponding (S,G)
   or (*,G) entry.  Furthermore, the hash function is invoked by all
   routers upon receiving a (*,G) or (*,*,RP) Join/Prune message.

3.8 Processing Timer Events

   In this subsection, we enumerate all timers that have been discussed
   or implied. Since some critical timer events are not associated with
   the receipt or sending of messages, they are not fully covered by
   earlier subsections.

   Timers are implemented in an implementation-specific manner. For
   example, a timer may count up or down, or may simply expire at a
   specific time. Setting a timer to a value T means that it will expire
   after T seconds.

3.8.1 Timers related to tree maintenance

   Each (S,G), (*,G), and (*,*,RP) route entry has multiple timers
   associated with it: one for each interface in the outgoing interface
   list, one for the multicast routing entry itself, and one optional
   Join/Prune-Suppression-Timer. Each (S,G) and (*,G) entry also has an
   Assert-timer and a Random-Delay-Join-Timer for use with Asserts. In
   addition, DR's have a Register-Suppression-timer for each (S,G) entry
   and every router has a single Join/Prune-timer. (A router may
   optionally keep separate Join/Prune-timers for different interfaces
   or route entries if different Join/Prune periods are desired.)

     *    [Join/Prune-Timer] This timer is used for periodically
          sending aggregate Join/Prune messages.  To avoid
          synchronization among routers booting simultaneously, it is
          initially set to a random value between 1 and [Join/Prune-
          Period].  When it expires, the timer is immediately restarted



Estrin, et. al.               Experimental                     [Page 34]

RFC 2362                         PIM-SM                        June 1998


          to [Join/Prune-Period]. A Join/Prune message is then sent out
          each interface.  This timer should not be restarted by other
          events.

     *    [Join/Prune-Suppression-Timer (kept per route entry)] A
          route entry's (optional) Join/Prune-Suppression-Timer may be
          used to suppress duplicate joins from multiple downstream
          routers on the same LAN. When a Join message is received from
          a neighbor on the entry's incoming interface in which the
          included Holdtime is higher than the router's own
          [Join/Prune-Holdtime] (with ties broken by higher network
          layer address), the timer is set to [Join/Prune-Suppression-
          Timeout], with some random jitter introduced to avoid
          synchronization of triggered Join/Prune messages on
          expiration. (The random timeout value must be < 1.5 *
          [Join/Prune-Period] to prevent losing data after 2 dropped
          Join/Prunes.)  The timer is restarted every time a subsequent
          Join/Prune message (with higher Holdtime/IP address) for the
          entry is received on its incoming interface.  While the timer
          is running, Join/Prune messages for the entry are not sent.
          This timer is idle (not running) for point-to-point links.

     *    [Oif-Timer (kept per oif for each route entry)] A timer for
          each oif of a route entry is used to time out that oif.
          Because some of the outgoing interfaces in an (S,G) entry are
          copied from the (*,G) outgoing interface list, they may not
          have explicit (S,G) join messages from some of the downstream
          routers (i.e., where members are joining to the (*,G) tree
          only). Thus, when an Oif-timer is restarted in a (*,G) entry,
          the Oif-timer is restarted for that interface in each existing
          (S,G) entry whose oif list contains that interface. The same
          rule applies to (*,G) and (S,G) entries when restarting an
          Oif-timer on a (*,*,RP) entry.

          The following table shows its usage when first adding the oif
          to the entry's oiflist, when it should be restarted (unless it
          is already higher), and when it should be decreased (unless it
          is already lower).

Set to                   | When                         | Applies  to
included Holdtime        | adding oif off Join/Prune    | (S,G) (*,G)
                         |                              | (*,*,RP)

Increased (only) to      | When                         | Applies to
included  Holdtime       | received Join/Prune          | (S,G) (*,G)
                         |                              | (*,*,RP)
(*,*,RP) oif-timer value | (*,*,RP) oif-timer restarted | (S,G) (*,G)
(*,G)  oif-timer  value  | (*,G) oif-timer restarted    | (S,G)



Estrin, et. al.               Experimental                     [Page 35]

RFC 2362                         PIM-SM                        June 1998


          When the timer expires, the oif is removed from the oiflist if
          there are no directly-connected members. When deleted, the oif
          is also removed in any associated (S,G) or (*,G) entries.

     *    [Entry-Timer (kept per route entry)] A timer for each route
          entry is used to time out that entry. The following table
          summarizes its usage when first adding the oif to the entry's
          oiflist, and when it should be restarted (unless it is already
          higher).

Set to                | When                     | Applies to
[Data-Timeout]        | created off data packet  | (S,G)
included Holdtime     | created off Join/Prune   | (S,G) (*,G) (*,*,RP)

Increased (only) to   | When                     | Applies to
[Data-Timeout]        | receiving  data  packets | (S,G)no RPT-bit
oif-timer value       | any oif-timer restarted  | (S,G)RPT-bit (*,G)
                      |                          | (*,*,RP)
[Assert-Timeout]      | assert received          | (S,G)RPT-bit (*,G)
                      |                          | w/null oif

          When the timer expires, the route entry is deleted; if the
          entry is a (*,G) or (*,*,RP) entry, all associated (S,G)RPT-
          bit entries are also deleted.

     *    [Register-Suppression-Timer (kept per (S,G) route entry)]
          An (S,G) route entry's Register-Suppression-Timer is used to
          suppress registers when the RP is receiving data packets
          natively. When a Register-Stop message for the entry is
          received from the RP, the timer is set to a random value in
          the range 0.5 * [Register-Suppression-Timeout] to 1.5 *
          [Register-Suppression-Timeout]. While the timer is running,
          Registers for that entry will be suppressed.  If null
          registers are used, a null register is sent [Probe-Time]
          seconds before the timer expires.

     *    [Assert-Timer (per (S,G) or (*,G) route entry)] The
          Assert-Timer for an (S,G) or (*,G) route entry is used for
          timing out Asserts received. When an Assert is received and
          the RPF neighbor is changed to the Assert winner, the Assert-
          Timer is set to [Assert-Timeout], and is restarted to this
          value every time a subsequent Assert for the entry is received
          on its incoming interface. When the timer expires, the router
          resets its RPF neighbor according to its unicast routing
          table.






Estrin, et. al.               Experimental                     [Page 36]

RFC 2362                         PIM-SM                        June 1998


     *    [Random-Delay-Join-Timer (per (S,G) or (*,G) route entry)]
          The Random-Delay-Join-Timer for an (S,G) or (*,G) route entry
          is used to prevent synchronization among downstream routers on
          a LAN when their RPF neighbor changes. When the RPF neighbor
          changes, this timer is set to a random value between 0 and
          [Random-Delay-Join-Timeout] seconds. When the timer expires, a
          triggered Join/Prune message is sent for the entry unless its
          Join/Prune-Suppression-Timer is running.

3.8.2 Timers relating to neighbor discovery

     *    [Hello-Timer] This timer is used to periodically send Hello
          messages. To avoid synchronization among routers booting
          simultaneously, it is initially set to a random value between
          1 and [Hello-Period]. When it expires, the timer is
          immediately restarted to [Hello-Period]. A Hello message is
          then sent out each interface. This timer should not be
          restarted by other events.

     *    [Neighbor-Timer (kept per neighbor)] A Neighbor-Timer for
          each neighbor is used to time out the neighbor state. When a
          Hello message is received from a new neighbor, the timer is
          initially set to the Holdtime included in the Hello message
          (which is equal to the neighbor's value of [Hello-Holdtime]).
          Every time a subsequent Hello is received from that neighbor,
          the timer is restarted to the Holdtime in the Hello.  When the
          timer expires, the neighbor state is removed.

3.8.3 Timers relating to RP information

     *    [C-RP-Adv-Timer (C-RP's only)] Routers configured as
          candidate RP's use this timer to periodically send C-RP-Adv
          messages. To avoid synchronization among routers booting
          simultaneously, the timer is initially set to a random value
          between 1 and [C-RP-Adv-Period]. When it expires, the timer is
          immediately restarted to [C-RP-Adv-Period]. A C-RP-Adv message
          is then sent to the elected BSR. This timer should not be
          restarted by other events.

     *    [RP-Timer (BSR only, kept per RP in RP-Set)] The BSR uses a
          timer per RP in the RP-Set to monitor liveness. When a C-RP is
          added to the RP-Set, its timer is set to the Holdtime included
          in the C-RP-Adv message from that C-RP (which is equal to the
          C-RP's value of [RP-Holdtime]). Every time a subsequent C-RP-
          Adv is received from that RP, its timer is restarted to the
          Holdtime in the C-RP-Adv. When the timer expires, the RP is
          removed from the RP-Set included in Bootstrap messages.




Estrin, et. al.               Experimental                     [Page 37]

RFC 2362                         PIM-SM                        June 1998


     *    [Bootstrap-Timer] This timer is used by the BSR to
          periodically originate Bootstrap messages, and by other
          routers to time out the BSR (see 3.6.3).  This timer is
          initially set to [Bootstrap-Timeout]. A C-BSR restarts this
          timer to [Bootstrap-Timeout] upon receiving a Bootstrap
          message from a preferred router, and originates a Bootstrap
          message and restarts the timer to [Bootstrap-Period] when it
          expires.  Routers not configured as C-BSR's restart this timer
          to [Bootstrap-Timeout] upon receiving a Bootstrap message from
          the elected or a more preferred BSR, and ignore Bootstrap
          messages from non-preferred C-BSRs while it is running.

3.8.4 Default timer values

   Most of the default timeout values for state information are 3.5
   times the refresh period. For example, Hellos refresh Neighbor state
   and the default Hello-timer period is 30 seconds, so a default
   Neighbor-timer duration of 105 seconds is included in the Holdtime
   field of the Hellos. In order to improve convergence, however, the
   default timeout value for information related to RP liveness and
   Bootstrap messages is 2.5 times the refresh period.

   In this version of the spec, we suggest particular numerical timer
   settings.  A future version of the specification will specify a
   mechanism for timer values to be scaled based upon observed network
   parameters.

     *    [Join/Prune-Period] This is the interval between
          sending Join/Prune messages. Default: 60 seconds. This value
          may be set to take into account such things as the configured
          bandwidth and expected average number of multicast route
          entries for the attached network or link (e.g., the period
          would be longer for lower-speed links, or for routers in the
          center of the network that expect to have a larger number of
          entries). In addition, a router could modify this value (and
          corresponding Join/Prune-Holdtime value) if the number of
          route entries changes significantly (e.g., by an order of
          magnitude).  For example, given a default minimum Join/Prune-
          Period value, if the number of route entries with a particular
          iif increases from N to N*100, the router could increase its
          Join/Prune-Period (and Join/Prune-Holdtime), for that
          interface, by a factor of 10; and if/when the number of
          entries decreases back to N, the Join/Prune-Period (and
          Join/Prune-Holdtime) could be decreased to its previous value.
          If the Join/Prune-Period is modified, these changes should be
          made relatively infrequently and the router should continue to
          refresh at its previous Join/Prune-Period for at least
          Join/Prune-Holdtime, in order to allow the upstream router to



Estrin, et. al.               Experimental                     [Page 38]

RFC 2362                         PIM-SM                        June 1998


          adapt.

     *    [Join-Prune Holdtime] This is the Holdtime specified in
          Join/Prune messages, and is used to time out oifs. This should
          be set to 3.5 * [Join/Prune-Period].  Default: 210 seconds.

     *    [Join/Prune-Suppression-Timeout] This is the mean
          interval between receiving a Join/Prune with a higher Holdtime
          (with ties broken by higher network layer address) and
          allowing duplicate Join/Prunes to be sent again. This should
          be set to approximately 1.25 * [Join/Prune-Period].  Default:
          75 seconds.

     *    [Data-Timeout] This is the time after which (S,G) state
          for a silent source will be deleted.  Default: 210 seconds.

     *    [Register-Suppression-Timeout] This is the mean
          interval between receiving a Register-Stop and allowing
          Registers to be sent again.  A lower value means more frequent
          register bursts at RP, while a higher value means longer join
          latency for new receivers.  Default: 60 seconds.  (Note that
          if null Registers are sent [Probe-Time] seconds before the
          timeout, register bursts are prevents, and [Register-
          Suppression-Timeout] may be lowered to decrease join latency.)

     *    [Probe-Time] When null Registers are used, this is the
          time between sending a null Register and the Register-
          Suppression-Timer expiring unless it is restarted by receiving
          a Register-Stop. Thus, a null Register would be sent when the
          Register-Suppression-Timer reaches this value.  Default: 5
          seconds.

     *    [Assert-Timeout] This is the interval between the last
          time an Assert is received, and the time at which the assert
          is timed out.  Default: 180 seconds.

     *    [Random-Delay-Join-Timeout] This is the maximum
          interval between the time when the RPF neighbor changes, and
          the time at which a triggered Join/Prune message is sent.
          Default: 4.5 seconds.

     *    [Hello-Period] This is the interval between sending
          Hello messages.  Default: 30 seconds.

     *    [Hello-Holdtime] This is the Holdtime specified in
          Hello messages, after which neighbors will time out their
          neighbor entries for the router. This should be set to 3.5 *
          [Hello-Period]. Default: 105 seconds.



Estrin, et. al.               Experimental                     [Page 39]

RFC 2362                         PIM-SM                        June 1998


     *    [C-RP-Adv-Period] For C-RPs, this is the interval
          between sending C-RP-Adv messages. Default: 60 seconds.

     *    [RP-Holdtime] For C-RPs, this is the Holdtime specified
          in C-RP-Adv messages, and is used by the BSR to time out RPs.
          This should be set to 2.5 * [C-RP-Adv-Period].  Default: 150
          seconds.

     *    [Bootstrap-Period] At the elected BSR, this is the
          interval between originating Bootstrap messages, and should be
          equal to 60 seconds.

     *    [Bootstrap-Timeout] This is the time after which the
          elected BSR will be assumed unreachable when Bootstrap
          messages are not received from it. This should be set to `2 *
          [Bootstrap-Period] + 10'. Default: 130 seconds.

3.9 Summary of flags used

   Following is a summary of all the flags used in our scheme.

Bit           | Used in     | Definition

Border        | Register    | Register for external sources is coming
                              from PIM multicast  border  router
Null          | Register    | Register sent as Probe of RP, the
                              encapsulated IP data packet should not
                              be forwarded
RPT           | Route entry | Entry represents state on the RP-tree
RPT           | Join/Prune  | Join is associated with the shared tree and
                              therefore the Join/Prune message is
                              propagated along the RP-tree (source
                              encoded is an RP address)
RPT           | Assert      | The data packet was routed down the shared
                              tree; thus, the path indicated corresponds
                              to the RP tree
SPT           | (S,G) entry | Packets have arrived on the iif towards
                              S, and the iif is different from the
                              (*,G) iif
WC            |Join         | The receiver expects to receive packets
                              from all sources via this (shared tree)
                              path. Thus, the Join/Prune applies to a
                              (*,G) entry
WC            | Route entry | Wildcard entry; if there is no more
                              specific match for a particular source,
                              packets will be forwarded according to
                              this entry




Estrin, et. al.               Experimental                     [Page 40]

RFC 2362                         PIM-SM                        June 1998


3.10 Security

   All PIM control messages may use IPsec [6] to address security
   concerns.

4 Packet Formats

   This section describes the details of the packet formats for PIM
   control messages.

   All PIM control messages have protocol number 103.

   Basically, PIM messages are either unicast (e.g.  Registers and
   Register-Stop), or multicast hop-by-hop to `ALL-PIM-ROUTERS' group
   `224.0.0.13' (e.g. Join/Prune, Asserts, etc.).

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |PIM Ver| Type  | Reserved      |           Checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        PIM Ver
              PIM Version number is 2.

        Type  Types for specific PIM messages.  PIM Types are:

           0 = Hello
           1 = Register
           2 = Register-Stop
           3 = Join/Prune
           4 = Bootstrap
           5 = Assert
           6 = Graft (used in PIM-DM only)
           7 = Graft-Ack (used in PIM-DM only)
           8 = Candidate-RP-Advertisement

        Reserved
              set to zero. Ignored upon receipt.

        Checksum
             The checksum is the 16-bit one's complement of the one's
             complement sum of the entire PIM message, (excluding the
             data portion in the Register message).  For computing the
             checksum, the checksum field is zeroed.






Estrin, et. al.               Experimental                     [Page 41]

RFC 2362                         PIM-SM                        June 1998


4.1 Encoded Source and Group Address formats

1    Encoded-Unicast-address: Takes the following format:

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Addr Family   | Encoding Type |     Unicast Address           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++

     Addr Family
           The address family of the `Unicast Address' field  of
           this address.

          Here is the address family numbers assigned by IANA:

 Number    Description
 --------  ---------------------------------------------------------
      0    Reserved
      1    IP (IP version 4)
      2    IP6 (IP version 6)
      3    NSAP
      4    HDLC (8-bit multidrop)
      5    BBN 1822
      6    802 (includes all 802 media plus Ethernet "canonical format")
      7    E.163
      8    E.164 (SMDS, Frame Relay, ATM)
      9    F.69 (Telex)
     10    X.121 (X.25, Frame Relay)
     11    IPX
     12    Appletalk
     13    Decnet IV
     14    Banyan Vines
     15    E.164 with NSAP format subaddress

     Encoding Type
          The type of encoding used within a specific Address
          Family.  The value `0' is reserved for this field,
          and represents the native encoding of the Address
          Family.

     Unicast Address
          The unicast address as represented by the given
          Address Family and Encoding Type.







Estrin, et. al.               Experimental                     [Page 42]

RFC 2362                         PIM-SM                        June 1998


2    Encoded-Group-Address: Takes the following format:

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Addr Family   | Encoding Type |   Reserved    |  Mask Len     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                Group multicast Address                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Addr Family
           described above.

     Encoding Type
           described above.

     Reserved
           Transmitted as zero. Ignored upon receipt.

     Mask Len
          The Mask length is 8 bits. The value is the number of
          contiguous bits left justified used as a mask which
          describes the address. It is less than or equal to the
          address length in bits for the given Address Family
          and Encoding Type. If the message is sent for a single
          group then the Mask length must equal the address
          length in bits for the given Address Family and
          Encoding Type.  (e.g. 32 for IPv4 native encoding and
          128 for IPv6 native encoding).

     Group multicast Address
           contains the group address.

3    Encoded-Source-Address: Takes the following format:

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Addr Family   | Encoding Type | Rsrvd   |S|W|R|  Mask Len     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        Source Address                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Addr Family
           described above.

     Encoding Type
           described above.



Estrin, et. al.               Experimental                     [Page 43]

RFC 2362                         PIM-SM                        June 1998


     Reserved
           Transmitted as zero, ignored on receipt.

     S,W,R See Section 4.5 for details.

     Mask Length
          Mask length is 8 bits. The value is the number of
          contiguous bits left justified used as a mask which
          describes the address. The mask length must be less
          than or equal to the address length in bits for the
          given Address Family and Encoding Type. If the message
          is sent for a single group then the Mask length must
          equal the address length in bits for the given Address
          Family and Encoding Type. In version 2 of PIM, it is
          strongly recommended that this field be set to 32 for
          IPv4 native encoding.

     Source Address
           The source address.

4.2 Hello Message

   It is sent periodically by routers on all interfaces.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |PIM Ver| Type  | Reserved      |           Checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       OptionType              |         OptionLength          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          OptionValue                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++
    |                               .                               |
    |                               .                               |
    |                               .                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       OptionType              |         OptionLength          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          OptionValue                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++


        PIM Version, Type, Reserved, Checksum
              Described above.






Estrin, et. al.               Experimental                     [Page 44]

RFC 2362                         PIM-SM                        June 1998


        OptionType
              The type of the option given in the following  OptionValue
             field.

        OptionLength
              The length of the OptionValue field in bytes.

        OptionValue
              A variable length field, carrying the value of the option.

        The Option fields may contain the following values:

     *    OptionType = 1; OptionLength = 2; OptionValue = Holdtime;
          where Holdtime is the amount of time a receiver must keep the
          neighbor reachable, in seconds. If the Holdtime is set to
          `0xffff', the receiver of this message never times out the
          neighbor. This may be used with ISDN lines, to avoid keeping
          the link up with periodic Hello messages.  Furthermore, if the
          Holdtime is set to `0', the information is timed out
          immediately.

     *    OptionType 2 to 16: reserved

     *    The rest of the OptionTypes are defined in another
          document.

   In general, options may be ignored; but a router must not ignore the

4.3 Register Message

   A Register message is sent by the DR or a PMBR to the RP when a
   multicast packet needs to be transmitted on the RP-tree. Source
   address is set to the address of the DR, destination address is to
   the RP's 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |PIM Ver| Type  | Reserved      |           Checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |B|N|                       Reserved                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
                          Multicast data packet
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Estrin, et. al.               Experimental                     [Page 45]

RFC 2362                         PIM-SM                        June 1998


        PIM Version, Type, Reserved, Checksum
              Described above. Note that the checksum for Registers
             is done only on the PIM header, excluding the data packet
             portion.

        B     The Border bit. If the router is a DR for a source that it
             is directly connected to, it sets the B bit to 0. If the
             router is a PMBR for a source in a directly connected
             cloud, it sets the B bit to 1.

        N     The Null-Register bit. Set to 1 by a DR that is probing
             the RP before expiring its local Register-Suppression
             timer. Set to 0 otherwise.

        Multicast data packet
              The original packet sent by the source.

        For (S,G) null Registers, the Multicast data packet portion
        contains only a dummy header with S as the source address, G as
        the destination address, and a data length of zero.

4.4 Register-Stop Message

   A Register-Stop is unicast from the RP to the sender of the Register
   message.  Source address is the address to which the register was
   addressed.  Destination address is the source address of the register
   message.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |PIM Ver| Type  | Reserved      |           Checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Encoded-Group Address                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Encoded-Unicast-Source Address             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        PIM Version, Type, Reserved, Checksum
              Described above.

        Encoded-Group Address
              Format described above. Note that for Register-Stops the
             Mask Len field contains full address length * 8 (e.g. 32
             for IPv4 native encoding), if the message is sent for a
             single group.





Estrin, et. al.               Experimental                     [Page 46]

RFC 2362                         PIM-SM                        June 1998


        Encoded-Unicast-Source Address
              host address of source from multicast data packet in
             register. The format for this address is given in the
             Encoded-Unicast-Address in 4.1. A special wild card value
             (0's), can be used to indicate any source.

4.5 Join/Prune Message

   A Join/Prune message is sent by routers towards upstream sources and
   RPs.  Joins are sent to build shared trees (RP trees) or source trees
   (SPT). Prunes are sent to prune source trees when members leave
   groups as well as sources that do not use the shared tree.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |PIM Ver| Type  | Reserved      |           Checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             Encoded-Unicast-Upstream Neighbor Address         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Reserved     | Num groups    |          Holdtime             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Encoded-Multicast Group Address-1                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Number of Joined  Sources   |   Number of Pruned Sources    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               Encoded-Joined Source Address-1                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             .                                 |
    |                             .                                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               Encoded-Joined Source Address-n                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               Encoded-Pruned Source Address-1                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             .                                 |
    |                             .                                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               Encoded-Pruned Source Address-n                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           .                                   |
    |                           .                                   |
    |                           .                                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Encoded-Multicast Group Address-n              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Number of Joined  Sources   |   Number of Pruned Sources    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Estrin, et. al.               Experimental                     [Page 47]

RFC 2362                         PIM-SM                        June 1998


    |               Encoded-Joined Source Address-1                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             .                                 |
    |                             .                                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               Encoded-Joined Source Address-n                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               Encoded-Pruned Source Address-1                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             .                                 |
    |                             .                                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               Encoded-Pruned Source Address-n                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        PIM Version, Type, Reserved, Checksum
              Described above.

        Encoded-Unicast Upstream Neighbor Address
              The address of the RPF or upstream neighbor.  The format
             for this address is given in the Encoded-Unicast-Address in
             4.1. .IP "Reserved"
              Transmitted as zero, ignored on receipt.

        Holdtime
              The amount of time a receiver must keep the Join/Prune
             state alive, in seconds.  If the Holdtime is set to
             `0xffff', the receiver of this message never times out the
             oif. This may be used with ISDN lines, to avoid keeping the
             link up with periodical Join/Prune messages.  Furthermore,
             if the Holdtime is set to `0', the information is timed out
             immediately.

        Number of Groups
              The number of multicast group sets contained in the
             message.

        Encoded-Multicast group address
              For format description see Section
              4.1. A wild card group in the (*,*,RP) join is represented
             by a 224.0.0.0 in the group address field and `4' in the
             mask length field. A (*,*,RP) join also has the WC-bit and
             the RPT-bit set.

        Number of Joined Sources
              Number of join source addresses listed for a given group.





Estrin, et. al.               Experimental                     [Page 48]

RFC 2362                         PIM-SM                        June 1998


        Join Source Address-1 .. n
              This list contains the sources that the sending router
             will forward multicast datagrams for if received on the
             interface this message is sent on.

             See format section 4.1. The fields explanation for the
             Encoded-Source-Address format follows:

             Reserved
                   Described above.

             S     The Sparse bit is a 1 bit value, set to 1 for PIM-SM.
                  It is used for PIM v.1 compatibility.

             W     The WC bit is a 1 bit value. If 1, the join or  prune
                  applies to the (*,G) or (*,*,RP) entry. If 0, the join
                  or prune applies to the (S,G) entry where S is Source
                  Address.  Joins and prunes sent towards the RP must
                  have this bit set.

             R     The RPT-bit is a 1 bit value. If 1, the information
                  about (S,G) is sent towards the RP.  If 0, the
                  information must be sent toward S, where S is the
                  Source Address.

             Mask Length, Source Address
                   Described above.

             Represented in the form of
             <  WC-bit  ><  RPT-bit  ><Mask length >< Source address>:

             A source address could be a host IPv4 native encoding
             address :

              < 0 >< 0 >< 32 >< 192.1.1.17 >

             A source address could be the RP's IP address :

              < 1 >< 1 >< 32 >< 131.108.13.111 >

             A source address could be a subnet address to prune from
             the RP-tree :

              < 0 >< 1 >< 28 >< 192.1.1.16 >

             A source address could be a general aggregate :

              < 0 >< 0 >< 16 >< 192.1.0.0 >



Estrin, et. al.               Experimental                     [Page 49]

RFC 2362                         PIM-SM                        June 1998


        Number of Pruned Sources
              Number of prune source addresses listed for a group.

        Prune Source Address-1 .. n
              This list contains the sources that the sending router
             does not want to forward multicast datagrams for when
             received on the interface this message is sent on.  If the
             Join/Prune message boundary exceeds the maximum packet
             size, then the join and prune lists for the same group must
             be included in the same packet.

4.6 Bootstrap Message

   The Bootstrap messages are multicast to `ALL-PIM-ROUTERS' group, out
   all interfaces having PIM neighbors (excluding the one over which the
   message was received).  Bootstrap messages are sent with TTL value of
   1. Bootstrap messages originate at the BSR, and are forwarded by
   intermediate routers.

   Bootstrap message is divided up into `semantic fragments', if the
   original message exceeds the maximum packet size boundaries.

   The semantics of a single `fragment' is given below:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |PIM Ver| Type  | Reserved      |           Checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Fragment Tag          | Hash Mask len | BSR-priority  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Encoded-Unicast-BSR-Address                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Encoded-Group Address-1               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | RP-Count-1    | Frag RP-Cnt-1 |         Reserved              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Encoded-Unicast-RP-Address-1                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          RP1-Holdtime         | RP1-Priority  |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Encoded-Unicast-RP-Address-2                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          RP2-Holdtime         | RP2-Priority  |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               .                               |
    |                               .                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Estrin, et. al.               Experimental                     [Page 50]

RFC 2362                         PIM-SM                        June 1998


    |                 Encoded-Unicast-RP-Address-m                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          RPm-Holdtime         | RPm-Priority  |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Encoded-Group Address-2               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               .                               |
    |                               .                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Encoded-Group Address-n               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | RP-Count-n    | Frag RP-Cnt-n |          Reserved             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Encoded-Unicast-RP-Address-1                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          RP1-Holdtime         | RP1-Priority  |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Encoded-Unicast-RP-Address-2                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          RP2-Holdtime         | RP2-Priority  |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               .                               |
    |                               .                               |
    |                               .                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Encoded-Unicast-RP-Address-m                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          RPm-Holdtime         | RPm-Priority  |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        PIM Version, Type, Reserved, Checksum
              Described above.

        Fragment Tag
              A randomly generated number, acts to distinguish the
             fragments belonging to different Bootstrap messages;
             fragments belonging to same Bootstrap message carry the
             same `Fragment Tag'.

        Hash Mask len
              The length (in bits) of the mask to use in the hash
             function. For IPv4 we recommend a value of 30. For IPv6 we
             recommend a value of 126.

        BSR-priority
              Contains the BSR priority value of the included BSR.  This
             field is considered as a high order byte when comparing BSR
             addresses.



Estrin, et. al.               Experimental                     [Page 51]

RFC 2362                         PIM-SM                        June 1998


        Encoded-Unicast-BSR-Address
              The address of the bootstrap router for the domain.  The
             format for this address is given in the Encoded-Unicast-
             Address in 4.1. .IP "Encoded-Group Address-1..n"
              The group prefix (address and mask) with which the
             Candidate RPs are associated. Format previously described.

        RP-Count-1..n
              The number of Candidate RP addresses included in the whole
             Bootstrap message for the corresponding group prefix. A
             router does not replace its old RP-Set for a given group
             prefix until/unless it receives `RP-Count' addresses for
             that prefix; the addresses could be carried over several
             fragments.  If only part of the RP-Set for a given group
             prefix was received, the router discards it, without
             updating that specific group prefix's RP-Set.

        Frag RP-Cnt-1..m
              The number of Candidate RP addresses included in this
             fragment of the Bootstrap message, for the corresponding
             group prefix. The `Frag RP-Cnt' field facilitates parsing
             of the RP-Set for a given group prefix, when carried over
             more than one fragment.

        Encoded-Unicast-RP-address-1..m
              The address of the Candidate RPs, for the corresponding
             group prefix.  The format for this address is given in the
             Encoded-Unicast-Address in 4.1. .IP "RP1..m-Holdtime"
              The Holdtime for the corresponding RP.  This field is
             copied from the `Holdtime' field of the associated RP
             stored at the BSR.

        RP1..m-Priority
              The `Priority' of the corresponding RP and Encoded-Group
             Address.  This field is copied from the `Priority' field
             stored at the BSR when receiving a Candidate-RP-
             Advertisement.  The highest priority is `0' (i.e. the lower
             the value of the `Priority' field, the higher).  Note that
             the priority is per RP per Encoded-Group Address.

4.7 Assert Message

   The Assert message is sent when a multicast data packet is received
   on an outgoing interface corresponding to the (S,G) or (*,G)
   associated with the source.






Estrin, et. al.               Experimental                     [Page 52]

RFC 2362                         PIM-SM                        June 1998


     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |PIM Ver| Type  | Reserved      |           Checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Encoded-Group Address                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Encoded-Unicast-Source Address                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |R|                        Metric Preference                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Metric                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        PIM Version, Type, Reserved, Checksum
              Described above.

        Encoded-Group Address
              The group address to which the data packet was addressed,
             and which triggered the Assert.  Format previously
             described.

        Encoded-Unicast-Source Address
              Source address from multicast datagram that triggered the
             Assert packet to be sent. The format for this address is
             given in the Encoded-Unicast-Address in 4.1. .IP "R"
              RPT-bit is a 1 bit value. If the multicast datagram that
             triggered the Assert packet is routed down the RP tree,
             then the RPT-bit is 1; if the multicast datagram is routed
             down the SPT, it is 0.

        Metric Preference
              Preference value assigned to the unicast routing protocol
             that provided the route to Host address.

        Metric The unicast routing table metric. The metric is in units
             applicable to the unicast routing protocol used.

4.8 Graft Message

   Used in dense-mode. Refer to PIM dense mode specification.

4.9 Graft-Ack Message

   Used in dense-mode. Refer to PIM dense mode specification.






Estrin, et. al.               Experimental                     [Page 53]

RFC 2362                         PIM-SM                        June 1998


4.10 Candidate-RP-Advertisement

   Candidate-RP-Advertisements are periodically unicast from the C-RPs
   to the BSR.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |PIM Ver| Type  | Reserved      |           Checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Prefix-Cnt    |   Priority    |             Holdtime          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Encoded-Unicast-RP-Address                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Encoded-Group Address-1               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               .                               |
    |                               .                               |
    |                               .                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Encoded-Group Address-n               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        PIM Version, Type, Reserved, Checksum
              Described above.

        Prefix-Cnt
              The number of encoded group addresses included in the
             message; indicating the group prefixes for which the C-RP
             is advertising. A Prefix-Cnt of `0' implies a prefix of
             224.0.0.0 with mask length of 4; i.e. all multicast groups.
             If the C-RP is not configured with Group-prefix
             information, the C-RP puts a default value of `0' in this
             field.

        Priority
              The `Priority' of the included RP, for the corresponding
             Encoded-Group Address (if any).  highest priority is `0'
             (i.e. the lower the value of the `Priority' field, the
             higher the priority). This field is stored at the BSR upon
             receipt along with the RP address and corresponding
             Encoded-Group Address.

        Holdtime
              The amount of time the advertisement is valid. This field
             allows advertisements to be aged out.





Estrin, et. al.               Experimental                     [Page 54]

RFC 2362                         PIM-SM                        June 1998


        Encoded-Unicast-RP-Address
              The address of the interface to advertise as a Candidate
             RP.  The format for this address is given in the Encoded-
             Unicast-Address in 4.1. .IP "Encoded-Group Address-1..n"
              The group prefixes for which the C-RP is advertising.
             Format previously described.

5 Acknowledgments

   Tony Ballardie, Scott Brim, Jon Crowcroft, Bill Fenner, Paul Francis,
   Joel Halpern, Horst Hodel, Polly Huang, Stephen Ostrowski, Lixia
   Zhang and Girish Chandranmenon provided detailed comments on previous
   drafts. The authors of CBT [8] and membership of the IDMR WG provided
   many of the motivating ideas for this work and useful feedback on
   design details.

   This work was supported by the National Science Foundation, ARPA,
   cisco Systems and Sun Microsystems.

































Estrin, et. al.               Experimental                     [Page 55]

RFC 2362                         PIM-SM                        June 1998


6 Appendices

6.1 Appendix I: Major Changes and Updates to the Spec

   This appendix populates the major changes in the specification
   document as compared to `draft-ietf-idmr-pim-spec-01.ps,txt'.

   bsubsection*Major Changes

   List of changes since March '96 IETF:

     1. (*,*,RP) Joins state and data forwarding check; replaces (*,G-
     Prefix) Joins state for interoperability. (*,G) negative cache
     introduced for the (*,*,RP) state supporting mechanisms.

     2. Semantic fragmentation for the Bootstrap message.

     3. Refinement of Assert details.

     4. Addition and refinement of Join/Prune suppression and Register
     suppression (introduction of null Registers).

     5. Editorial changes and clarifications to the timers section.

     6. Addition of Appendix II (BSR Election and RP-Set Distribution),
     and Appendix III (Glossary of Terms).

     7. Addition of table of contents.

   List of changes incurred since version 1 of the spec.:

     1. Proposal and refinement of bootstrap router (BSR) election
     mechanisms

     2. Introduction of hash functions for Group to RP mapping

     3. New RP-liveness indication mechanisms based upon the the
     Bootstrap Router (BSR) and the Bootstrap messages.

     4. Removal of reachability messages, RP reports and multiple RPs
     per group.

   *Packet Format Changes

     Packet Format incurred updates to accommodate different address
     lengths, and address aggregation.





Estrin, et. al.               Experimental                     [Page 56]

RFC 2362                         PIM-SM                        June 1998


     1 The `Addr Family' and `Encoding Type' fields were added to the
     packet formats.

     2 The Encoded source and group address formats were introduced,
     with the use of a `Mask length' field to allow aggregation, section
     4.1.

     3 Packet formats are no longer IGMP messages; rather PIM messages.

   PIM message types and formats were also modified:

   [Note: most changes were made to the May  95  version,  unless
   otherwise specified].

     1    Obsolete messages:

         Register-Ack [Feb. 96]

         Poll and Poll Response [Feb. 96]

         RP-Reachability [Feb. 96]

         RPlist-Mapping [Feb. 96]


     2     New messages:

         Candidate-RP-Advertisement [change made in  October  95]
         RP-Set [Feb. 96]

     3       Modified messages:

         Join/Prune [Feb. 96]
         Register [Feb. 96]
         Register-Stop [Feb.  96]
         Hello (addition of OptionTypes) [Aug 96]

     4        Renamed messages:

          Query messages are renamed as Hello messages [Aug. 96]
          RP-Set  messages are renamed as Bootstrap messages [Aug. 96]










Estrin, et. al.               Experimental                     [Page 57]

RFC 2362                         PIM-SM                        June 1998


6.2 Appendix II: BSR Election and RP-Set Distribution

   For simplicity, the bootstrap message is used in both the BSR
   election and the RP-Set distribution mechanisms.  These mechanisms
   are described by the following state machine, illustrated in figure
   4.  The protocol transitions for a Candidate-BSR are given  in state
   diagram (a).  For routers not configured as Candidate-BSRs, the
   protocol transitions are given in state diagram (b).

     [Figures are present only in the postscript version] Fig. 4 State
           Diagram for the BSR election and RP-Set distribution

   Each PIM router keeps a bootstrap-timer, initialized to [Bootstrap-
   Timeout], in addition to a local BSR field `LclBSR' (initialized to a
   local address if Candidate-BSR, or to 0 otherwise), and a local RP-
   Set `LclRP-Set' (initially empty). The main stimuli to the state
   machine are timer events and arrival of bootstrap messages:

        bsubsection*Initial States and Timer Events

        1

        2    If the router is a Candidate-BSR:

             1

             2 The router operates initially in the `CandBSR' state,
               where it does not originate any bootstrap messages.

             3 If the bootstrap-timer expires, and the current state
               is `CandBSR', the router originates a bootstrap
               message carrying the local RP-Set and its own BSR
               priority and address, restarts the bootstrap-timer at
               [Bootstrap-Period] seconds, and transits into the
               `ElectedBSR' state. Note that the actual sending of
               the bootstrap message may be delayed by a random value
               to reduce transient control overhead. To obtain best
               results, the random value is set such that the
               preferred BSR is the first to originate a bootstrap
               message. We propose the following as an efficient
               implementation of the random value delay (in seconds):

         Delay = 5 + 2 * log_2(1 + bestPriority - myPriority) + AddrDelay

               where myPriority is the Candidate-BSR's
               configured priority, and bestPriority equals:

                 bestPriority = Max(storedPriority, myPriority) ]



Estrin, et. al.               Experimental                     [Page 58]

RFC 2362                         PIM-SM                        June 1998



               and AddrDelay is given by the following:


               1 if ( bestPriority equals myPriority) then
               [AddrDelay = log_2(bestAddr - myAddr) / 16, ]

               2 else [AddrDelay = 2 - (myAddr / 2^31) ]

               where myAddr is the Candidate-BSR's address, and
               bestAddr is the stored BSR's address.


             4 If the bootstrap-timer expires, and the current state
               is `ElectedBSR', the router originates a bootstrap
               message, and restarts the RP-Set timer at [Bootstrap-
               Period]. No state transition is incurred.

               This way, the elected BSR originates periodic
               bootstrap messages every [Bootstrap-Period].

        3 If a router is not a Candidate-BSR:


             1

             2 The router operates initially in the `AxptAny' state.
               In such state, a router accepts the first bootstrap
               message from the The Reverse Path Forwarding (RPF)
               neighbor toward the included BSR. The RPF neighbor in
               this case is the next hop router en route to the
               included BSR.

             3 If the bootstrap-timer expires, and the current state
               is `AxptPref'-- where the router accepts only
               preferred bootstrap messages (those that carry BSR-
               priority and address higher than, or equal to,
               `LclBSR') from the RPF neighbor toward the included
               BSR-- the router transits into the `AxptAny' state.

               In this case, if an elected BSR becomes unreachable,
               the routers start accepting bootstrap messages from
               another Candidate-BSR after the bootstrap-timer
               expires.  All PIM routers within a domain converge on
               the preferred reachable Candidate-BSR.






Estrin, et. al.               Experimental                     [Page 59]

RFC 2362                         PIM-SM                        June 1998


        Receiving Bootstrap Message:

        To avoid loops, an RPF check is performed on the included BSR
        address.  Upon receiving a bootstrap message from the RPF
        neighbor toward the included BSR, the following actions are
        taken:

        1 If the router is not a Candidate-BSR:

             1 If the current state is `AxptAny', the router accepts
               the bootstrap message, and transits into the
               `AxptPref' state.

             2 If the current state is `AxptPref', and the bootstrap
               message is preferred, the message is accepted. No
               state transition is incurred.

        2 If the router is a Candidate-BSR, and the bootstrap message
          is preferred, the message is accepted. Further, if this
          happens when the current state is `Elected BSR', the router
          transits into the `CandBSR' state.

        When a bootstrap message is accepted, the router restarts the
        bootstrap-timer at [Bootstrap-Timeout], stores the received BSR
        priority and address in `LclBSR', and the received RP-Set in
        `LclRP-Set', and forwards the bootstrap message out all
        interfaces except the receiving interface.

        If a bootstrap message is rejected, no state transitions are
        triggered.





















Estrin, et. al.               Experimental                     [Page 60]

RFC 2362                         PIM-SM                        June 1998


6.3 Appendix III: Glossary of Terms

   Following is an alphabetized list of terms and definitions used
   throughout this specification.

     *    { Bootstrap router (BSR)}. A BSR is a dynamically elected
          router within a PIM domain. It is responsible for constructing
          the RP-Set and originating Bootstrap messages.

     *    { Candidate-BSR (C-BSR)}. A C-BSR is a router configured to
          participate in the BSR election and act as BSRs if elected.

     *    { Candidate RP (C-RP)}. A C-RP is a router configured to
          send periodic Candidate-RP-Advertisement messages to the BSR,
          and act as an RP when it receives Join/Prune or Register
          messages for the advertised group prefix.

     *    { Designated Router (DR)}. The DR sets up multicast route
          entries and sends corresponding Join/Prune and Register
          messages on behalf of directly-connected receivers and
          sources, respectively.  The DR may or may not be the same
          router as the IGMP Querier. The DR may or may not be the
          long-term, last-hop router for the group; a router on the LAN
          that has a lower metric route to the data source, or to the
          group's RP, may take over the role of sending Join/Prune
          messages.

     *    { Incoming interface (iif)}. The iif of a multicast route
          entry indicates the interface from which multicast data
          packets are accepted for forwarding. The iif is initialized
          when the entry is created.

     *     Join list. The Join list is one of two lists of addresses
          that is included in a Join/Prune message; each address refers
          to a source or RP. It indicates those sources or RPs to which
          downstream receiver(s) wish to join.

     *    { Last-hop router}. The last-hop router is the last router
          to receive multicast data packets before they are delivered to
          directly-connected member hosts. In general the last-hop
          router is the DR for the LAN.  However, under various
          conditions described in this document a parallel router
          connected to the same LAN may take over as the last-hop router
          in place of the DR.

     *    { Outgoing interface (oif) list}.  Each multicast route
          entry has an oif list containing the outgoing interfaces to
          which multicast packets should be forwarded.



Estrin, et. al.               Experimental                     [Page 61]

RFC 2362                         PIM-SM                        June 1998


     *     Prune List. The Prune list is the second list of addresses
          that is included in a Join/Prune message. It indicates those
          sources or RPs from which downstream receiver(s) wish to
          prune.

     *    { PIM Multicast Border Router (PMBR)}. A PMBR connects a
          PIM domain to other multicast routing domain(s).

     *    { Rendezvous Point (RP)}.  Each multicast group has a
          shared-tree via which receivers hear of new sources and new
          receivers hear of all sources. The RP is the root of this
          per-group shared tree, called the RP-Tree.

     *    { RP-Set}. The RP-Set is a set of RP addresses constructed
          by the BSR based on Candidate-RP advertisements received.  The
          RP-Set information is distributed to all PIM routers in the
          BSR's PIM domain.

     *    { Reverse Path Forwarding (RPF)}. RPF is used to select the
          appropriate incoming interface for a multicast route entry .
          The RPF neighbor for an address X is the the next-hop router
          used to forward packets toward X. The RPF interface is the
          interface to that RPF neighbor. In the common case this is the
          next hop used by the unicast routing protocol for sending
          unicast packets toward X. For example, in cases where unicast
          and multicast routes are not congruent, it can be different.

     *    { Route entry.} A multicast route entry is state maintained
          in a router along the distribution tree and is created, and
          updated based on incoming control messages. The route entry
          may be different from the forwarding entry; the latter is used
          to forward data packets in real time.  Typically a forwarding
          entry is not created until data packets arrive, the forwarding
          entry's iif and oif list are copied from the route entry, and
          the forwarding entry may be flushed and recreated at will.

     *    { Shortest path tree (SPT)}.  The SPT is the multicast
          distribution tree created by the merger of all of the shortest
          paths that connect receivers to the source (as determined by
          unicast routing).

     *    { Sparse Mode (SM)}. SM is one mode of operation of a
          multicast protocol.  PIM SM uses explicit Join/Prune messages
          and Rendezvous points in place of Dense Mode PIM's and DVMRP's
          broadcast and prune mechanism.






Estrin, et. al.               Experimental                     [Page 62]

RFC 2362                         PIM-SM                        June 1998


     *    { Wildcard (WC) multicast route entry}. Wildcard multicast
          route entries are those entries that may be used to forward
          packets for any source sending to the specified group.
          Wildcard bots in the join list of a Join/Prune message
          represent either a (*,G) or (*,*,RP) join; in the prune list
          they represent a (*,G) prune.

     *    { (S,G) route entry}.  (S,G) is a source-specific route
          entry.  It may be created in response to data packets,
          Join/Prune messages, or Asserts. The (S,G) state in routers
          creates a source-rooted, shortest path (or reverse shortest
          path) distribution tree. (S,G)RPT bit entries are source-
          specific entries on the shared RP-Tree; these entries are used
          to prune particular sources off of the shared tree.

     *    { (*,G) route entry}. Group members join the shared RP-Tree
          for a particular group. This tree is represented by (*,G)
          multicast route entries along the shortest path branches
          between the RP and the group members.

     *    { (*,*,RP) route entry}. (*,*,RP) refers to any source and
          any multicast group that maps to the RP included in the entry.
          The routers along the shortest path branches between a
          domain's RP(s) and its PMBRs keep (*,*,RP) state and use it to
          determine how to deliver packets toward the PMBRs if data
          packets arrive for which there is not a longer match.  The
          wildcard group in the (*,*,RP) route entry is represented by a
          group address of 224.0.0.0 and a mask length of 4 bits.

References

   1. Deering, S., Estrin, D., Farinacci, D., Jacobson, V., Liu, C.,
   Wei, L., Sharma, P., and A. Helmy, "Protocol Independent Multicast
   (pim): Motivation and Architecture", Work in Progress.

   2. S. Deering, D. Estrin, D. Farinacci, V. Jacobson, C. Liu, and L.
   Wei.  The pim architecture for wide-area multicast routing.  ACM
   Transactions on Networks, April 1996.

   3. Estrin, D., Farinacci, D., Jacobson, V., Liu, C., Wei, L., Sharma,
   P., and A. Helmy, "Protocol Independent Multicast-dense Mode (pim-
   dm): Protocol Specification", Work in Progress.

   4. Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
   1112, August 1989.

   5. Fenner, W., "Internet Group Management Protocol, Version 2", RFC
   2236, November 1997.



Estrin, et. al.               Experimental                     [Page 63]

RFC 2362                         PIM-SM                        June 1998


   6. Atkinson, R., "Security Architecture for the Internet Protocol",
   RFC 1825, August 1995.

   7. Mark R. Nelson.  File verification using CRC.  Dr.  Dobb's
   Journal, May 1992.

   8. A.J. Ballardie, P.F. Francis, and J.Crowcroft. Core based trees.
   In Proceedings of the ACM SIGCOMM, San Francisco, 1993.

Authors' Addresses

   NOTE: The author list has been reordered to reflect the involvement
   in detailed editorial work on this specification document.  The first
   four authors are the primary editors and are listed alphabetically.
   The rest of the authors, also listed alphabetically, participated in
   all aspects of the architectural and detailed design but managed to
   get away without hacking the latex!

   Deborah Estrin
   Computer Science Dept/ISI
   University of Southern Calif.
   Los Angeles, CA 90089

   EMail: estrin@usc.edu


   Dino Farinacci
   Cisco Systems Inc.
   170 West Tasman Drive,
   San Jose, CA 95134

   EMail: dino@cisco.com


   Ahmed Helmy
   Computer Science Dept.
   University of Southern Calif.
   Los Angeles, CA 90089

   EMail: ahelmy@catarina.usc.edu


   David Thaler
   EECS Department
   University of Michigan
   Ann Arbor, MI 48109

   EMail: thalerd@eecs.umich.edu



Estrin, et. al.               Experimental                     [Page 64]

RFC 2362                         PIM-SM                        June 1998


   Stephen Deering
   Xerox PARC
   3333 Coyote Hill Road
   Palo Alto, CA 94304

   EMail: deering@parc.xerox.com

   Mark Handley
   Department of Computer Science
   University College London
   Gower Street
   London, WC1E 6BT
   UK

   EMail: m.handley@cs.ucl.ac.uk


   Van Jacobson
   Lawrence Berkeley Laboratory
   1 Cyclotron Road
   Berkeley, CA 94720

   EMail: van@ee.lbl.gov


   Ching-gung  Liu
   Computer Science Dept.
   University of Southern Calif.
   Los Angeles, CA 90089

   EMail: charley@catarina.usc.edu


   Puneet Sharma
   Computer Science Dept.
   University of Southern Calif.
   Los Angeles, CA 90089

   EMail: puneet@catarina.usc.edu


   Liming Wei
   Cisco Systems Inc.
   170 West Tasman Drive,
   San Jose, CA 95134

   EMail: lwei@cisco.com




Estrin, et. al.               Experimental                     [Page 65]

RFC 2362                         PIM-SM                        June 1998


Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.
























Estrin, et. al.               Experimental                     [Page 66]