File: rfc2205.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 (6274 lines) | stat: -rw-r--r-- 223,976 bytes parent folder | download | duplicates (8)
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
3700
3701
3702
3703
3704
3705
3706
3707
3708
3709
3710
3711
3712
3713
3714
3715
3716
3717
3718
3719
3720
3721
3722
3723
3724
3725
3726
3727
3728
3729
3730
3731
3732
3733
3734
3735
3736
3737
3738
3739
3740
3741
3742
3743
3744
3745
3746
3747
3748
3749
3750
3751
3752
3753
3754
3755
3756
3757
3758
3759
3760
3761
3762
3763
3764
3765
3766
3767
3768
3769
3770
3771
3772
3773
3774
3775
3776
3777
3778
3779
3780
3781
3782
3783
3784
3785
3786
3787
3788
3789
3790
3791
3792
3793
3794
3795
3796
3797
3798
3799
3800
3801
3802
3803
3804
3805
3806
3807
3808
3809
3810
3811
3812
3813
3814
3815
3816
3817
3818
3819
3820
3821
3822
3823
3824
3825
3826
3827
3828
3829
3830
3831
3832
3833
3834
3835
3836
3837
3838
3839
3840
3841
3842
3843
3844
3845
3846
3847
3848
3849
3850
3851
3852
3853
3854
3855
3856
3857
3858
3859
3860
3861
3862
3863
3864
3865
3866
3867
3868
3869
3870
3871
3872
3873
3874
3875
3876
3877
3878
3879
3880
3881
3882
3883
3884
3885
3886
3887
3888
3889
3890
3891
3892
3893
3894
3895
3896
3897
3898
3899
3900
3901
3902
3903
3904
3905
3906
3907
3908
3909
3910
3911
3912
3913
3914
3915
3916
3917
3918
3919
3920
3921
3922
3923
3924
3925
3926
3927
3928
3929
3930
3931
3932
3933
3934
3935
3936
3937
3938
3939
3940
3941
3942
3943
3944
3945
3946
3947
3948
3949
3950
3951
3952
3953
3954
3955
3956
3957
3958
3959
3960
3961
3962
3963
3964
3965
3966
3967
3968
3969
3970
3971
3972
3973
3974
3975
3976
3977
3978
3979
3980
3981
3982
3983
3984
3985
3986
3987
3988
3989
3990
3991
3992
3993
3994
3995
3996
3997
3998
3999
4000
4001
4002
4003
4004
4005
4006
4007
4008
4009
4010
4011
4012
4013
4014
4015
4016
4017
4018
4019
4020
4021
4022
4023
4024
4025
4026
4027
4028
4029
4030
4031
4032
4033
4034
4035
4036
4037
4038
4039
4040
4041
4042
4043
4044
4045
4046
4047
4048
4049
4050
4051
4052
4053
4054
4055
4056
4057
4058
4059
4060
4061
4062
4063
4064
4065
4066
4067
4068
4069
4070
4071
4072
4073
4074
4075
4076
4077
4078
4079
4080
4081
4082
4083
4084
4085
4086
4087
4088
4089
4090
4091
4092
4093
4094
4095
4096
4097
4098
4099
4100
4101
4102
4103
4104
4105
4106
4107
4108
4109
4110
4111
4112
4113
4114
4115
4116
4117
4118
4119
4120
4121
4122
4123
4124
4125
4126
4127
4128
4129
4130
4131
4132
4133
4134
4135
4136
4137
4138
4139
4140
4141
4142
4143
4144
4145
4146
4147
4148
4149
4150
4151
4152
4153
4154
4155
4156
4157
4158
4159
4160
4161
4162
4163
4164
4165
4166
4167
4168
4169
4170
4171
4172
4173
4174
4175
4176
4177
4178
4179
4180
4181
4182
4183
4184
4185
4186
4187
4188
4189
4190
4191
4192
4193
4194
4195
4196
4197
4198
4199
4200
4201
4202
4203
4204
4205
4206
4207
4208
4209
4210
4211
4212
4213
4214
4215
4216
4217
4218
4219
4220
4221
4222
4223
4224
4225
4226
4227
4228
4229
4230
4231
4232
4233
4234
4235
4236
4237
4238
4239
4240
4241
4242
4243
4244
4245
4246
4247
4248
4249
4250
4251
4252
4253
4254
4255
4256
4257
4258
4259
4260
4261
4262
4263
4264
4265
4266
4267
4268
4269
4270
4271
4272
4273
4274
4275
4276
4277
4278
4279
4280
4281
4282
4283
4284
4285
4286
4287
4288
4289
4290
4291
4292
4293
4294
4295
4296
4297
4298
4299
4300
4301
4302
4303
4304
4305
4306
4307
4308
4309
4310
4311
4312
4313
4314
4315
4316
4317
4318
4319
4320
4321
4322
4323
4324
4325
4326
4327
4328
4329
4330
4331
4332
4333
4334
4335
4336
4337
4338
4339
4340
4341
4342
4343
4344
4345
4346
4347
4348
4349
4350
4351
4352
4353
4354
4355
4356
4357
4358
4359
4360
4361
4362
4363
4364
4365
4366
4367
4368
4369
4370
4371
4372
4373
4374
4375
4376
4377
4378
4379
4380
4381
4382
4383
4384
4385
4386
4387
4388
4389
4390
4391
4392
4393
4394
4395
4396
4397
4398
4399
4400
4401
4402
4403
4404
4405
4406
4407
4408
4409
4410
4411
4412
4413
4414
4415
4416
4417
4418
4419
4420
4421
4422
4423
4424
4425
4426
4427
4428
4429
4430
4431
4432
4433
4434
4435
4436
4437
4438
4439
4440
4441
4442
4443
4444
4445
4446
4447
4448
4449
4450
4451
4452
4453
4454
4455
4456
4457
4458
4459
4460
4461
4462
4463
4464
4465
4466
4467
4468
4469
4470
4471
4472
4473
4474
4475
4476
4477
4478
4479
4480
4481
4482
4483
4484
4485
4486
4487
4488
4489
4490
4491
4492
4493
4494
4495
4496
4497
4498
4499
4500
4501
4502
4503
4504
4505
4506
4507
4508
4509
4510
4511
4512
4513
4514
4515
4516
4517
4518
4519
4520
4521
4522
4523
4524
4525
4526
4527
4528
4529
4530
4531
4532
4533
4534
4535
4536
4537
4538
4539
4540
4541
4542
4543
4544
4545
4546
4547
4548
4549
4550
4551
4552
4553
4554
4555
4556
4557
4558
4559
4560
4561
4562
4563
4564
4565
4566
4567
4568
4569
4570
4571
4572
4573
4574
4575
4576
4577
4578
4579
4580
4581
4582
4583
4584
4585
4586
4587
4588
4589
4590
4591
4592
4593
4594
4595
4596
4597
4598
4599
4600
4601
4602
4603
4604
4605
4606
4607
4608
4609
4610
4611
4612
4613
4614
4615
4616
4617
4618
4619
4620
4621
4622
4623
4624
4625
4626
4627
4628
4629
4630
4631
4632
4633
4634
4635
4636
4637
4638
4639
4640
4641
4642
4643
4644
4645
4646
4647
4648
4649
4650
4651
4652
4653
4654
4655
4656
4657
4658
4659
4660
4661
4662
4663
4664
4665
4666
4667
4668
4669
4670
4671
4672
4673
4674
4675
4676
4677
4678
4679
4680
4681
4682
4683
4684
4685
4686
4687
4688
4689
4690
4691
4692
4693
4694
4695
4696
4697
4698
4699
4700
4701
4702
4703
4704
4705
4706
4707
4708
4709
4710
4711
4712
4713
4714
4715
4716
4717
4718
4719
4720
4721
4722
4723
4724
4725
4726
4727
4728
4729
4730
4731
4732
4733
4734
4735
4736
4737
4738
4739
4740
4741
4742
4743
4744
4745
4746
4747
4748
4749
4750
4751
4752
4753
4754
4755
4756
4757
4758
4759
4760
4761
4762
4763
4764
4765
4766
4767
4768
4769
4770
4771
4772
4773
4774
4775
4776
4777
4778
4779
4780
4781
4782
4783
4784
4785
4786
4787
4788
4789
4790
4791
4792
4793
4794
4795
4796
4797
4798
4799
4800
4801
4802
4803
4804
4805
4806
4807
4808
4809
4810
4811
4812
4813
4814
4815
4816
4817
4818
4819
4820
4821
4822
4823
4824
4825
4826
4827
4828
4829
4830
4831
4832
4833
4834
4835
4836
4837
4838
4839
4840
4841
4842
4843
4844
4845
4846
4847
4848
4849
4850
4851
4852
4853
4854
4855
4856
4857
4858
4859
4860
4861
4862
4863
4864
4865
4866
4867
4868
4869
4870
4871
4872
4873
4874
4875
4876
4877
4878
4879
4880
4881
4882
4883
4884
4885
4886
4887
4888
4889
4890
4891
4892
4893
4894
4895
4896
4897
4898
4899
4900
4901
4902
4903
4904
4905
4906
4907
4908
4909
4910
4911
4912
4913
4914
4915
4916
4917
4918
4919
4920
4921
4922
4923
4924
4925
4926
4927
4928
4929
4930
4931
4932
4933
4934
4935
4936
4937
4938
4939
4940
4941
4942
4943
4944
4945
4946
4947
4948
4949
4950
4951
4952
4953
4954
4955
4956
4957
4958
4959
4960
4961
4962
4963
4964
4965
4966
4967
4968
4969
4970
4971
4972
4973
4974
4975
4976
4977
4978
4979
4980
4981
4982
4983
4984
4985
4986
4987
4988
4989
4990
4991
4992
4993
4994
4995
4996
4997
4998
4999
5000
5001
5002
5003
5004
5005
5006
5007
5008
5009
5010
5011
5012
5013
5014
5015
5016
5017
5018
5019
5020
5021
5022
5023
5024
5025
5026
5027
5028
5029
5030
5031
5032
5033
5034
5035
5036
5037
5038
5039
5040
5041
5042
5043
5044
5045
5046
5047
5048
5049
5050
5051
5052
5053
5054
5055
5056
5057
5058
5059
5060
5061
5062
5063
5064
5065
5066
5067
5068
5069
5070
5071
5072
5073
5074
5075
5076
5077
5078
5079
5080
5081
5082
5083
5084
5085
5086
5087
5088
5089
5090
5091
5092
5093
5094
5095
5096
5097
5098
5099
5100
5101
5102
5103
5104
5105
5106
5107
5108
5109
5110
5111
5112
5113
5114
5115
5116
5117
5118
5119
5120
5121
5122
5123
5124
5125
5126
5127
5128
5129
5130
5131
5132
5133
5134
5135
5136
5137
5138
5139
5140
5141
5142
5143
5144
5145
5146
5147
5148
5149
5150
5151
5152
5153
5154
5155
5156
5157
5158
5159
5160
5161
5162
5163
5164
5165
5166
5167
5168
5169
5170
5171
5172
5173
5174
5175
5176
5177
5178
5179
5180
5181
5182
5183
5184
5185
5186
5187
5188
5189
5190
5191
5192
5193
5194
5195
5196
5197
5198
5199
5200
5201
5202
5203
5204
5205
5206
5207
5208
5209
5210
5211
5212
5213
5214
5215
5216
5217
5218
5219
5220
5221
5222
5223
5224
5225
5226
5227
5228
5229
5230
5231
5232
5233
5234
5235
5236
5237
5238
5239
5240
5241
5242
5243
5244
5245
5246
5247
5248
5249
5250
5251
5252
5253
5254
5255
5256
5257
5258
5259
5260
5261
5262
5263
5264
5265
5266
5267
5268
5269
5270
5271
5272
5273
5274
5275
5276
5277
5278
5279
5280
5281
5282
5283
5284
5285
5286
5287
5288
5289
5290
5291
5292
5293
5294
5295
5296
5297
5298
5299
5300
5301
5302
5303
5304
5305
5306
5307
5308
5309
5310
5311
5312
5313
5314
5315
5316
5317
5318
5319
5320
5321
5322
5323
5324
5325
5326
5327
5328
5329
5330
5331
5332
5333
5334
5335
5336
5337
5338
5339
5340
5341
5342
5343
5344
5345
5346
5347
5348
5349
5350
5351
5352
5353
5354
5355
5356
5357
5358
5359
5360
5361
5362
5363
5364
5365
5366
5367
5368
5369
5370
5371
5372
5373
5374
5375
5376
5377
5378
5379
5380
5381
5382
5383
5384
5385
5386
5387
5388
5389
5390
5391
5392
5393
5394
5395
5396
5397
5398
5399
5400
5401
5402
5403
5404
5405
5406
5407
5408
5409
5410
5411
5412
5413
5414
5415
5416
5417
5418
5419
5420
5421
5422
5423
5424
5425
5426
5427
5428
5429
5430
5431
5432
5433
5434
5435
5436
5437
5438
5439
5440
5441
5442
5443
5444
5445
5446
5447
5448
5449
5450
5451
5452
5453
5454
5455
5456
5457
5458
5459
5460
5461
5462
5463
5464
5465
5466
5467
5468
5469
5470
5471
5472
5473
5474
5475
5476
5477
5478
5479
5480
5481
5482
5483
5484
5485
5486
5487
5488
5489
5490
5491
5492
5493
5494
5495
5496
5497
5498
5499
5500
5501
5502
5503
5504
5505
5506
5507
5508
5509
5510
5511
5512
5513
5514
5515
5516
5517
5518
5519
5520
5521
5522
5523
5524
5525
5526
5527
5528
5529
5530
5531
5532
5533
5534
5535
5536
5537
5538
5539
5540
5541
5542
5543
5544
5545
5546
5547
5548
5549
5550
5551
5552
5553
5554
5555
5556
5557
5558
5559
5560
5561
5562
5563
5564
5565
5566
5567
5568
5569
5570
5571
5572
5573
5574
5575
5576
5577
5578
5579
5580
5581
5582
5583
5584
5585
5586
5587
5588
5589
5590
5591
5592
5593
5594
5595
5596
5597
5598
5599
5600
5601
5602
5603
5604
5605
5606
5607
5608
5609
5610
5611
5612
5613
5614
5615
5616
5617
5618
5619
5620
5621
5622
5623
5624
5625
5626
5627
5628
5629
5630
5631
5632
5633
5634
5635
5636
5637
5638
5639
5640
5641
5642
5643
5644
5645
5646
5647
5648
5649
5650
5651
5652
5653
5654
5655
5656
5657
5658
5659
5660
5661
5662
5663
5664
5665
5666
5667
5668
5669
5670
5671
5672
5673
5674
5675
5676
5677
5678
5679
5680
5681
5682
5683
5684
5685
5686
5687
5688
5689
5690
5691
5692
5693
5694
5695
5696
5697
5698
5699
5700
5701
5702
5703
5704
5705
5706
5707
5708
5709
5710
5711
5712
5713
5714
5715
5716
5717
5718
5719
5720
5721
5722
5723
5724
5725
5726
5727
5728
5729
5730
5731
5732
5733
5734
5735
5736
5737
5738
5739
5740
5741
5742
5743
5744
5745
5746
5747
5748
5749
5750
5751
5752
5753
5754
5755
5756
5757
5758
5759
5760
5761
5762
5763
5764
5765
5766
5767
5768
5769
5770
5771
5772
5773
5774
5775
5776
5777
5778
5779
5780
5781
5782
5783
5784
5785
5786
5787
5788
5789
5790
5791
5792
5793
5794
5795
5796
5797
5798
5799
5800
5801
5802
5803
5804
5805
5806
5807
5808
5809
5810
5811
5812
5813
5814
5815
5816
5817
5818
5819
5820
5821
5822
5823
5824
5825
5826
5827
5828
5829
5830
5831
5832
5833
5834
5835
5836
5837
5838
5839
5840
5841
5842
5843
5844
5845
5846
5847
5848
5849
5850
5851
5852
5853
5854
5855
5856
5857
5858
5859
5860
5861
5862
5863
5864
5865
5866
5867
5868
5869
5870
5871
5872
5873
5874
5875
5876
5877
5878
5879
5880
5881
5882
5883
5884
5885
5886
5887
5888
5889
5890
5891
5892
5893
5894
5895
5896
5897
5898
5899
5900
5901
5902
5903
5904
5905
5906
5907
5908
5909
5910
5911
5912
5913
5914
5915
5916
5917
5918
5919
5920
5921
5922
5923
5924
5925
5926
5927
5928
5929
5930
5931
5932
5933
5934
5935
5936
5937
5938
5939
5940
5941
5942
5943
5944
5945
5946
5947
5948
5949
5950
5951
5952
5953
5954
5955
5956
5957
5958
5959
5960
5961
5962
5963
5964
5965
5966
5967
5968
5969
5970
5971
5972
5973
5974
5975
5976
5977
5978
5979
5980
5981
5982
5983
5984
5985
5986
5987
5988
5989
5990
5991
5992
5993
5994
5995
5996
5997
5998
5999
6000
6001
6002
6003
6004
6005
6006
6007
6008
6009
6010
6011
6012
6013
6014
6015
6016
6017
6018
6019
6020
6021
6022
6023
6024
6025
6026
6027
6028
6029
6030
6031
6032
6033
6034
6035
6036
6037
6038
6039
6040
6041
6042
6043
6044
6045
6046
6047
6048
6049
6050
6051
6052
6053
6054
6055
6056
6057
6058
6059
6060
6061
6062
6063
6064
6065
6066
6067
6068
6069
6070
6071
6072
6073
6074
6075
6076
6077
6078
6079
6080
6081
6082
6083
6084
6085
6086
6087
6088
6089
6090
6091
6092
6093
6094
6095
6096
6097
6098
6099
6100
6101
6102
6103
6104
6105
6106
6107
6108
6109
6110
6111
6112
6113
6114
6115
6116
6117
6118
6119
6120
6121
6122
6123
6124
6125
6126
6127
6128
6129
6130
6131
6132
6133
6134
6135
6136
6137
6138
6139
6140
6141
6142
6143
6144
6145
6146
6147
6148
6149
6150
6151
6152
6153
6154
6155
6156
6157
6158
6159
6160
6161
6162
6163
6164
6165
6166
6167
6168
6169
6170
6171
6172
6173
6174
6175
6176
6177
6178
6179
6180
6181
6182
6183
6184
6185
6186
6187
6188
6189
6190
6191
6192
6193
6194
6195
6196
6197
6198
6199
6200
6201
6202
6203
6204
6205
6206
6207
6208
6209
6210
6211
6212
6213
6214
6215
6216
6217
6218
6219
6220
6221
6222
6223
6224
6225
6226
6227
6228
6229
6230
6231
6232
6233
6234
6235
6236
6237
6238
6239
6240
6241
6242
6243
6244
6245
6246
6247
6248
6249
6250
6251
6252
6253
6254
6255
6256
6257
6258
6259
6260
6261
6262
6263
6264
6265
6266
6267
6268
6269
6270
6271
6272
6273
6274
     





Network Working Group                                   R. Braden, Ed.
Request for Comments: 2205                                         ISI
Category: Standards Track                                     L. Zhang
                                                                  UCLA
                                                             S. Berson
                                                                   ISI
                                                             S. Herzog
                                                          IBM Research
                                                              S. Jamin
                                                     Univ. of Michigan
                                                        September 1997


                Resource ReSerVation Protocol (RSVP) --

                   Version 1 Functional Specification

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This memo describes version 1 of RSVP, a resource reservation setup
   protocol designed for an integrated services Internet.  RSVP provides
   receiver-initiated setup of resource reservations for multicast or
   unicast data flows, with good scaling and robustness properties.




















Braden, Ed., et. al.        Standards Track                     [Page 1]

RFC 2205                          RSVP                    September 1997


Table of Contents

   1. Introduction ................................................... 4
      1.1 Data Flows ................................................. 7
      1.2 Reservation Model .......................................... 8
      1.3 Reservation Styles .........................................11
      1.4 Examples of Styles .........................................14
   2. RSVP Protocol Mechanisms .......................................19
      2.1 RSVP Messages ..............................................19
      2.2 Merging Flowspecs ..........................................21
      2.3 Soft State .................................................22
      2.4 Teardown ...................................................24
      2.5 Errors .....................................................25
      2.6 Confirmation ...............................................27
      2.7 Policy Control .............................................27
      2.8 Security ...................................................28
      2.9 Non-RSVP Clouds ............................................29
      2.10 Host Model ................................................30
   3. RSVP Functional Specification ..................................32
      3.1 RSVP Message Formats .......................................32
      3.2 Port Usage .................................................47
      3.3 Sending RSVP Messages ......................................48
      3.4 Avoiding RSVP Message Loops ................................50
      3.5 Blockade State .............................................54
      3.6 Local Repair ...............................................56
      3.7 Time Parameters ............................................57
      3.8 Traffic Policing and Non-Integrated Service Hops ...........58
      3.9 Multihomed Hosts ...........................................59
      3.10 Future Compatibility ......................................61
      3.11 RSVP Interfaces ...........................................63
   4. Acknowledgments ................................................76
   APPENDIX A. Object Definitions ....................................77
   APPENDIX B. Error Codes and Values ................................92
   APPENDIX C. UDP Encapsulation .....................................98
   APPENDIX D. Glossary .............................................102
   REFERENCES .......................................................111
   SECURITY CONSIDERATIONS ..........................................111
   AUTHORS' ADDRESSES ...............................................112













Braden, Ed., et. al.        Standards Track                     [Page 2]

RFC 2205                          RSVP                    September 1997


   What's Changed

   This revision contains the following very minor changes from the ID14
   version.


      o    For clarity, each message type is now defined separately in
           Section 3.1.

      o    We added more precise and complete rules for accepting Path
           messages for unicast and multicast destinations (Section
           3.1.3).

      o    We added more precise and complete rules for processing and
           forwarding PathTear messages (Section 3.1.5).

      o    A note was added that a SCOPE object will be ignored if it
           appears in a ResvTear message (Section 3.1.6).

      o    A note was added that a SENDER_TSPEC or ADSPEC object will be
           ignored if it appears in a PathTear message (Section 3.1.5).

      o    The obsolete error code Ambiguous Filter Spec (09) was
           removed, and a new (and more consistent) name was given to
           error code 08 (Appendix B).

      o    In the generic interface to traffic control, the Adspec was
           added as a parameter to the AddFlow and ModFlow calls
           (3.11.2).  This is needed to accommodate a node that updates
           the slack term (S) of Guaranteed service.

      o    An error subtype was added for an Adspec error (Appendix B).

      o    Additional explanation was added for handling a CONFIRM
           object (Section 3.1.4).

      o    The rules for forwarding objects with unknown class type were
           clarified.

      o    Additional discussion was added to the Introduction and to
           Section 3.11.2 about the relationship of RSVP to the link
           layer.  (Section 3.10).

      o    Section 2.7 on Policy and Security was split into two
           sections, and some additional discussion of security was
           included.

      o    There were some minor editorial improvements.



Braden, Ed., et. al.        Standards Track                     [Page 3]

RFC 2205                          RSVP                    September 1997


1. Introduction

   This document defines RSVP, a resource reservation setup protocol
   designed for an integrated services Internet [RSVP93, RFC 1633].  The
   RSVP protocol is used by a host to request specific qualities of
   service from the network for particular application data streams or
   flows.  RSVP is also used by routers to deliver quality-of-service
   (QoS) requests to all nodes along the path(s) of the flows and to
   establish and maintain state to provide the requested service.  RSVP
   requests will generally result in resources being reserved in each
   node along the data path.

   RSVP requests resources for simplex flows, i.e., it requests
   resources in only one direction.  Therefore, RSVP treats a sender as
   logically distinct from a receiver, although the same application
   process may act as both a sender and a receiver at the same time.
   RSVP operates on top of IPv4 or IPv6, occupying the place of a
   transport protocol in the protocol stack.  However, RSVP does not
   transport application data but is rather an Internet control
   protocol, like ICMP, IGMP, or routing protocols.  Like the
   implementations of routing and management protocols, an
   implementation of RSVP will typically execute in the background, not
   in the data forwarding path, as shown in Figure 1.

   RSVP is not itself a routing protocol; RSVP is designed to operate
   with current and future unicast and multicast routing protocols.  An
   RSVP process consults the local routing database(s) to obtain routes.
   In the multicast case, for example, a host sends IGMP messages to
   join a multicast group and then sends RSVP messages to reserve
   resources along the delivery path(s) of that group.  Routing
   protocols determine where packets get forwarded; RSVP is only
   concerned with the QoS of those packets that are forwarded in
   accordance with routing.

   In order to efficiently accommodate large groups, dynamic group
   membership, and heterogeneous receiver requirements, RSVP makes
   receivers responsible for requesting a specific QoS [RSVP93].  A QoS
   request from a receiver host application is passed to the local RSVP
   process.  The RSVP protocol then carries the request to all the nodes
   (routers and hosts) along the reverse data path(s) to the data
   source(s), but only as far as the router where the receiver's data
   path joins the multicast distribution tree.  As a result, RSVP's
   reservation overhead is in general logarithmic rather than linear in
   the number of receivers.







Braden, Ed., et. al.        Standards Track                     [Page 4]

RFC 2205                          RSVP                    September 1997



              HOST                              ROUTER

 _____________________________       ____________________________
|  _______                    |     |                            |
| |       |   _______         |     |            _______         |
| |Appli- |  |       |        |RSVP |           |       |        |
| | cation|  | RSVP <---------------------------> RSVP  <---------->
| |       <-->       |        |     | _______   |       |        |
| |       |  |process|  _____ |     ||Routing|  |process|  _____ |
| |_._____|  |       -->Polcy||     ||       <-->       -->Polcy||
|   |        |__.__._| |Cntrl||     ||process|  |__.__._| |Cntrl||
|   |data       |  |   |_____||     ||__.____|     |  |   |_____||
|===|===========|==|==========|     |===|==========|==|==========|
|   |   --------|  |    _____ |     |   |  --------|  |    _____ |
|   |  |        |  ---->Admis||     |   |  |       |  ---->Admis||
|  _V__V_    ___V____  |Cntrl||     |  _V__V_    __V_____ |Cntrl||
| |      |  |        | |_____||     | |      |  |        ||_____||
| |Class-|  | Packet |        |     | |Class-|  | Packet |       |
| | ifier|==>Schedulr|================> ifier|==>Schedulr|===========>
| |______|  |________|        |data | |______|  |________|       |data
|                             |     |                            |
|_____________________________|     |____________________________|


                  Figure 1: RSVP in Hosts and Routers


   Quality of service is implemented for a particular data flow by
   mechanisms collectively called "traffic control".  These mechanisms
   include (1) a packet classifier, (2) admission control, and (3) a
   "packet scheduler" or some other link-layer-dependent mechanism to
   determine when particular packets are forwarded.  The "packet
   classifier" determines the QoS class (and perhaps the route) for each
   packet.  For each outgoing interface, the "packet scheduler" or other
   link-layer-dependent mechanism achieves the promised QoS.  Traffic
   control implements QoS service models defined by the Integrated
   Services Working Group.

   During reservation setup, an RSVP QoS request is passed to two local
   decision modules, "admission control" and "policy control".
   Admission control determines whether the node has sufficient
   available resources to supply the requested QoS.  Policy control








Braden, Ed., et. al.        Standards Track                     [Page 5]

RFC 2205                          RSVP                    September 1997


   determines whether the user has administrative permission to make the
   reservation.  If both checks succeed, parameters are set in the
   packet classifier and in the link layer interface (e.g., in the
   packet scheduler) to obtain the desired QoS.  If either check fails,
   the RSVP program returns an error notification to the application
   process that originated the request.

   RSVP protocol mechanisms provide a general facility for creating and
   maintaining distributed reservation state across a mesh of multicast
   or unicast delivery paths.  RSVP itself transfers and manipulates QoS
   and policy control parameters as opaque data, passing them to the
   appropriate traffic control and policy control modules for
   interpretation.  The structure and contents of the QoS parameters are
   documented in specifications developed by the Integrated Services
   Working Group; see [RFC 2210].  The structure and contents of the
   policy parameters are under development.

   Since the membership of a large multicast group and the resulting
   multicast tree topology are likely to change with time, the RSVP
   design assumes that state for RSVP and traffic control state is to be
   built and destroyed incrementally in routers and hosts.  For this
   purpose, RSVP establishes "soft" state; that is, RSVP sends periodic
   refresh messages to maintain the state along the reserved path(s).
   In the absence of refresh messages, the state automatically times out
   and is deleted.

   In summary, RSVP has the following attributes:

   o    RSVP makes resource reservations for both unicast and many-to-
        many multicast applications, adapting dynamically to changing
        group membership as well as to changing routes.

   o    RSVP is simplex, i.e., it makes reservations for unidirectional
        data flows.

   o    RSVP is receiver-oriented, i.e., the receiver of a data flow
        initiates and maintains the resource reservation used for that
        flow.

   o    RSVP maintains "soft" state in routers and hosts, providing
        graceful support for dynamic membership changes and automatic
        adaptation to routing changes.

   o    RSVP is not a routing protocol but depends upon present and
        future routing protocols.

   o    RSVP transports and maintains traffic control and policy control
        parameters that are opaque to RSVP.



Braden, Ed., et. al.        Standards Track                     [Page 6]

RFC 2205                          RSVP                    September 1997


   o    RSVP provides several reservation models or "styles" (defined
        below) to fit a variety of applications.

   o    RSVP provides transparent operation through routers that do not
        support it.

   o    RSVP supports both IPv4 and IPv6.

   Further discussion on the objectives and general justification for
   RSVP design are presented in [RSVP93] and [RFC 1633].

   The remainder of this section describes the RSVP reservation
   services.  Section 2 presents an overview of the RSVP protocol
   mechanisms.  Section 3 contains the functional specification of RSVP,
   while Section 4 presents explicit message processing rules.  Appendix
   A defines the variable-length typed data objects used in the RSVP
   protocol.  Appendix B defines error codes and values.  Appendix C
   defines a UDP encapsulation of RSVP messages, for hosts whose
   operating systems provide inadequate raw network I/O support.

   1.1 Data Flows

      RSVP defines a "session" to be a data flow with a particular
      destination and transport-layer protocol.  RSVP treats each
      session independently, and this document often omits the implied
      qualification "for the same session".

      An RSVP session is defined by the triple: (DestAddress, ProtocolId
      [, DstPort]).  Here DestAddress, the IP destination address of the
      data packets, may be a unicast or multicast address.  ProtocolId
      is the IP protocol ID.  The optional DstPort parameter is a
      "generalized destination port", i.e., some further demultiplexing
      point in the transport or application protocol layer.  DstPort
      could be defined by a UDP/TCP destination port field, by an
      equivalent field in another transport protocol, or by some
      application-specific information.

      Although the RSVP protocol is designed to be easily extensible for
      greater generality, the basic protocol documented here supports
      only UDP/TCP ports as generalized ports.  Note that it is not
      strictly necessary to include DstPort in the session definition
      when DestAddress is multicast, since different sessions can always
      have different multicast addresses.  However, DstPort is necessary
      to allow more than one unicast session addressed to the same
      receiver host.






Braden, Ed., et. al.        Standards Track                     [Page 7]

RFC 2205                          RSVP                    September 1997


      Figure 2 illustrates the flow of data packets in a single RSVP
      session, assuming multicast data distribution.  The arrows
      indicate data flowing from senders S1 and S2 to receivers R1, R2,
      and R3, and the cloud represents the distribution mesh created by
      multicast routing.  Multicast distribution forwards a copy of each
      data packet from a sender Si to every receiver Rj; a unicast
      distribution session has a single receiver R.  Each sender Si may
      be running in a unique Internet host, or a single host may contain
      multiple senders distinguished by "generalized source ports".


              Senders                              Receivers
                          _____________________
                         (                     ) ===> R1
                 S1 ===> (    Multicast        )
                         (                     ) ===> R2
                         (    distribution     )
                 S2 ===> (                     )
                         (    by Internet      ) ===> R3
                         (_____________________)

                 Figure 2: Multicast Distribution Session


      For unicast transmission, there will be a single destination host
      but there may be multiple senders; RSVP can set up reservations
      for multipoint-to-single-point transmission.

   1.2 Reservation Model

      An elementary RSVP reservation request consists of a "flowspec"
      together with a "filter spec"; this pair is called a "flow
      descriptor".  The flowspec specifies a desired QoS.  The filter
      spec, together with a session specification, defines the set of
      data packets -- the "flow" -- to receive the QoS defined by the
      flowspec.  The flowspec is used to set parameters in the node's
      packet scheduler or other link layer mechanism, while the filter
      spec is used to set parameters in the packet classifier.  Data
      packets that are addressed to a particular session but do not
      match any of the filter specs for that session are handled as
      best-effort traffic.

      The flowspec in a reservation request will generally include a
      service class and two sets of numeric parameters: (1) an "Rspec"
      (R for `reserve') that defines the desired QoS, and (2) a "Tspec"
      (T for `traffic') that describes the data flow.  The formats and
      contents of Tspecs and Rspecs are determined by the integrated
      service models [RFC 2210] and are generally opaque to RSVP.



Braden, Ed., et. al.        Standards Track                     [Page 8]

RFC 2205                          RSVP                    September 1997


      The exact format of a filter spec depends upon whether IPv4 or
      IPv6 is in use; see Appendix A.  In the most general approach
      [RSVP93], filter specs may select arbitrary subsets of the packets
      in a given session.  Such subsets might be defined in terms of
      senders (i.e., sender IP address and generalized source port), in
      terms of a higher-level protocol, or generally in terms of any
      fields in any protocol headers in the packet.  For example, filter
      specs might be used to select different subflows of a
      hierarchically-encoded video stream by selecting on fields in an
      application-layer header.  In the interest of simplicity (and to
      minimize layer violation), the basic filter spec format defined in
      the present RSVP specification has a very restricted form: sender
      IP address and optionally the UDP/TCP port number SrcPort.

      Because the UDP/TCP port numbers are used for packet
      classification, each router must be able to examine these fields.
      This raises three potential problems.

      1.   It is necessary to avoid IP fragmentation of a data flow for
           which a resource reservation is desired.

           Document [RFC 2210] specifies a procedure for applications
           using RSVP facilities to compute the minimum MTU over a
           multicast tree and return the result to the senders.

      2.   IPv6 inserts a variable number of variable-length Internet-
           layer headers before the transport header, increasing the
           difficulty and cost of packet classification for QoS.

           Efficient classification of IPv6 data packets could be
           obtained using the Flow Label field of the IPv6 header.  The
           details will be provided in the future.

      3.   IP-level Security, under either IPv4 or IPv6, may encrypt the
           entire transport header, hiding the port numbers of data
           packets from intermediate routers.

           A small extension to RSVP for IP Security under IPv4 and IPv6
           is described separately in [RFC 2207].

      RSVP messages carrying reservation requests originate at receivers
      and are passed upstream towards the sender(s).  Note: in this
      document, we define the directional terms "upstream" vs.
      "downstream", "previous hop" vs. "next hop", and "incoming
      interface" vs "outgoing interface" with respect to the direction
      of data flow.





Braden, Ed., et. al.        Standards Track                     [Page 9]

RFC 2205                          RSVP                    September 1997


      At each intermediate node, a reservation request triggers two
      general actions, as follows:

      1.   Make a reservation on a link

           The RSVP process passes the request to admission control and
           policy control.  If either test fails, the reservation is
           rejected and the RSVP process returns an error message to the
           appropriate receiver(s).  If both succeed, the node sets the
           packet classifier to select the data packets defined by the
           filter spec, and it interacts with the appropriate link layer
           to obtain the desired QoS defined by the flowspec.

           The detailed rules for satisfying an RSVP QoS request depend
           upon the particular link layer technology in use on each
           interface.  Specifications are under development in the ISSLL
           Working Group for mapping reservation requests into popular
           link layer technologies.  For a simple leased line, the
           desired QoS will be obtained from the packet scheduler in the
           link layer driver, for example.  If the link-layer technology
           implements its own QoS management capability, then RSVP must
           negotiate with the link layer to obtain the requested QoS.
           Note that the action to control QoS occurs at the place where
           the data enters the link-layer medium, i.e., at the upstream
           end of the logical or physical link, although an RSVP
           reservation request originates from receiver(s) downstream.

      2.   Forward the request upstream

           A reservation request is propagated upstream towards the
           appropriate senders.  The set of sender hosts to which a
           given reservation request is propagated is called the "scope"
           of that request.

           The reservation request that a node forwards upstream may
           differ from the request that it received from downstream, for
           two reasons.  The traffic control mechanism may modify the
           flowspec hop-by-hop.  More importantly, reservations from
           different downstream branches of the multicast tree(s) from
           the same sender (or set of senders) must be " merged" as
           reservations travel upstream.


      When a receiver originates a reservation request, it can also
      request a confirmation message to indicate that its request was
      (probably) installed in the network.  A successful reservation
      request propagates upstream along the multicast tree until it
      reaches a point where an existing reservation is equal or greater



Braden, Ed., et. al.        Standards Track                    [Page 10]

RFC 2205                          RSVP                    September 1997


      than that being requested.  At that point, the arriving request is
      merged with the reservation in place and need not be forwarded
      further; the node may then send a reservation confirmation message
      back to the receiver.  Note that the receipt of a confirmation is
      only a high-probability indication, not a guarantee, that the
      requested service is in place all the way to the sender(s), as
      explained in Section 2.6.

      The basic RSVP reservation model is "one pass": a receiver sends a
      reservation request upstream, and each node in the path either
      accepts or rejects the request.  This scheme provides no easy way
      for a receiver to find out the resulting end-to-end service.
      Therefore, RSVP supports an enhancement to one-pass service known
      as "One Pass With Advertising" (OPWA) [OPWA95].  With OPWA, RSVP
      control packets are sent downstream, following the data paths, to
      gather information that may be used to predict the end-to-end QoS.
      The results ("advertisements") are delivered by RSVP to the
      receiver hosts and perhaps to the receiver applications.  The
      advertisements may then be used by the receiver to construct, or
      to dynamically adjust, an appropriate reservation request.

   1.3 Reservation Styles

      A reservation request includes a set of options that are
      collectively called the reservation "style".

      One reservation option concerns the treatment of reservations for
      different senders within the same session: establish a "distinct"
      reservation for each upstream sender, or else make a single
      reservation that is "shared" among all packets of selected
      senders.

      Another reservation option controls the selection of senders; it
      may be an "explicit" list of all selected senders, or a "wildcard"
      that implicitly selects all the senders to the session.  In an
      explicit sender-selection reservation, each filter spec must match
      exactly one sender, while in a wildcard sender-selection no filter
      spec is needed.













Braden, Ed., et. al.        Standards Track                    [Page 11]

RFC 2205                          RSVP                    September 1997



           Sender   ||             Reservations:
         Selection  ||     Distinct     |        Shared
           _________||__________________|____________________
                    ||                  |                    |
          Explicit  ||  Fixed-Filter    |  Shared-Explicit   |
                    ||  (FF) style      |  (SE) Style        |
          __________||__________________|____________________|
                    ||                  |                    |
          Wildcard  ||  (None defined)  |  Wildcard-Filter   |
                    ||                  |  (WF) Style        |
          __________||__________________|____________________|


                 Figure 3: Reservation Attributes and Styles



      The following styles are currently defined (see Figure 3):

      o    Wildcard-Filter (WF) Style

           The WF style implies the options: "shared" reservation and
           "wildcard" sender selection.  Thus, a WF-style reservation
           creates a single reservation shared by flows from all
           upstream senders.  This reservation may be thought of as a
           shared "pipe", whose "size" is the largest of the resource
           requests from all receivers, independent of the number of
           senders using it.  A WF-style reservation is propagated
           upstream towards all sender hosts, and it automatically
           extends to new senders as they appear.

           Symbolically, we can represent a WF-style reservation request
           by:

               WF( * {Q})


           where the asterisk represents wildcard sender selection and Q
           represents the flowspec.

      o    Fixed-Filter (FF) Style

           The FF style implies the options: "distinct" reservations and
           "explicit" sender selection.  Thus, an elementary FF-style
           reservation request creates a distinct reservation for data
           packets from a particular sender, not sharing them with other
           senders' packets for the same session.



Braden, Ed., et. al.        Standards Track                    [Page 12]

RFC 2205                          RSVP                    September 1997


           Symbolically, we can represent an elementary FF reservation
           request by:

               FF( S{Q})


           where S is the selected sender and Q is the corresponding
           flowspec; the pair forms a flow descriptor.  RSVP allows
           multiple elementary FF-style reservations to be requested at
           the same time, using a list of flow descriptors:

               FF( S1{Q1}, S2{Q2}, ...)


           The total reservation on a link for a given session is the
           `sum' of Q1, Q2, ... for all requested senders.

      o    Shared Explicit (SE) Style

           The SE style implies the options: "shared" reservation and
           "explicit" sender selection.  Thus, an SE-style reservation
           creates a single reservation shared by selected upstream
           senders.  Unlike the WF style, the SE style allows a receiver
           to explicitly specify the set of senders to be included.

           We can represent an SE reservation request containing a
           flowspec Q and a list of senders S1, S2, ... by:

               SE( (S1,S2,...){Q} )


      Shared reservations, created by WF and SE styles, are appropriate
      for those multicast applications in which multiple data sources
      are unlikely to transmit simultaneously.  Packetized audio is an
      example of an application suitable for shared reservations; since
      a limited number of people talk at once, each receiver might issue
      a WF or SE reservation request for twice the bandwidth required
      for one sender (to allow some over-speaking).  On the other hand,
      the FF style, which creates distinct reservations for the flows
      from different senders, is appropriate for video signals.

      The RSVP rules disallow merging of shared reservations with
      distinct reservations, since these modes are fundamentally
      incompatible.  They also disallow merging explicit sender
      selection with wildcard sender selection, since this might produce
      an unexpected service for a receiver that specified explicit
      selection.  As a result of these prohibitions, WF, SE, and FF
      styles are all mutually incompatible.



Braden, Ed., et. al.        Standards Track                    [Page 13]

RFC 2205                          RSVP                    September 1997


      It would seem possible to simulate the effect of a WF reservation
      using the SE style.  When an application asked for WF, the RSVP
      process on the receiver host could use local state to create an
      equivalent SE reservation that explicitly listed all senders.
      However, an SE reservation forces the packet classifier in each
      node to explicitly select each sender in the list, while a WF
      allows the packet classifier to simply "wild card" the sender
      address and port.  When there is a large list of senders, a WF
      style reservation can therefore result in considerably less
      overhead than an equivalent SE style reservation.  For this
      reason, both SE and WF are included in the protocol.

      Other reservation options and styles may be defined in the future.

   1.4 Examples of Styles

      This section presents examples of each of the reservation styles
      and shows the effects of merging.

      Figure 4 illustrates a router with two incoming interfaces,
      labeled (a) and (b), through which flows will arrive, and two
      outgoing interfaces, labeled (c) and (d), through which data will
      be forwarded.  This topology will be assumed in the examples that
      follow.  There are three upstream senders; packets from sender S1
      (S2 and S3) arrive through previous hop (a) ((b), respectively).
      There are also three downstream receivers; packets bound for R1
      (R2 and R3) are routed via outgoing interface (c) ((d),
      respectively).  We furthermore assume that outgoing interface (d)
      is connected to a broadcast LAN, i.e., that replication occurs in
      the network; R2 and R3 are reached via different next hop routers
      (not shown).

      We must also specify the multicast routes within the node of
      Figure 4.  Assume first that data packets from each Si shown in
      Figure 4 are routed to both outgoing interfaces.  Under this
      assumption, Figures 5, 6, and 7 illustrate Wildcard-Filter,
      Fixed-Filter, and Shared-Explicit reservations, respectively.














Braden, Ed., et. al.        Standards Track                    [Page 14]

RFC 2205                          RSVP                    September 1997


                         ________________
                     (a)|                | (c)
      ( S1 ) ---------->|                |----------> ( R1 )
                        |     Router     |      |
                     (b)|                | (d)  |---> ( R2 )
      ( S2,S3 ) ------->|                |------|
                        |________________|      |---> ( R3 )
                                                |

                        Figure 4: Router Configuration



      For simplicity, these examples show flowspecs as one-dimensional
      multiples of some base resource quantity B.  The "Receives" column
      shows the RSVP reservation requests received over outgoing
      interfaces (c) and (d), and the "Reserves" column shows the
      resulting reservation state for each interface.   The "Sends"
      column shows the reservation requests that are sent upstream to
      previous hops (a) and (b).  In the "Reserves" column, each box
      represents one reserved "pipe" on the outgoing link, with the
      corresponding flow descriptor.

      Figure 5, showing the WF style, illustrates two distinct
      situations in which merging is required.  (1) Each of the two next
      hops on interface (d) results in a separate RSVP reservation
      request, as shown; these two requests must be merged into the
      effective flowspec, 3B, that is used to make the reservation on
      interface (d).  (2) The reservations on the interfaces (c) and (d)
      must be merged in order to forward the reservation requests
      upstream; as a result, the larger flowspec 4B is forwarded
      upstream to each previous hop.



















Braden, Ed., et. al.        Standards Track                    [Page 15]

RFC 2205                          RSVP                    September 1997



                             |
               Sends         |       Reserves             Receives
                             |
                             |       _______
         WF( *{4B} ) <- (a)  |  (c) | * {4B}|    (c) <- WF( *{4B} )
                             |      |_______|
                             |
      -----------------------|----------------------------------------
                             |       _______
         WF( *{4B} ) <- (b)  |  (d) | * {3B}|    (d) <- WF( *{3B} )
                             |      |_______|        <- WF( *{2B} )

              Figure 5: Wildcard-Filter (WF) Reservation Example



      Figure 6 shows Fixed-Filter (FF) style reservations.  For each
      outgoing interface, there is a separate reservation for each
      source that has been requested, but this reservation will be
      shared among all the receivers that made the request.  The flow
      descriptors for senders S2 and S3, received through outgoing
      interfaces (c) and (d), are packed (not merged) into the request
      forwarded to previous hop (b).  On the other hand, the three
      different flow descriptors specifying sender S1 are merged into
      the single request FF( S1{4B} ) that is sent to previous hop (a).


                          |
            Sends         |       Reserves             Receives
                          |
                          |       ________
     FF( S1{4B} ) <- (a)  |  (c) | S1{4B} |  (c) <- FF( S1{4B}, S2{5B} )
                          |      |________|
                          |      | S2{5B} |
                          |      |________|
     ---------------------|---------------------------------------------
                          |       ________
                  <- (b)  |  (d) | S1{3B} |  (d) <- FF( S1{3B}, S3{B} )
     FF( S2{5B}, S3{B} )  |      |________|      <- FF( S1{B} )
                          |      | S3{B}  |
                          |      |________|

              Figure 6: Fixed-Filter (FF) Reservation Example







Braden, Ed., et. al.        Standards Track                    [Page 16]

RFC 2205                          RSVP                    September 1997


      Figure 7 shows an example of Shared-Explicit (SE) style
      reservations.  When SE-style reservations are merged, the
      resulting filter spec is the union of the original filter specs,
      and the resulting flowspec is the largest flowspec.


                          |
            Sends         |       Reserves             Receives
                          |
                          |       ________
     SE( S1{3B} ) <- (a)  |  (c) |(S1,S2) |   (c) <- SE( (S1,S2){B} )
                          |      |   {B}  |
                          |      |________|
     ---------------------|---------------------------------------------
                          |      __________
                  <- (b)  | (d) |(S1,S2,S3)|  (d) <- SE( (S1,S3){3B} )
     SE( (S2,S3){3B} )    |     |   {3B}   |      <- SE( S2{2B} )
                          |     |__________|

            Figure 7: Shared-Explicit (SE) Reservation Example



      The three examples just shown assume that data packets from S1,
      S2, and S3 are routed to both outgoing interfaces.  The top part
      of Figure 8 shows another routing assumption: data packets from S2
      and S3 are not forwarded to interface (c), e.g., because the
      network topology provides a shorter path for these senders towards
      R1, not traversing this node.  The bottom part of Figure 8 shows
      WF style reservations under this assumption.  Since there is no
      route from (b) to (c), the reservation forwarded out interface (b)
      considers only the reservation on interface (d).



















Braden, Ed., et. al.        Standards Track                    [Page 17]

RFC 2205                          RSVP                    September 1997


                         _______________
                     (a)|               | (c)
      ( S1 ) ---------->| >-----------> |----------> ( R1 )
                        |    >          |
                        |      >        |
                     (b)|        >      | (d)
      ( S2,S3 ) ------->| >-------->--> |----------> ( R2, R3 )
                        |_______________|

                       Router Configuration


                             |
               Sends         |       Reserves             Receives
                             |
                             |       _______
         WF( *{4B} ) <- (a)  |  (c) | * {4B}|   (c) <- WF( *{4B} )
                             |      |_______|
                             |
      -----------------------|----------------------------------------
                             |       _______
         WF( *{3B} ) <- (b)  |  (d) | * {3B}|   (d) <- WF( * {3B} )
                             |      |_______|       <- WF( * {2B} )

             Figure 8: WF Reservation Example -- Partial Routing


























Braden, Ed., et. al.        Standards Track                    [Page 18]

RFC 2205                          RSVP                    September 1997


2. RSVP Protocol Mechanisms

   2.1 RSVP Messages


       Previous       Incoming           Outgoing             Next
       Hops           Interfaces         Interfaces           Hops

       _____             _____________________                _____
      |     | data -->  |                     |  data -->    |     |
      |  A  |-----------| a                 c |--------------|  C  |
      |_____| Path -->  |                     |  Path -->    |_____|
              <-- Resv  |                     |  <-- Resv     _____
       _____            |       ROUTER        |           |  |     |
      |     |  |        |                     |           |--|  D  |
      |  B  |--| data-->|                     |  data --> |  |_____|
      |_____|  |--------| b                 d |-----------|
               | Path-->|                     |  Path --> |   _____
       _____   | <--Resv|_____________________|  <-- Resv |  |     |
      |     |  |                                          |--|  D' |
      |  B' |--|                                          |  |_____|
      |_____|  |                                          |

                         Figure 9: Router Using RSVP



      Figure 9 illustrates RSVP's model of a router node.  Each data
      flow arrives from a "previous hop" through a corresponding
      "incoming interface" and departs through one or more "outgoing
      interface"(s).  The same interface may act in both the incoming
      and outgoing roles for different data flows in the same session.
      Multiple previous hops and/or next hops may be reached through a
      given physical interface; for example, the figure implies that D
      and D' are connected to (d) with a broadcast LAN.

      There are two fundamental RSVP message types: Resv and Path.

      Each receiver host sends RSVP reservation request (Resv) messages
      upstream towards the senders.  These messages must follow exactly
      the reverse of the path(s) the data packets will use, upstream to
      all the sender hosts included in the sender selection.  They
      create and maintain "reservation state" in each node along the
      path(s).  Resv messages must finally be delivered to the sender
      hosts themselves, so that the hosts can set up appropriate traffic
      control parameters for the first hop.  The processing of Resv
      messages was discussed previously in Section 1.2.




Braden, Ed., et. al.        Standards Track                    [Page 19]

RFC 2205                          RSVP                    September 1997


      Each RSVP sender host transmits RSVP "Path" messages downstream
      along the uni-/multicast routes provided by the routing
      protocol(s), following the paths of the data.  These Path messages
      store "path state" in each node along the way.  This path state
      includes at least the unicast IP address of the previous hop node,
      which is used to route the Resv messages hop-by-hop in the reverse
      direction.  (In the future, some routing protocols may supply
      reverse path forwarding information directly, replacing the
      reverse-routing function of path state).

      A Path message contains the following information in addition to
      the previous hop address:

      o    Sender Template

           A Path message is required to carry a Sender Template, which
           describes the format of data packets that the sender will
           originate.  This template is in the form of a filter spec
           that could be used to select this sender's packets from
           others in the same session on the same link.

           Sender Templates have exactly the same expressive power and
           format as filter specs that appear in Resv messages.
           Therefore a Sender Template may specify only the sender IP
           address and optionally the UDP/TCP sender port, and it
           assumes the protocol Id specified for the session.

      o    Sender Tspec

           A Path message is required to carry a Sender Tspec, which
           defines the traffic characteristics of the data flow that the
           sender will generate.  This Tspec is used by traffic control
           to prevent over-reservation, and perhaps unnecessary
           Admission Control failures.

      o    Adspec

           A Path message may carry a package of OPWA advertising
           information, known as an "Adspec".  An Adspec received in a
           Path message is passed to the local traffic control, which
           returns an updated Adspec; the updated version is then
           forwarded in Path messages sent downstream.









Braden, Ed., et. al.        Standards Track                    [Page 20]

RFC 2205                          RSVP                    September 1997


      Path messages are sent with the same source and destination
      addresses as the data, so that they will be routed correctly
      through non-RSVP clouds (see Section 2.9).  On the other hand,
      Resv messages are sent hop-by-hop; each RSVP-speaking node
      forwards a Resv message to the unicast address of a previous RSVP
      hop.

   2.2 Merging Flowspecs

      A Resv message forwarded to a previous hop carries a flowspec that
      is the "largest" of the flowspecs requested by the next hops to
      which the data flow will be sent (however, see Section 3.5 for a
      different merging rule used in certain cases).  We say the
      flowspecs have been "merged".  The examples shown in Section 1.4
      illustrated another case of merging, when there are multiple
      reservation requests from different next hops for the same session
      and with the same filter spec, but RSVP should install only one
      reservation on that interface.  Here again, the installed
      reservation should have an effective flowspec that is the
      "largest" of the flowspecs requested by the different next hops.

      Since flowspecs are opaque to RSVP, the actual rules for comparing
      flowspecs must be defined and implemented outside RSVP proper.
      The comparison rules are defined in the appropriate integrated
      service specification document.  An RSVP implementation will need
      to call service-specific routines to perform flowspec merging.

      Note that flowspecs are generally multi-dimensional vectors; they
      may contain both Tspec and Rspec components, each of which may
      itself be multi-dimensional.  Therefore, it may not be possible to
      strictly order two flowspecs.  For example, if one request calls
      for a higher bandwidth and another calls for a tighter delay
      bound, one is not "larger" than the other.  In such a case,
      instead of taking the larger, the service-specific merging
      routines must be able to return a third flowspec that is at least
      as large as each; mathematically, this is the "least upper bound"
      (LUB).  In some cases, a flowspec at least as small is needed;
      this is the "greatest lower bound" (GLB) GLB (Greatest Lower
      Bound).

      The following steps are used to calculate the effective flowspec
      (Re, Te) to be installed on an interface [RFC 2210].  Here Te is
      the effective Tspec and Re is the effective Rspec.








Braden, Ed., et. al.        Standards Track                    [Page 21]

RFC 2205                          RSVP                    September 1997


      1.   An effective flowspec is determined for the outgoing
           interface.  Depending upon the link-layer technology, this
           may require merging flowspecs from different next hops; this
           means computing the effective flowspec as the LUB of the
           flowspecs.  Note that what flowspecs to merge is determined
           by the link layer medium (see Section 3.11.2), while how to
           merge them is determined by the service model in use [RFC
           2210].

           The result is a flowspec that is opaque to RSVP but actually
           consists of the pair (Re, Resv_Te), where is Re is the
           effective Rspec and Resv_Te is the effective Tspec.

      2.   A service-specific calculation of Path_Te, the sum of all
           Tspecs that were supplied in Path messages from different
           previous hops (e.g., some or all of A, B, and B' in Figure
           9), is performed.

      3.   (Re, Resv_Te) and Path_Te are passed to traffic control.
           Traffic control will compute the effective flowspec as the
           "minimum" of Path_Te and Resv_Te, in a service-dependent
           manner.

      Section 3.11.6 defines a generic set of service-specific calls to
      compare flowspecs, to compute the LUB and GLB of flowspecs, and to
      compare and sum Tspecs.

   2.3 Soft State

      RSVP takes a "soft state" approach to managing the reservation
      state in routers and hosts.  RSVP soft state is created and
      periodically refreshed by Path and Resv messages.  The state is
      deleted if no matching refresh messages arrive before the
      expiration of a "cleanup timeout" interval.  State may also be
      deleted by an explicit "teardown" message, described in the next
      section.  At the expiration of each "refresh timeout" period and
      after a state change, RSVP scans its state to build and forward
      Path and Resv refresh messages to succeeding hops.

      Path and Resv messages are idempotent.  When a route changes, the
      next Path message will initialize the path state on the new route,
      and future Resv messages will establish reservation state there;
      the state on the now-unused segment of the route will time out.
      Thus, whether a message is "new" or a "refresh" is determined
      separately at each node, depending upon the existence of state at
      that node.





Braden, Ed., et. al.        Standards Track                    [Page 22]

RFC 2205                          RSVP                    September 1997


      RSVP sends its messages as IP datagrams with no reliability
      enhancement.  Periodic transmission of refresh messages by hosts
      and routers is expected to handle the occasional loss of an RSVP
      message.  If the effective cleanup timeout is set to K times the
      refresh timeout period, then RSVP can tolerate K-1 successive RSVP
      packet losses without falsely deleting state.  The network traffic
      control mechanism should be statically configured to grant some
      minimal bandwidth for RSVP messages to protect them from
      congestion losses.

      The state maintained by RSVP is dynamic; to change the set of
      senders Si or to change any QoS request, a host simply starts
      sending revised Path and/or Resv messages.  The result will be an
      appropriate adjustment in the RSVP state in all nodes along the
      path; unused state will time out if it is not explicitly torn
      down.

      In steady state, state is refreshed hop-by-hop to allow merging.
      When the received state differs from the stored state, the stored
      state is updated.  If this update results in modification of state
      to be forwarded in refresh messages, these refresh messages must
      be generated and forwarded immediately, so that state changes can
      be propagated end-to-end without delay.  However, propagation of a
      change stops when and if it reaches a point where merging causes
      no resulting state change.  This minimizes RSVP control traffic
      due to changes and is essential for scaling to large multicast
      groups.

      State that is received through a particular interface I* should
      never be forwarded out the same interface.  Conversely, state that
      is forwarded out interface I* must be computed using only state
      that arrived on interfaces different from I*.  A trivial example
      of this rule is illustrated in Figure 10, which shows a transit
      router with one sender and one receiver on each interface (and
      assumes one next/previous hop per interface).  Interfaces (a) and
      (c) serve as both outgoing and incoming interfaces for this
      session.  Both receivers are making wildcard-style reservations,
      in which the Resv messages are forwarded to all previous hops for
      senders in the group, with the exception of the next hop from
      which they came.  The result is independent reservations in the
      two directions.

      There is an additional rule governing the forwarding of Resv
      messages: state from Resv messages received from outgoing
      interface Io should be forwarded to incoming interface Ii only if
      Path messages from Ii are forwarded to Io.





Braden, Ed., et. al.        Standards Track                    [Page 23]

RFC 2205                          RSVP                    September 1997


                         ________________
                      a |                | c
      ( R1, S1 ) <----->|     Router     |<-----> ( R2, S2 )
                        |________________|

             Send                |        Receive
                                 |
        WF( *{3B}) <-- (a)       |     (c) <-- WF( *{3B})
                                 |
             Receive             |          Send
                                 |
        WF( *{4B}) --> (a)       |     (c) --> WF( *{4B})
                                 |
             Reserve on (a)      |        Reserve on (c)
              __________         |        __________
             |  * {4B}  |        |       |   * {3B} |
             |__________|        |       |__________|
                                 |

                     Figure 10: Independent Reservations


   2.4 Teardown

      RSVP "teardown" messages remove path or reservation state
      immediately.  Although it is not necessary to explicitly tear down
      an old reservation, we recommend that all end hosts send a
      teardown request as soon as an application finishes.

      There are two types of RSVP teardown message, PathTear and
      ResvTear.  A PathTear message travels towards all receivers
      downstream from its point of initiation and deletes path state, as
      well as all dependent reservation state, along the way.  An
      ResvTear message deletes reservation state and travels towards all
      senders upstream from its point of initiation.  A PathTear
      (ResvTear) message may be conceptualized as a reversed-sense Path
      message (Resv message, respectively).

      A teardown request may be initiated either by an application in an
      end system (sender or receiver), or by a router as the result of
      state timeout or service preemption.  Once initiated, a teardown
      request must be forwarded hop-by-hop without delay.  A teardown
      message deletes the specified state in the node where it is
      received.  As always, this state change will be propagated
      immediately to the next node, but only if there will be a net
      change after merging.  As a result, a ResvTear message will prune
      the reservation state back (only) as far as possible.




Braden, Ed., et. al.        Standards Track                    [Page 24]

RFC 2205                          RSVP                    September 1997


      Like all other RSVP messages, teardown requests are not delivered
      reliably.  The loss of a teardown request message will not cause a
      protocol failure because the unused state will eventually time out
      even though it is not explicitly deleted.  If a teardown message
      is lost, the router that failed to receive that message will time
      out its state and initiate a new teardown message beyond the loss
      point.  Assuming that RSVP message loss probability is small, the
      longest time to delete state will seldom exceed one refresh
      timeout period.

      It should be possible to tear down any subset of the established
      state.  For path state, the granularity for teardown is a single
      sender.  For reservation state, the granularity is an individual
      filter spec.  For example, refer to Figure 7.  Receiver R1 could
      send a ResvTear message for sender S2 only (or for any subset of
      the filter spec list), leaving S1 in place.

      A ResvTear message specifies the style and filters; any flowspec
      is ignored.  Whatever flowspec is in place will be removed if all
      its filter specs are torn down.

   2.5 Errors

      There are two RSVP error messages, ResvErr and PathErr.  PathErr
      messages are very simple; they are simply sent upstream to the
      sender that created the error, and they do not change path state
      in the nodes though which they pass.  There are only a few
      possible causes of path errors.

      However, there are a number of ways for a syntactically valid
      reservation request to fail at some node along the path.  A node
      may also decide to preempt an established reservation.  The
      handling of ResvErr messages is somewhat complex (Section 3.5).
      Since a request that fails may be the result of merging a number
      of requests, a reservation error must be reported to all of the
      responsible receivers.  In addition, merging heterogeneous
      requests creates a potential difficulty known as the "killer
      reservation" problem, in which one request could deny service to
      another.  There are actually two killer-reservation problems.

      1.   The first killer reservation problem (KR-I) arises when there
           is already a reservation Q0 in place.  If another receiver
           now makes a larger reservation Q1 > Q0, the result of merging
           Q0 and Q1 may be rejected by admission control in some
           upstream node.  This must not deny service to Q0.






Braden, Ed., et. al.        Standards Track                    [Page 25]

RFC 2205                          RSVP                    September 1997


           The solution to this problem is simple: when admission
           control fails for a reservation request, any existing
           reservation is left in place.

      2.   The second killer reservation problem (KR-II) is the
           converse: the receiver making a reservation Q1 is persistent
           even though Admission Control is failing for Q1 in some node.
           This must not prevent a different receiver from now
           establishing a smaller reservation Q0 that would succeed if
           not merged with Q1.

           To solve this problem, a ResvErr message establishes
           additional state, called "blockade state", in each node
           through which it passes.  Blockade state in a node modifies
           the merging procedure to omit the offending flowspec (Q1 in
           the example) from the merge, allowing a smaller request to be
           forwarded and established.  The Q1 reservation state is said
           to be "blockaded".  Detailed rules are presented in Section
           3.5.

      A reservation request that fails Admission Control creates
      blockade state but is left in place in nodes downstream of the
      failure point.  It has been suggested that these reservations
      downstream from the failure represent "wasted" reservations and
      should be timed out if not actively deleted.  However, the
      downstream reservations are left in place, for the following
      reasons:

      o    There are two possible reasons for a receiver persisting in a
           failed reservation: (1) it is polling for resource
           availability along the entire path, or (2) it wants to obtain
           the desired QoS along as much of the path as possible.
           Certainly in the second case, and perhaps in the first case,
           the receiver will want to hold onto the reservations it has
           made downstream from the failure.

      o    If these downstream reservations were not retained, the
           responsiveness of RSVP to certain transient failures would be
           impaired.  For example, suppose a route "flaps" to an
           alternate route that is congested, so an existing reservation
           suddenly fails, then quickly recovers to the original route.
           The blockade state in each downstream router must not remove
           the state or prevent its immediate refresh.

      o    If we did not refresh the downstream reservations, they might
           time out, to be restored every Tb seconds (where Tb is the
           blockade state timeout interval).  Such intermittent behavior
           might be very distressing for users.



Braden, Ed., et. al.        Standards Track                    [Page 26]

RFC 2205                          RSVP                    September 1997


   2.6 Confirmation

      To request a confirmation for its reservation request, a receiver
      Rj includes in the Resv message a confirmation-request object
      containing Rj's IP address.  At each merge point, only the largest
      flowspec and any accompanying confirmation-request object is
      forwarded upstream.  If the reservation request from Rj is equal
      to or smaller than the reservation in place on a node, its Resv is
      not forwarded further, and if the Resv included a confirmation-
      request object, a ResvConf message is sent back to Rj.  If the
      confirmation request is forwarded, it is forwarded immediately,
      and no more than once for each request.

      This confirmation mechanism has the following consequences:

      o    A new reservation request with a flowspec larger than any in
           place for a session will normally result in either a ResvErr
           or a ResvConf message back to the receiver from each sender.
           In this case, the ResvConf message will be an end-to-end
           confirmation.

      o    The receipt of a ResvConf gives no guarantees.  Assume the
           first two reservation requests from receivers R1 and R2
           arrive at the node where they are merged.  R2, whose
           reservation was the second to arrive at that node, may
           receive a ResvConf from that node while R1's request has not
           yet propagated all the way to a matching sender and may still
           fail.  Thus, R2 may receive a ResvConf although there is no
           end-to-end reservation in place; furthermore, R2 may receive
           a ResvConf followed by a ResvErr.


   2.7 Policy Control

      RSVP-mediated QoS requests allow particular user(s) to obtain
      preferential access to network resources.  To prevent abuse, some
      form of back pressure will generally be required on users who make
      reservations.  For example, such back pressure may be accomplished
      by administrative access policies, or it may depend upon some form
      of user feedback such as real or virtual billing for the "cost" of
      a reservation.  In any case, reliable user identification and
      selective admission will generally be needed when a reservation is
      requested.

      The term "policy control" is used for the mechanisms required to
      support access policies and back pressure for RSVP reservations.
      When a new reservation is requested, each node must answer two
      questions: "Are enough resources available to meet this request?"



Braden, Ed., et. al.        Standards Track                    [Page 27]

RFC 2205                          RSVP                    September 1997


      and "Is this user allowed to make this reservation?"  These two
      decisions are termed the "admission control" decision and the
      "policy control" decision, respectively, and both must be
      favorable in order for RSVP to make a reservation.  Different
      administrative domains in the Internet may have different
      reservation policies.

      The input to policy control is referred to as "policy data", which
      RSVP carries in POLICY_DATA objects.  Policy data may include
      credentials identifying users or user classes, account numbers,
      limits, quotas, etc.  Like flowspecs, policy data is opaque to
      RSVP, which simply passes it to policy control when required.
      Similarly, merging of policy data must be done by the policy
      control mechanism rather than by RSVP itself.  Note that the merge
      points for policy data are likely to be at the boundaries of
      administrative domains.  It may therefore be necessary to carry
      accumulated and unmerged policy data upstream through multiple
      nodes before reaching one of these merge points.

      Carrying user-provided policy data in Resv messages presents a
      potential scaling problem.  When a multicast group has a large
      number of receivers, it will be impossible or undesirable to carry
      all receivers' policy data upstream.  The policy data will have to
      be administratively merged at places near the receivers, to avoid
      excessive policy data.  Further discussion of these issues and an
      example of a policy control scheme will be found in [PolArch96].
      Specifications for the format of policy data objects and RSVP
      processing rules for them are under development.

   2.8 Security

      RSVP raises the following security issues.

      o    Message integrity and node authentication

           Corrupted or spoofed reservation requests could lead to theft
           of service by unauthorized parties or to denial of service
           caused by locking up network resources.  RSVP protects
           against such attacks with a hop-by-hop authentication
           mechanism using an encrypted hash function.  The mechanism is
           supported by INTEGRITY objects that may appear in any RSVP
           message.  These objects use a keyed cryptographic digest
           technique, which assumes that RSVP neighbors share a secret.
           Although this mechanism is part of the base RSVP
           specification, it is described in a companion document
           [Baker96].





Braden, Ed., et. al.        Standards Track                    [Page 28]

RFC 2205                          RSVP                    September 1997


           Widespread use of the RSVP integrity mechanism will require
           the availability of the long-sought key management and
           distribution infrastructure for routers.  Until that
           infrastructure becomes available, manual key management will
           be required to secure RSVP message integrity.

      o    User authentication

           Policy control will depend upon positive authentication of
           the user responsible for each reservation request.  Policy
           data may therefore include cryptographically protected user
           certificates.  Specification of such certificates is a future
           issue.

           Even without globally-verifiable user certificates, it may be
           possible to provide practical user authentication in many
           cases by establishing a chain of trust, using the hop-by-hop
           INTEGRITY mechanism described earlier.

      o    Secure data streams

           The first two security issues concerned RSVP's operation.  A
           third security issue concerns resource reservations for
           secure data streams.  In particular, the use of IPSEC (IP
           Security) in the data stream poses a problem for RSVP:  if
           the transport and higher level headers are encrypted, RSVP's
           generalized port numbers cannot be used to define a session
           or a sender.

           To solve this problem, an RSVP extension has been defined in
           which the security association identifier (IPSEC SPI) plays a
           role roughly equivalent to the generalized ports [RFC 2207].

   2.9 Non-RSVP Clouds

      It is impossible to deploy RSVP (or any new protocol) at the same
      moment throughout the entire Internet.  Furthermore, RSVP may
      never be deployed everywhere.  RSVP must therefore provide correct
      protocol operation even when two RSVP-capable routers are joined
      by an arbitrary "cloud" of non-RSVP routers.  Of course, an
      intermediate cloud that does not support RSVP is unable to perform
      resource reservation.  However, if such a cloud has sufficient
      capacity, it may still provide useful realtime service.

      RSVP is designed to operate correctly through such a non-RSVP
      cloud.  Both RSVP and non-RSVP routers forward Path messages
      towards the destination address using their local uni-/multicast
      routing table.  Therefore, the routing of Path messages will be



Braden, Ed., et. al.        Standards Track                    [Page 29]

RFC 2205                          RSVP                    September 1997


      unaffected by non-RSVP routers in the path.  When a Path message
      traverses a non-RSVP cloud, it carries to the next RSVP-capable
      node the IP address of the last RSVP-capable router before
      entering the cloud.  An Resv message is then forwarded directly to
      the next RSVP-capable router on the path(s) back towards the
      source.

      Even though RSVP operates correctly through a non-RSVP cloud, the
      non-RSVP-capable nodes will in general perturb the QoS provided to
      a receiver.  Therefore, RSVP passes a `NonRSVP' flag bit to the
      local traffic control mechanism when there are non-RSVP-capable
      hops in the path to a given sender.  Traffic control combines this
      flag bit with its own sources of information, and forwards the
      composed information on integrated service capability along the
      path to receivers using Adspecs [RFC 2210].

      Some topologies of RSVP routers and non-RSVP routers can cause
      Resv messages to arrive at the wrong RSVP-capable node, or to
      arrive at the wrong interface of the correct node.  An RSVP
      process must be prepared to handle either situation.  If the
      destination address does not match any local interface and the
      message is not a Path or PathTear, the message must be forwarded
      without further processing by this node.  To handle the wrong
      interface case, a "Logical Interface Handle" (LIH) is used.  The
      previous hop information included in a Path message includes not
      only the IP address of the previous node but also an LIH defining
      the logical outgoing interface; both values are stored in the path
      state.  A Resv message arriving at the addressed node carries both
      the IP address and the LIH of the correct outgoing interface, i.e,
      the interface that should receive the requested reservation,
      regardless of which interface it arrives on.

      The LIH may also be useful when RSVP reservations are made over a
      complex link layer, to map between IP layer and link layer flow
      entities.

   2.10 Host Model

      Before a session can be created, the session identification
      (DestAddress, ProtocolId [, DstPort]) must be assigned and
      communicated to all the senders and receivers by some out-of-band
      mechanism.  When an RSVP session is being set up, the following
      events happen at the end systems.








Braden, Ed., et. al.        Standards Track                    [Page 30]

RFC 2205                          RSVP                    September 1997


      H1   A receiver joins the multicast group specified by
           DestAddress, using IGMP.

      H2   A potential sender starts sending RSVP Path messages to the
           DestAddress.

      H3   A receiver application receives a Path message.

      H4   A receiver starts sending appropriate Resv messages,
           specifying the desired flow descriptors.

      H5   A sender application receives a Resv message.

      H6   A sender starts sending data packets.

      There are several synchronization considerations.

      o    H1 and H2 may happen in either order.

      o    Suppose that a new sender starts sending data (H6) but there
           are no multicast routes because no receivers have joined the
           group (H1).  Then the data will be dropped at some router
           node (which node depends upon the routing protocol) until
           receivers(s) appear.

      o    Suppose that a new sender starts sending Path messages (H2)
           and data (H6) simultaneously, and there are receivers but no
           Resv messages have reached the sender yet (e.g., because its
           Path messages have not yet propagated to the receiver(s)).
           Then the initial data may arrive at receivers without the
           desired QoS.  The sender could mitigate this problem by
           awaiting arrival of the first Resv message (H5); however,
           receivers that are farther away may not have reservations in
           place yet.

      o    If a receiver starts sending Resv messages (H4) before
           receiving any Path messages (H3), RSVP will return error
           messages to the receiver.

           The receiver may simply choose to ignore such error messages,
           or it may avoid them by waiting for Path messages before
           sending Resv messages.

      A specific application program interface (API) for RSVP is not
      defined in this protocol spec, as it may be host system dependent.
      However, Section 3.11.1 discusses the general requirements and
      outlines a generic interface.




Braden, Ed., et. al.        Standards Track                    [Page 31]

RFC 2205                          RSVP                    September 1997


3. RSVP Functional Specification

   3.1 RSVP Message Formats

      An RSVP message consists of a common header, followed by a body
      consisting of a variable number of variable-length, typed
      "objects".  The following subsections define the formats of the
      common header, the standard object header, and each of the RSVP
      message types.

      For each RSVP message type, there is a set of rules for the
      permissible choice of object types.  These rules are specified
      using Backus-Naur Form (BNF) augmented with square brackets
      surrounding optional sub-sequences.  The BNF implies an order for
      the objects in a message.  However, in many (but not all) cases,
      object order makes no logical difference.  An implementation
      should create messages with the objects in the order shown here,
      but accept the objects in any permissible order.

      3.1.1 Common Header

                0             1              2             3
         +-------------+-------------+-------------+-------------+
         | Vers | Flags|  Msg Type   |       RSVP Checksum       |
         +-------------+-------------+-------------+-------------+
         |  Send_TTL   | (Reserved)  |        RSVP Length        |
         +-------------+-------------+-------------+-------------+



         The fields in the common header are as follows:

         Vers: 4 bits

              Protocol version number.  This is version 1.

         Flags: 4 bits

              0x01-0x08: Reserved

                   No flag bits are defined yet.

         Msg Type: 8 bits

              1 = Path

              2 = Resv




Braden, Ed., et. al.        Standards Track                    [Page 32]

RFC 2205                          RSVP                    September 1997


              3 = PathErr

              4 = ResvErr

              5 = PathTear

              6 = ResvTear

              7 = ResvConf

         RSVP Checksum: 16 bits

              The one's complement of the one's complement sum of the
              message, with the checksum field replaced by zero for the
              purpose of computing the checksum.  An all-zero value
              means that no checksum was transmitted.

         Send_TTL: 8 bits

              The IP TTL value with which the message was sent.  See
              Section 3.8.

         RSVP Length: 16 bits

              The total length of this RSVP message in bytes, including
              the common header and the variable-length objects that
              follow.

      3.1.2 Object Formats

         Every object consists of one or more 32-bit words with a one-
         word header, with the following format:

                0             1              2             3
         +-------------+-------------+-------------+-------------+
         |       Length (bytes)      |  Class-Num  |   C-Type    |
         +-------------+-------------+-------------+-------------+
         |                                                       |
         //                  (Object contents)                   //
         |                                                       |
         +-------------+-------------+-------------+-------------+










Braden, Ed., et. al.        Standards Track                    [Page 33]

RFC 2205                          RSVP                    September 1997


         An object header has the following fields:

         Length

              A 16-bit field containing the total object length in
              bytes.  Must always be a multiple of 4, and at least 4.

         Class-Num

              Identifies the object class; values of this field are
              defined in Appendix A.  Each object class has a name,
              which is always capitalized in this document.  An RSVP
              implementation must recognize the following classes:

              NULL

                   A NULL object has a Class-Num of zero, and its C-Type
                   is ignored.  Its length must be at least 4, but can
                   be any multiple of 4.  A NULL object may appear
                   anywhere in a sequence of objects, and its contents
                   will be ignored by the receiver.

              SESSION

                   Contains the IP destination address (DestAddress),
                   the IP protocol id, and some form of generalized
                   destination port, to define a specific session for
                   the other objects that follow.  Required in every
                   RSVP message.

              RSVP_HOP

                   Carries the IP address of the RSVP-capable node that
                   sent this message and a logical outgoing interface
                   handle (LIH; see Section 3.3).  This document refers
                   to a RSVP_HOP object as a PHOP ("previous hop")
                   object for downstream messages or as a NHOP (" next
                   hop") object for upstream messages.

              TIME_VALUES

                   Contains the value for the refresh period R used by
                   the creator of the message; see Section 3.7.
                   Required in every Path and Resv message.







Braden, Ed., et. al.        Standards Track                    [Page 34]

RFC 2205                          RSVP                    September 1997


              STYLE

                   Defines the reservation style plus style-specific
                   information that is not in FLOWSPEC or FILTER_SPEC
                   objects.  Required in every Resv message.

              FLOWSPEC

                   Defines a desired QoS, in a Resv message.

              FILTER_SPEC

                   Defines a subset of session data packets that should
                   receive the desired QoS (specified by a FLOWSPEC
                   object), in a Resv message.

              SENDER_TEMPLATE

                   Contains a sender IP address and perhaps some
                   additional demultiplexing information to identify a
                   sender.  Required in a Path message.

              SENDER_TSPEC

                   Defines the traffic characteristics of a sender's
                   data flow.  Required in a Path message.

              ADSPEC

                   Carries OPWA data, in a Path message.

              ERROR_SPEC

                   Specifies an error in a PathErr, ResvErr, or a
                   confirmation in a ResvConf message.

              POLICY_DATA

                   Carries information that will allow a local policy
                   module to decide whether an associated reservation is
                   administratively permitted.  May appear in Path,
                   Resv, PathErr, or ResvErr message.

                   The use of POLICY_DATA objects is not fully specified
                   at this time; a future document will fill this gap.






Braden, Ed., et. al.        Standards Track                    [Page 35]

RFC 2205                          RSVP                    September 1997


              INTEGRITY

                   Carries cryptographic data to authenticate the
                   originating node and to verify the contents of this
                   RSVP message.  The use of the INTEGRITY object is
                   described in [Baker96].

              SCOPE

                   Carries an explicit list of sender hosts towards
                   which the information in the message is to be
                   forwarded.  May appear in a Resv, ResvErr, or
                   ResvTear message.  See Section 3.4.

              RESV_CONFIRM

                   Carries the IP address of a receiver that requested a
                   confirmation.  May appear in a Resv or ResvConf
                   message.

         C-Type

              Object type, unique within Class-Num.  Values are defined
              in Appendix A.

         The maximum object content length is 65528 bytes.  The Class-
         Num and C-Type fields may be used together as a 16-bit number
         to define a unique type for each object.

         The high-order two bits of the Class-Num is used to determine
         what action a node should take if it does not recognize the
         Class-Num of an object; see Section 3.10.

      3.1.3 Path Messages

         Each sender host periodically sends a Path message for each
         data flow it originates.  It contains a SENDER_TEMPLATE object
         defining the format of the data packets and a SENDER_TSPEC
         object specifying the traffic characteristics of the flow.
         Optionally, it may contain may be an ADSPEC object carrying
         advertising (OPWA) data for the flow.

         A Path message travels from a sender to receiver(s) along the
         same path(s) used by the data packets.  The IP source address
         of a Path message must be an address of the sender it
         describes, while the destination address must be the
         DestAddress for the session.  These addresses assure that the
         message will be correctly routed through a non-RSVP cloud.



Braden, Ed., et. al.        Standards Track                    [Page 36]

RFC 2205                          RSVP                    September 1997


         The format of a Path message is as follows:

           <Path Message> ::= <Common Header> [ <INTEGRITY> ]

                                     <SESSION> <RSVP_HOP>

                                     <TIME_VALUES>

                                    [ <POLICY_DATA> ... ]

                                    [ <sender descriptor> ]

           <sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>

                                    [ <ADSPEC> ]


         If the INTEGRITY object is present, it must immediately follow
         the common header.  There are no other requirements on
         transmission order, although the above order is recommended.
         Any number of POLICY_DATA objects may appear.

         The PHOP (i.e., RSVP_HOP) object of each Path message contains
         the previous hop address, i.e., the IP address of the interface
         through which the Path message was most recently sent.  It also
         carries a logical interface handle (LIH).

         Each RSVP-capable node along the path(s) captures a Path
         message and processes it to create path state for the sender
         defined by the SENDER_TEMPLATE and SESSION objects.  Any
         POLICY_DATA, SENDER_TSPEC, and ADSPEC objects are also saved in
         the path state.  If an error is encountered while processing a
         Path message, a PathErr message is sent to the originating
         sender of the Path message.  Path messages must satisfy the
         rules on SrcPort and DstPort in Section 3.2.

         Periodically, the RSVP process at a node scans the path state
         to create new Path messages to forward towards the receiver(s).
         Each message contains a sender descriptor defining one sender,
         and carries the original sender's IP address as its IP source
         address.  Path messages eventually reach the applications on
         all receivers; however, they are not looped back to a receiver
         running in the same application process as the sender.

         The RSVP process forwards Path messages and replicates them as
         required by multicast sessions, using routing information it
         obtains from the appropriate uni-/multicast routing process.
         The route depends upon the session DestAddress, and for some



Braden, Ed., et. al.        Standards Track                    [Page 37]

RFC 2205                          RSVP                    September 1997


         routing protocols also upon the source (sender's IP) address.
         The routing information generally includes the list of zero or
         more outgoing interfaces to which the Path message is to be
         forwarded.  Because each outgoing interface has a different IP
         address, the Path messages sent out different interfaces
         contain different PHOP addresses.  In addition, ADSPEC objects
         carried in Path messages will also generally differ for
         different outgoing interfaces.

         Path state for a given session and sender may not necessarily
         have a unique PHOP or unique incoming interface.  There are two
         cases, corresponding to multicast and unicast sessions.

         o    Multicast Sessions

              Multicast routing allows a stable distribution tree in
              which Path messages from the same sender arrive from more
              than one PHOP, and RSVP must be prepared to maintain all
              such path state.  The RSVP rules for handling this
              situation are contained in Section 3.9.  RSVP must not
              forward (according to the rules of Section 3.9) Path
              messages that arrive on an incoming interface different
              from that provided by routing.

         o    Unicast Sessions

              For a short period following a unicast route change
              upstream, a node may receive Path messages from multiple
              PHOPs for a given (session, sender) pair.  The node cannot
              reliably determine which is the right PHOP, although the
              node will receive data from only one of the PHOPs at a
              time.  One implementation choice for RSVP is to ignore
              PHOP in matching unicast past state, and allow the PHOP to
              flip among the candidates.  Another implementation choice
              is to maintain path state for each PHOP and to send Resv
              messages upstream towards all such PHOPs.  In either case,
              the situation is a transient; the unused path state will
              time out or be torn down (because upstream path state
              timed out).

      3.1.4 Resv Messages

         Resv messages carry reservation requests hop-by-hop from
         receivers to senders, along the reverse paths of data flows for
         the session.  The IP destination address of a Resv message is
         the unicast address of a previous-hop node, obtained from the
         path state.  The IP source address is an address of the node
         that sent the message.



Braden, Ed., et. al.        Standards Track                    [Page 38]

RFC 2205                          RSVP                    September 1997


         The Resv message format is as follows:

           <Resv Message> ::= <Common Header> [ <INTEGRITY> ]

                                   <SESSION>  <RSVP_HOP>

                                   <TIME_VALUES>

                                   [ <RESV_CONFIRM> ]  [ <SCOPE> ]

                                   [ <POLICY_DATA> ... ]

                                   <STYLE> <flow descriptor list>

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

                            <flow descriptor list> <flow descriptor>


         If the INTEGRITY object is present, it must immediately follow
         the common header.  The STYLE object followed by the flow
         descriptor list must occur at the end of the message, and
         objects within the flow descriptor list must follow the BNF
         given below.  There are no other requirements on transmission
         order, although the above order is recommended.

         The NHOP (i.e., the RSVP_HOP) object contains the IP address of
         the interface through which the Resv message was sent and the
         LIH for the logical interface on which the reservation is
         required.

         The appearance of a RESV_CONFIRM object signals a request for a
         reservation confirmation and carries the IP address of the
         receiver to which the ResvConf should be sent.  Any number of
         POLICY_DATA objects may appear.

         The BNF above defines a flow descriptor list as simply a list
         of flow descriptors.  The following style-dependent rules
         specify in more detail the composition of a valid flow
         descriptor list for each of the reservation styles.

         o    WF Style:

                <flow descriptor list> ::=  <WF flow descriptor>

                <WF flow descriptor> ::= <FLOWSPEC>





Braden, Ed., et. al.        Standards Track                    [Page 39]

RFC 2205                          RSVP                    September 1997


         o    FF style:

                <flow descriptor list> ::=

                          <FLOWSPEC>  <FILTER_SPEC>  |

                          <flow descriptor list> <FF flow descriptor>

                <FF flow descriptor> ::=

                          [ <FLOWSPEC> ] <FILTER_SPEC>



              Each elementary FF style request is defined by a single
              (FLOWSPEC, FILTER_SPEC) pair, and multiple such requests
              may be packed into the flow descriptor list of a single
              Resv message.  A FLOWSPEC object can be omitted if it is
              identical to the most recent such object that appeared in
              the list; the first FF flow descriptor must contain a
              FLOWSPEC.

         o    SE style:

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

                <SE flow descriptor> ::=

                                       <FLOWSPEC> <filter spec list>

                <filter spec list> ::=  <FILTER_SPEC>

                                  |  <filter spec list> <FILTER_SPEC>


         The reservation scope, i.e., the set of senders towards which a
         particular reservation is to be forwarded (after merging), is
         determined as follows:

         o    Explicit sender selection

              The reservation is forwarded to all senders whose
              SENDER_TEMPLATE objects recorded in the path state match a
              FILTER_SPEC object in the reservation.  This match must
              follow the rules of Section 3.2.






Braden, Ed., et. al.        Standards Track                    [Page 40]

RFC 2205                          RSVP                    September 1997


         o    Wildcard sender selection

              A request with wildcard sender selection will match all
              senders that route to the given outgoing interface.

              Whenever a Resv message with wildcard sender selection is
              forwarded to more than one previous hop, a SCOPE object
              must be included in the message (see Section 3.4 below);
              in this case, the scope for forwarding the reservation is
              constrained to just the sender IP addresses explicitly
              listed in the SCOPE object.

              A Resv message that is forwarded by a node is generally
              the result of merging a set of incoming Resv messages
              (that are not blockaded; see Section 3.5).  If one of
              these merged messages contains a RESV_CONFIRM object and
              has a FLOWSPEC larger than the FLOWSPECs of the other
              merged reservation requests, then this RESV_CONFIRM object
              is forwarded in the outgoing Resv message.  A RESV_CONFIRM
              object in one of the other merged requests (whose
              flowspecs are equal to, smaller than, or incomparable to,
              the merged flowspec, and which is not blockaded) will
              trigger the generation of an ResvConf message containing
              the RESV_CONFIRM.  A RESV_CONFIRM object in a request that
              is blockaded will be neither forwarded nor returned; it
              will be dropped in the current node.

      3.1.5 Path Teardown Messages

         Receipt of a PathTear (path teardown) message deletes matching
         path state.  Matching state must have match the SESSION,
         SENDER_TEMPLATE, and PHOP objects.  In addition, a PathTear
         message for a multicast session can only match path state for
         the incoming interface on which the PathTear arrived.  If there
         is no matching path state, a PathTear message should be
         discarded and not forwarded.

         PathTear messages are initiated explicitly by senders or by
         path state timeout in any node, and they travel downstream
         towards all receivers.  A unicast PathTear must not be
         forwarded if there is path state for the same (session, sender)
         pair but a different PHOP.  Forwarding of multicast PathTear
         messages is governed by the rules of Section 3.9.








Braden, Ed., et. al.        Standards Track                    [Page 41]

RFC 2205                          RSVP                    September 1997


         A PathTear message must be routed exactly like the
         corresponding Path message.  Therefore, its IP destination
         address must be the session DestAddress, and its IP source
         address must be the sender address from the path state being
         torn down.

             <PathTear Message> ::= <Common Header> [ <INTEGRITY> ]

                                         <SESSION> <RSVP_HOP>

                                        [ <sender descriptor> ]

             <sender descriptor> ::= (see earlier definition)


         A PathTear message may include a SENDER_TSPEC or ADSPEC object
         in its sender descriptor, but these must be ignored.  The order
         requirements are as given earlier for a Path message, but the
         above order is recommended.

         Deletion of path state as the result of a PathTear message or a
         timeout must also adjust related reservation state as required
         to maintain consistency in the local node.  The adjustment
         depends upon the reservation style.  For example, suppose a
         PathTear deletes the path state for a sender S.  If the style
         specifies explicit sender selection (FF or SE), any reservation
         with a filter spec matching S should be deleted; if the style
         has wildcard sender selection (WF), the reservation should be
         deleted if S is the last sender to the session.  These
         reservation changes should not trigger an immediate Resv
         refresh message, since the PathTear message has already made
         the required changes upstream.  They should not trigger a
         ResvErr message, since the result could be to generate a shower
         of such messages.

      3.1.6 Resv Teardown Messages

         Receipt of a ResvTear (reservation teardown) message deletes
         matching reservation state.  Matching reservation state must
         match the SESSION, STYLE, and FILTER_SPEC objects as well as
         the LIH in the RSVP_HOP object.  If there is no matching
         reservation state, a ResvTear message should be discarded.  A
         ResvTear message may tear down any subset of the filter specs
         in FF-style or SE-style reservation state.

         ResvTear messages are initiated explicitly by receivers or by
         any node in which reservation state has timed out, and they
         travel upstream towards all matching senders.



Braden, Ed., et. al.        Standards Track                    [Page 42]

RFC 2205                          RSVP                    September 1997


         A ResvTear message must be routed like the corresponding Resv
         message, and its IP destination address will be the unicast
         address of a previous hop.

             <ResvTear Message> ::= <Common Header> [<INTEGRITY>]

                                         <SESSION> <RSVP_HOP>

                                         [ <SCOPE> ] <STYLE>

                                         <flow descriptor list>

             <flow descriptor list> ::= (see earlier definition)


         FLOWSPEC objects in the flow descriptor list of a ResvTear
         message will be ignored and may be omitted.  The order
         requirements for INTEGRITY object, sender descriptor, STYLE
         object, and flow descriptor list are as given earlier for a
         Resv message, but the above order is recommended.  A ResvTear
         message may include a SCOPE object, but it must be ignored.

         A ResvTear message will cease to be forwarded at the node where
         merging would have suppressed forwarding of the corresponding
         Resv message.  Depending upon the resulting state change in a
         node, receipt of a ResvTear message may cause a ResvTear
         message to be forwarded, a modified Resv message to be
         forwarded, or no message to be forwarded.  These three cases
         can be illustrated in the case of the FF-style reservations
         shown in Figure 6.

         o    If receiver R2 sends a ResvTear message for its
              reservation S3{B}, the corresponding reservation is
              removed from interface (d) and a ResvTear for S3{B} is
              forwarded out (b).

         o    If receiver R1 sends a ResvTear for its reservation
              S1{4B}, the corresponding reservation is removed from
              interface (c) and a modified Resv message FF( S1{3B} ) is
              immediately forwarded out (a).

         o    If receiver R3 sends a ResvTear message for S1{B}, there
              is no change in the effective reservation S1{3B} on (d)
              and no message is forwarded.







Braden, Ed., et. al.        Standards Track                    [Page 43]

RFC 2205                          RSVP                    September 1997


      3.1.7 Path Error Messages

         PathErr (path error) messages report errors in processing Path
         messages.  They are travel upstream towards senders and are
         routed hop-by-hop using the path state.  At each hop, the IP
         destination address is the unicast address of a previous hop.
         PathErr messages do not modify the state of any node through
         which they pass; they are only reported to the sender
         application.


           <PathErr message> ::= <Common Header> [ <INTEGRITY> ]

                                      <SESSION> <ERROR_SPEC>

                                      [ <POLICY_DATA> ...]

                                     [ <sender descriptor> ]

           <sender descriptor> ::= (see earlier definition)

         The ERROR_SPEC object specifies the error and includes the IP
         address of the node that detected the error (Error Node
         Address).  One or more POLICY_DATA objects may be included
         message to provide relevant information.  The sender descriptor
         is copied from the message in error.  The object order
         requirements are as given earlier for a Path message, but the
         above order is recommended.

      3.1.8 Resv Error Messages

         ResvErr (reservation error) messages report errors in
         processing Resv messages, or they may report the spontaneous
         disruption of a reservation, e.g., by administrative
         preemption.

         ResvErr messages travel downstream towards the appropriate
         receivers, routed hop-by-hop using the reservation state.  At
         each hop, the IP destination address is the unicast address of
         a next-hop node.











Braden, Ed., et. al.        Standards Track                    [Page 44]

RFC 2205                          RSVP                    September 1997


           <ResvErr Message> ::= <Common Header> [ <INTEGRITY> ]

                                      <SESSION>  <RSVP_HOP>

                                      <ERROR_SPEC>  [ <SCOPE> ]

                                      [ <POLICY_DATA> ...]

                                    <STYLE> [ <error flow descriptor> ]


         The ERROR_SPEC object specifies the error and includes the IP
         address of the node that detected the error (Error Node
         Address).  One or more POLICY_DATA objects may be included in
         an error message to provide relevant information (e.g.,, when a
         policy control error is being reported).  The RSVP_HOP object
         contains the previous hop address, and the STYLE object is
         copied from the Resv message in error.  The use of the SCOPE
         object in a ResvErr message is defined below in Section 3.4.
         The object order requirements are as given for Resv messages,
         but the above order is recommended.

         The following style-dependent rules define the composition of a
         valid error flow descriptor; the object order requirements are
         as given earlier for flow descriptor.

         o    WF Style:

                  <error flow descriptor> ::= <WF flow descriptor>


         o    FF style:

                  <error flow descriptor> ::= <FF flow descriptor>


              Each flow descriptor in a FF-style Resv message must be
              processed independently, and a separate ResvErr message
              must be generated for each one that is in error.

         o    SE style:

                  <error flow descriptor> ::= <SE flow descriptor>

              An SE-style ResvErr message may list the subset of the
              filter specs in the corresponding Resv message to which
              the error applies.




Braden, Ed., et. al.        Standards Track                    [Page 45]

RFC 2205                          RSVP                    September 1997


         Note that a ResvErr message contains only one flow descriptor.
         Therefore, a Resv message that contains N > 1 flow descriptors
         (FF style) may create up to N separate ResvErr messages.

         Generally speaking, a ResvErr message should be forwarded
         towards all receivers that may have caused the error being
         reported.  More specifically:

         o    The node that detects an error in a reservation request
              sends a ResvErr message to the next hop node from which
              the erroneous reservation came.

              This ResvErr message must contain the information required
              to define the error and to route the error message in
              later hops.  It therefore includes an ERROR_SPEC object, a
              copy of the STYLE object, and the appropriate error flow
              descriptor.  If the error is an admission control failure
              while attempting to increase an existing reservation, then
              the existing reservation must be left in place and the
              InPlace flag bit must be on in the ERROR_SPEC of the
              ResvErr message.

         o    Succeeding nodes forward the ResvErr message to next hops
              that have local reservation state.  For reservations with
              wildcard scope, there is an additional limitation on
              forwarding ResvErr messages, to avoid loops; see Section
              3.4.  There is also a rule restricting the forwarding of a
              Resv message after an Admission Control failure; see
              Section 3.5.

              A ResvErr message that is forwarded should carry the
              FILTER_SPEC(s) from the corresponding reservation state.

         o    When a ResvErr message reaches a receiver, the STYLE
              object, flow descriptor list, and ERROR_SPEC object
              (including its flags) should be delivered to the receiver
              application.

      3.1.9 Confirmation Messages

         ResvConf messages are sent to (probabilistically) acknowledge
         reservation requests.  A ResvConf message is sent as the result
         of the appearance of a RESV_CONFIRM object in a Resv message.








Braden, Ed., et. al.        Standards Track                    [Page 46]

RFC 2205                          RSVP                    September 1997


         A ResvConf message is sent to the unicast address of a receiver
         host; the address is obtained from the RESV_CONFIRM object.
         However, a ResvConf message is forwarded to the receiver hop-
         by-hop, to accommodate the hop-by-hop integrity check
         mechanism.

           <ResvConf message> ::= <Common Header> [ <INTEGRITY> ]

                                      <SESSION> <ERROR_SPEC>

                                      <RESV_CONFIRM>

                                      <STYLE> <flow descriptor list>

           <flow descriptor list> ::= (see earlier definition)


         The object order requirements are the same as those given
         earlier for a Resv message, but the above order is recommended.

         The RESV_CONFIRM object is a copy of that object in the Resv
         message that triggered the confirmation.  The ERROR_SPEC is
         used only to carry the IP address of the originating node, in
         the Error Node Address; the Error Code and Value are zero to
         indicate a confirmation.  The flow descriptor list specifies
         the particular reservations that are being confirmed; it may be
         a subset of flow descriptor list of the Resv that requested the
         confirmation.

   3.2 Port Usage

      An RSVP session is normally defined by the triple: (DestAddress,
      ProtocolId, DstPort).  Here DstPort is a UDP/TCP destination port
      field (i.e., a 16-bit quantity carried at octet offset +2 in the
      transport header).  DstPort may be omitted (set to zero) if the
      ProtocolId specifies a protocol that does not have a destination
      port field in the format used by UDP and TCP.

      RSVP allows any value for ProtocolId.  However, end-system
      implementations of RSVP may know about certain values for this
      field, and in particular the values for UDP and TCP (17 and 6,
      respectively).  An end system may give an error to an application
      that either:

      o    specifies a non-zero DstPort for a protocol that does not
           have UDP/TCP-like ports, or





Braden, Ed., et. al.        Standards Track                    [Page 47]

RFC 2205                          RSVP                    September 1997


      o    specifies a zero DstPort for a protocol that does have
           UDP/TCP-like ports.

      Filter specs and sender templates specify the pair: (SrcAddress,
      SrcPort), where SrcPort is a UDP/TCP source port field (i.e., a
      16-bit quantity carried at octet offset +0 in the transport
      header).   SrcPort may be omitted (set to zero) in certain cases.

      The following rules hold for the use of zero DstPort and/or
      SrcPort fields in RSVP.

      1.   Destination ports must be consistent.

           Path state and reservation state for the same DestAddress and
           ProtocolId must each have DstPort values that are all zero or
           all non-zero.  Violation of this condition in a node is a
           "Conflicting Dest Ports" error.

      2.   Destination ports rule.

           If DstPort in a session definition is zero, all SrcPort
           fields used for that session must also be zero.  The
           assumption here is that the protocol does not have UDP/TCP-
           like ports.   Violation of this condition in a node is a "Bad
           Src Ports" error.

      3.   Source Ports must be consistent.

           A sender host must not send path state both with and without
           a zero SrcPort.  Violation of this condition is a
           "Conflicting Sender Port" error.

      Note that RSVP has no "wildcard" ports, i.e., a zero port cannot
      match a non-zero port.

   3.3 Sending RSVP Messages

      RSVP messages are sent hop-by-hop between RSVP-capable routers as
      "raw" IP datagrams with protocol number 46.  Raw IP datagrams are
      also intended to be used between an end system and the first/last
      hop router, although it is also possible to encapsulate RSVP
      messages as UDP datagrams for end-system communication, as
      described in Appendix C.  UDP encapsulation is needed for systems
      that cannot do raw network I/O.







Braden, Ed., et. al.        Standards Track                    [Page 48]

RFC 2205                          RSVP                    September 1997


      Path, PathTear, and ResvConf messages must be sent with the Router
      Alert IP option [RFC 2113] in their IP headers.  This option may
      be used in the fast forwarding path of a high-speed router to
      detect datagrams that require special processing.

      Upon the arrival of an RSVP message M that changes the state, a
      node must forward the state modification immediately.  However,
      this must not trigger sending a message out the interface through
      which M arrived (which could happen if the implementation simply
      triggered an immediate refresh of all state for the session).
      This rule is necessary to prevent packet storms on broadcast LANs.

      In this version of the spec, each RSVP message must occupy exactly
      one IP datagram.  If it exceeds the MTU, such a datagram will be
      fragmented by IP and reassembled at the recipient node.  This has
      several consequences:

      o    A single RSVP message may not exceed the maximum IP datagram
           size, approximately 64K bytes.

      o    A congested non-RSVP cloud could lose individual message
           fragments, and any lost fragment will lose the entire
           message.

      Future versions of the protocol will provide solutions for these
      problems if they prove burdensome.  The most likely direction will
      be to perform "semantic fragmentation", i.e., break the path or
      reservation state being transmitted into multiple self-contained
      messages, each of an acceptable size.

      RSVP uses its periodic refresh mechanisms to recover from
      occasional packet losses.  Under network overload, however,
      substantial losses of RSVP messages could cause a failure of
      resource reservations.  To control the queuing delay and dropping
      of RSVP packets, routers should be configured to offer them a
      preferred class of service.  If RSVP packets experience noticeable
      losses when crossing a congested non-RSVP cloud, a larger value
      can be used for the timeout factor K (see section 3.7).

      Some multicast routing protocols provide for "multicast tunnels",
      which do IP encapsulation of multicast packets for transmission
      through routers that do not have multicast capability.  A
      multicast tunnel looks like a logical outgoing interface that is
      mapped into some physical interface.  A multicast routing protocol
      that supports tunnels will describe a route using a list of
      logical rather than physical interfaces.  RSVP can operate across
      such multicast tunnels in the following manner:




Braden, Ed., et. al.        Standards Track                    [Page 49]

RFC 2205                          RSVP                    September 1997


      1.   When a node N forwards a Path message out a logical outgoing
           interface L, it includes in the message some encoding of the
           identity of L, called the "logical interface handle" or LIH.
           The LIH value is carried in the RSVP_HOP object.

      2.   The next hop node N' stores the LIH value in its path state.

      3.   When N' sends a Resv message to N, it includes the LIH value
           from the path state (again, in the RSVP_HOP object).

      4.   When the Resv message arrives at N, its LIH value provides
           the information necessary to attach the reservation to the
           appropriate logical interface.  Note that N creates and
           interprets the LIH; it is an opaque value to N'.

      Note that this only solves the routing problem posed by tunnels.
      The tunnel appears to RSVP as a non-RSVP cloud.  To establish RSVP
      reservations within the tunnel, additional machinery will be
      required, to be defined in the future.

   3.4 Avoiding RSVP Message Loops

      Forwarding of RSVP messages must avoid looping.  In steady state,
      Path and Resv messages are forwarded on each hop only once per
      refresh period.  This avoids looping packets, but there is still
      the possibility of an "auto-refresh" loop, clocked by the refresh
      period.  Such auto-refresh loops keep state active "forever", even
      if the end nodes have ceased refreshing it, until the receivers
      leave the multicast group and/or the senders stop sending Path
      messages.  On the other hand, error and teardown messages are
      forwarded immediately and are therefore subject to direct looping.

      Consider each message type.

      o    Path Messages

           Path messages are forwarded in exactly the same way as IP
           data packets.  Therefore there should be no loops of Path
           messages (except perhaps for transient routing loops, which
           we ignore here), even in a topology with cycles.

      o    PathTear Messages

           PathTear messages use the same routing as Path messages and
           therefore cannot loop.






Braden, Ed., et. al.        Standards Track                    [Page 50]

RFC 2205                          RSVP                    September 1997


      o    PathErr Messages

           Since Path messages do not loop, they create path state
           defining a loop-free reverse path to each sender.  PathErr
           messages are always directed to particular senders and
           therefore cannot loop.

      o    Resv Messages

           Resv messages directed to particular senders (i.e., with
           explicit sender selection) cannot loop.  However, Resv
           messages with wildcard sender selection (WF style) have a
           potential for auto-refresh looping.

      o    ResvTear Messages

           Although ResvTear messages are routed the same as Resv
           messages, during the second pass around a loop there will be
           no state so any ResvTear message will be dropped.  Hence
           there is no looping problem here.

      o    ResvErr Messages

           ResvErr messages for WF style reservations may loop for
           essentially the same reasons that Resv messages loop.

      o    ResvConf Messages

           ResvConf messages are forwarded towards a fixed unicast
           receiver address and cannot loop.

      If the topology has no loops, then looping of Resv and ResvErr
      messages with wildcard sender selection can be avoided by simply
      enforcing the rule given earlier: state that is received through a
      particular interface must never be forwarded out the same
      interface.  However, when the topology does have cycles, further
      effort is needed to prevent auto-refresh loops of wildcard Resv
      messages and fast loops of wildcard ResvErr messages.  The
      solution to this problem adopted by this protocol specification is
      for such messages to carry an explicit sender address list in a
      SCOPE object.










Braden, Ed., et. al.        Standards Track                    [Page 51]

RFC 2205                          RSVP                    September 1997


      When a Resv message with WF style is to be forwarded to a
      particular previous hop, a new SCOPE object is computed from the
      SCOPE objects that were received in matching Resv messages.  If
      the computed SCOPE object is empty, the message is not forwarded
      to the previous hop; otherwise, the message is sent containing the
      new SCOPE object.  The rules for computing a new SCOPE object for
      a Resv message are as follows:

      1.   The union is formed of the sets of sender IP addresses listed
           in all SCOPE objects in the reservation state for the given
           session.

           If reservation state from some NHOP does not contain a SCOPE
           object, a substitute sender list must be created and included
           in the union.  For a message that arrived on outgoing
           interface OI, the substitute list is the set of senders that
           route to OI.

      2.   Any local senders (i.e., any sender applications on this
           node) are removed from this set.

      3.   If the SCOPE object is to be sent to PHOP, remove from the
           set any senders that did not come from PHOP.

      Figure 11 shows an example of wildcard-scoped (WF style) Resv
      messages.  The address lists within SCOPE objects are shown in
      square brackets.  Note that there may be additional connections
      among the nodes, creating looping topology that is not shown.























Braden, Ed., et. al.        Standards Track                    [Page 52]

RFC 2205                          RSVP                    September 1997



                         ________________
                      a |                | c
           R4, S4<----->|     Router     |<-----> R2, S2, S3
                        |                |
                      b |                |
           R1, S1<----->|                |
                        |________________|

          Send on (a):           |    Receive on (c):
                                 |
             <-- WF( [S4] )      |       <-- WF( [S4, S1])
                                 |
          Send on (b):           |
                                 |
             <-- WF( [S1] )      |
                                 |
          Receive on (a):        |    Send on (c):
                                 |
             WF( [S1,S2,S3]) --> |       WF( [S2, S3]) -->
                                 |
          Receive on (b):        |
                                 |
             WF( [S2,S3,S4]) --> |
                                 |

           Figure 11: SCOPE Objects in Wildcard-Scope Reservations


      SCOPE objects are not necessary if the multicast routing uses
      shared trees or if the reservation style has explicit sender
      selection.  Furthermore, attaching a SCOPE object to a reservation
      should be deferred to a node which has more than one previous hop
      for the reservation state.

      The following rules are used for SCOPE objects in ResvErr messages
      with WF style:

      1.   The node that detected the error initiates an ResvErr message
           containing a copy of the SCOPE object associated with the
           reservation state or message in error.

      2.   Suppose a wildcard-style ResvErr message arrives at a node
           with a SCOPE object containing the sender host address list
           L.  The node forwards the ResvErr message using the rules of
           Section 3.1.8.  However,





Braden, Ed., et. al.        Standards Track                    [Page 53]

RFC 2205                          RSVP                    September 1997


           the ResvErr message forwarded out OI must contain a SCOPE
           object derived from L by including only those senders that
           route to OI.  If this SCOPE object is empty, the ResvErr
           message should not be sent out OI.

   3.5 Blockade State

      The basic rule for creating a Resv refresh message is to merge the
      flowspecs of the reservation requests in place in the node, by
      computing their LUB.  However, this rule is modified by the
      existence of "blockade state" resulting from ResvErr messages, to
      solve the KR-II problem (see Section 2.5).  The blockade state
      also enters into the routing of ResvErr messages for Admission
      Control failure.

      When a ResvErr message for an Admission Control failure is
      received, its flowspec Qe is used to create or refresh an element
      of local blockade state.  Each element of blockade state consists
      of a blockade flowspec Qb taken from the flowspec of the ResvErr
      message, and an associated blockade timer Tb.  When a blockade
      timer expires, the corresponding blockade state is deleted.

      The granularity of blockade state depends upon the style of the
      ResvErr message that created it.  For an explicit style, there may
      be a blockade state element (Qb(S),Tb(S)) for each sender S.  For
      a wildcard style, blockade state is per previous hop P.

      An element of blockade state with flowspec Qb is said to
      "blockade" a reservation with flowspec Qi if Qb is not (strictly)
      greater than Qi.  For example, suppose that the LUB of two
      flowspecs is computed by taking the max of each of their
      corresponding components.  Then Qb blockades Qi if for some
      component j, Qb[j] <= Qi[j].

      Suppose that a node receives a ResvErr message from previous hop P
      (or, if style is explicit, sender S) as the result of an Admission
      Control failure upstream.  Then:

      1.   An element of blockade state is created for P (or S) if it
           did not exist.

      2.   Qb(P) (or Qb(S)) is set equal to the flowspec Qe from the
           ResvErr message.

      3.   A corresponding blockade timer Tb(P) (or Tb(S)) is started or
           restarted for a time Kb*R.  Here Kb is a fixed multiplier and
           R is the refresh interval for reservation state.  Kb should
           be configurable.



Braden, Ed., et. al.        Standards Track                    [Page 54]

RFC 2205                          RSVP                    September 1997


      4.   If there is some local reservation state that is not
           blockaded (see below), an immediate reservation refresh for P
           (or S) is generated.

      5.   The ResvErr message is forwarded to next hops in the
           following way.  If the InPlace bit is off, the ResvErr
           message is forwarded to all next hops for which there is
           reservation state.  If the InPlace bit is on, the ResvErr
           message is forwarded only to the next hops whose Qi is
           blockaded by Qb.

      Finally, we present the modified rule for merging flowspecs to
      create a reservation refresh message.

      o    If there are any local reservation requests Qi that are not
           blockaded, these are merged by computing their LUB.  The
           blockaded reservations are ignored; this allows forwarding of
           a smaller reservation that has not failed and may perhaps
           succeed, after a larger reservation fails.

      o    Otherwise (all local requests Qi are blockaded), they are
           merged by taking the GLB (Greatest Lower Bound) of the Qi's.

           (The use of some definition of "minimum" improves performance
           by bracketing the failure level between the largest that
           succeeds and the smallest that fails.  The choice of GLB in
           particular was made because it is simple to define and
           implement, and no reason is known for using a different
           definition of "minimum" here).

      This refresh merging algorithm is applied separately to each flow
      (each sender or PHOP) contributing to a shared reservation (WF or
      SE style).

      Figure 12 shows an example of the the application of blockade
      state for a shared reservation (WF style).  There are two previous
      hops labeled (a) and (b), and two next hops labeled (c) and (d).
      The larger reservation 4B arrived from (c) first, but it failed
      somewhere upstream via PHOP (a), but not via PHOP (b).  The
      figures show the final "steady state" after the smaller
      reservation 2B subsequently arrived from (d).  This steady state
      is perturbed roughly every Kb*R seconds, when the blockade state
      times out.  The next refresh then sends 4B to previous hop (a);
      presumably this will fail, sending a ResvErr message that will
      re-establish the blockade state, returning to the situation shown
      in the figure.  At the same time, the ResvErr message will be
      forwarded to next hop (c) and to all receivers downstream
      responsible for the 4B reservations.



Braden, Ed., et. al.        Standards Track                    [Page 55]

RFC 2205                          RSVP                    September 1997



               Send     Blockade |   Reserve       Receive
                       State {Qb}|
                                 |   ________
        (a) <- WF(*{2B})    {4B} |  | * {4B} | WF(*{4B}) <- (c)
                                 |  |________|
                                 |
      ---------------------------|-------------------------------
                                 |
                                 |   ________
        (b) <- WF(*{4B})   (none)|  | * {2B} | WF(*{2B}) <- (d)
                                 |  |________|


                   Figure 12: Blockading with Shared Style



   3.6 Local Repair

      When a route changes, the next Path or Resv refresh message will
      establish path or reservation state (respectively) along the new
      route.  To provide fast adaptation to routing changes without the
      overhead of short refresh periods, the local routing protocol
      module can notify the RSVP process of route changes for particular
      destinations.  The RSVP process should use this information to
      trigger a quick refresh of state for these destinations, using the
      new route.

      The specific rules are as follows:

      o    When routing detects a change of the set of outgoing
           interfaces for destination G, RSVP should update the path
           state, wait for a short period W, and then send Path
           refreshes for all sessions G/* (i.e., for any session with
           destination G, regardless of destination port).

           The short wait period before sending Path refreshes is to
           allow the routing protocol to settle, and the value for W
           should be chosen accordingly.  Currently W = 2 sec is
           suggested; however, this value should be configurable per
           interface.

      o    When a Path message arrives with a Previous Hop address that
           differs from the one stored in the path state, RSVP should
           send immediate Resv refreshes to that PHOP.





Braden, Ed., et. al.        Standards Track                    [Page 56]

RFC 2205                          RSVP                    September 1997


   3.7 Time Parameters

      There are two time parameters relevant to each element of RSVP
      path or reservation state in a node: the refresh period R between
      generation of successive refreshes for the state by the neighbor
      node, and the local state's lifetime L.  Each RSVP Resv or Path
      message may contain a TIME_VALUES object specifying the R value
      that was used to generate this (refresh) message.  This R value is
      then used to determine the value for L when the state is received
      and stored.  The values for R and L may vary from hop to hop.

      In more detail:

      1.   Floyd and Jacobson [FJ94] have shown that periodic messages
           generated by independent network nodes can become
           synchronized.  This can lead to disruption in network
           services as the periodic messages contend with other network
           traffic for link and forwarding resources.  Since RSVP sends
           periodic refresh messages, it must avoid message
           synchronization and ensure that any synchronization that may
           occur is not stable.

           For this reason, the refresh timer should be randomly set to
           a value in the range [0.5R, 1.5R].

      2.   To avoid premature loss of state, L must satisfy L >= (K +
           0.5)*1.5*R, where K is a small integer.  Then in the worst
           case, K-1 successive messages may be lost without state being
           deleted.  To compute a lifetime L for a collection of state
           with different R values R0, R1, ..., replace R by max(Ri).

           Currently K = 3 is suggested as the default.  However, it may
           be necessary to set a larger K value for hops with high loss
           rate.  K may be set either by manual configuration per
           interface, or by some adaptive technique that has not yet
           been specified.

      3.   Each Path or Resv message carries a TIME_VALUES object
           containing the refresh time R used to generate refreshes.
           The recipient node uses this R to determine the lifetime L of
           the stored state created or refreshed by the message.

      4.   The refresh time R is chosen locally by each node.  If the
           node does not implement local repair of reservations
           disrupted by route changes, a smaller R speeds up adaptation
           to routing changes, while increasing the RSVP overhead.  With
           local repair, a router can be more relaxed about R since the
           periodic refresh becomes only a backstop robustness



Braden, Ed., et. al.        Standards Track                    [Page 57]

RFC 2205                          RSVP                    September 1997


           mechanism.  A node may therefore adjust the effective R
           dynamically to control the amount of overhead due to refresh
           messages.

           The current suggested default for R is 30 seconds.  However,
           the default value Rdef should be configurable per interface.

      5.   When R is changed dynamically, there is a limit on how fast
           it may increase.  Specifically, the ratio of two successive
           values R2/R1 must not exceed 1 + Slew.Max.

           Currently, Slew.Max is 0.30.  With K = 3, one packet may be
           lost without state timeout while R is increasing 30 percent
           per refresh cycle.

      6.   To improve robustness, a node may temporarily send refreshes
           more often than R after a state change (including initial
           state establishment).

      7.   The values of Rdef, K, and Slew.Max used in an implementation
           should be easily modifiable per interface, as experience may
           lead to different values.  The possibility of dynamically
           adapting K and/or Slew.Max in response to measured loss rates
           is for future study.

   3.8 Traffic Policing and Non-Integrated Service Hops

      Some QoS services may require traffic policing at some or all of
      (1) the edge of the network, (2) a merging point for data from
      multiple senders, and/or (3) a branch point where traffic flow
      from upstream may be greater than the downstream reservation being
      requested.  RSVP knows where such points occur and must so
      indicate to the traffic control mechanism.  On the other hand,
      RSVP does not interpret the service embodied in the flowspec and
      therefore does not know whether policing will actually be applied
      in any particular case.

      The RSVP process passes to traffic control a separate policing
      flag for each of these three situations.

      o    E_Police_Flag -- Entry Policing

           This flag is set in the first-hop RSVP node that implements
           traffic control (and is therefore capable of policing).

           For example, sender hosts must implement RSVP but currently
           many of them do not implement traffic control.  In this case,
           the E_Police_Flag should be off in the sender host, and it



Braden, Ed., et. al.        Standards Track                    [Page 58]

RFC 2205                          RSVP                    September 1997


           should only be set on when the first node capable of traffic
           control is reached.  This is controlled by the E_Police flag
           in SESSION objects.

      o    M_Police_Flag -- Merge Policing

           This flag should be set on for a reservation using a shared
           style (WF or SE) when flows from more than one sender are
           being merged.

      o    B_Police_Flag -- Branch Policing

           This flag should be set on when the flowspec being installed
           is smaller than, or incomparable to, a FLOWSPEC in place on
           any other interface, for the same FILTER_SPEC and SESSION.

      RSVP must also test for the presence of non-RSVP hops in the path
      and pass this information to traffic control.  From this flag bit
      that the RSVP process supplies and from its own local knowledge,
      traffic control can detect the presence of a hop in the path that
      is not capable of QoS control, and it passes this information to
      the receivers in Adspecs [RFC 2210].

      With normal IP forwarding, RSVP can detect a non-RSVP hop by
      comparing the IP TTL with which a Path message is sent to the TTL
      with which it is received; for this purpose, the transmission TTL
      is placed in the common header.  However, the TTL is not always a
      reliable indicator of non-RSVP hops, and other means must
      sometimes be used.  For example, if the routing protocol uses IP
      encapsulating tunnels, then the routing protocol must inform RSVP
      when non-RSVP hops are included.  If no automatic mechanism will
      work, manual configuration will be required.

   3.9 Multihomed Hosts

      Accommodating multihomed hosts requires some special rules in
      RSVP.  We use the term `multihomed host' to cover both hosts (end
      systems) with more than one network interface and routers that are
      supporting local application programs.

      An application executing on a multihomed host may explicitly
      specify which interface any given flow will use for sending and/or
      for receiving data packets, to override the system-specified
      default interface.  The RSVP process must be aware of the default,
      and if an application sets a specific interface, it must also pass
      that information to RSVP.





Braden, Ed., et. al.        Standards Track                    [Page 59]

RFC 2205                          RSVP                    September 1997


      o    Sending Data

           A sender application uses an API call (SENDER in Section
           3.11.1) to declare to RSVP the characteristics of the data
           flow it will originate.  This call may optionally include the
           local IP address of the sender. If it is set by the
           application, this parameter must be the interface address for
           sending the data packets; otherwise, the system default
           interface is implied.

           The RSVP process on the host then sends Path messages for
           this application out the specified interface (only).

      o    Making Reservations

           A receiver application uses an API call (RESERVE in Section
           3.11.1) to request a reservation from RSVP.  This call may
           optionally include the local IP address of the receiver,
           i.e., the interface address for receiving data packets.  In
           the case of multicast sessions, this is the interface on
           which the group has been joined.  If the parameter is
           omitted, the system default interface is used.

           In general, the RSVP process should send Resv messages for an
           application out the specified interface.  However, when the
           application is executing on a router and the session is
           multicast, a more complex situation arises.   Suppose in this
           case that a receiver application joins the group on an
           interface Iapp that differs from Isp, the shortest-path
           interface to the sender.  Then there are two possible ways
           for multicast routing to deliver data packets to the
           application.  The RSVP process must determine which case
           holds by examining the path state, to decide which incoming
           interface to use for sending Resv messages.

           1.   The multicast routing protocol may create a separate
                branch of the multicast distribution `tree' to deliver
                to Iapp.  In this case, there will be path state for
                both interfaces Isp and Iapp.  The path state on Iapp
                should only match a reservation from the local
                application; it must be marked "Local_only" by the RSVP
                process.  If "Local_only" path state for Iapp exists,
                the Resv message should be sent out Iapp.

                Note that it is possible for the path state blocks for
                Isp and Iapp to have the same next hop, if there is an
                intervening non-RSVP cloud.




Braden, Ed., et. al.        Standards Track                    [Page 60]

RFC 2205                          RSVP                    September 1997


           2.   The multicast routing protocol may forward data within
                the router from Isp to Iapp.  In this case, Iapp will
                appear in the list of outgoing interfaces of the path
                state for Isp, and the Resv message should be sent out
                Isp.

           3.   When Path and PathTear messages are forwarded, path
                state marked "Local_Only" must be ignored.

   3.10 Future Compatibility

      We may expect that in the future new object C-Types will be
      defined for existing object classes, and perhaps new object
      classes will be defined.  It will be desirable to employ such new
      objects within the Internet using older implementations that do
      not recognize them.  Unfortunately, this is only possible to a
      limited degree with reasonable complexity.  The rules are as
      follows (`b' represents a bit).

      1.   Unknown Class

           There are three possible ways that an RSVP implementation can
           treat an object with unknown class.  This choice is
           determined by the two high-order bits of the Class-Num octet,
           as follows.

           o    Class-Num = 0bbbbbbb

                The entire message should be rejected and an "Unknown
                Object Class" error returned.

           o    Class-Num = 10bbbbbb

                The node should ignore the object, neither forwarding it
                nor sending an error message.

           o    Class-Num = 11bbbbbb

                The node should ignore the object but forward it,
                unexamined and unmodified, in all messages resulting
                from this message.

           The following more detailed rules hold for unknown-class
           objects with a Class-Num of the form 11bbbbbb:

           1.   Such unknown-class objects received in PathTear,
                ResvTear, PathErr, or ResvErr messages should be
                forwarded immediately in the same messages.



Braden, Ed., et. al.        Standards Track                    [Page 61]

RFC 2205                          RSVP                    September 1997


           2.   Such unknown-class objects received in Path or Resv
                messages should be saved with the corresponding state
                and forwarded in any refresh message resulting from that
                state.

           3.   When a Resv refresh is generated by merging multiple
                reservation requests, the refresh message should include
                the union of unknown-class objects from the component
                requests.  Only one copy of each unique unknown-class
                object should be included in this union.

           4.   The original order of such unknown-class objects need
                not be retained; however, the message that is forwarded
                must obey the general order requirements for its message
                type.

           Although objects with unknown class cannot be merged, these
           rules will forward such objects until they reach a node that
           knows how to merge them.  Forwarding objects with unknown
           class enables incremental deployment of new objects; however,
           the scaling limitations of doing so must be carefully
           examined before a new object class is deployed with both high
           bits on.

      2.   Unknown C-Type for Known Class

           One might expect the known Class-Num to provide information
           that could allow intelligent handling of such an object.
           However, in practice such class-dependent handling is
           complex, and in many cases it is not useful.

           Generally, the appearance of an object with unknown C-Type
           should result in rejection of the entire message and
           generation of an error message (ResvErr or PathErr as
           appropriate).  The error message will include the Class-Num
           and C-Type that failed (see Appendix B); the end system that
           originated the failed message may be able to use this
           information to retry the request using a different C-Type
           object, repeating this process until it runs out of
           alternatives or succeeds.

           Objects of certain classes (FLOWSPEC, ADSPEC, and
           POLICY_DATA) are opaque to RSVP, which simply hands them to
           traffic control or policy modules.  Depending upon its
           internal rules, either of the latter modules may reject a C-
           Type and inform the RSVP process; RSVP should then reject the
           message and send an error, as described in the previous
           paragraph.



Braden, Ed., et. al.        Standards Track                    [Page 62]

RFC 2205                          RSVP                    September 1997


   3.11 RSVP Interfaces

      RSVP on a router has interfaces to routing and to traffic control.
      RSVP on a host has an interface to applications (i.e, an API) and
      also an interface to traffic control (if it exists on the host).

      3.11.1 Application/RSVP Interface

         This section describes a generic interface between an
         application and an RSVP control process.  The details of a real
         interface may be operating-system dependent; the following can
         only suggest the basic functions to be performed.  Some of
         these calls cause information to be returned asynchronously.

         o    Register Session

              Call: SESSION( DestAddress , ProtocolId, DstPort

                         [ , SESSION_object ]

                         [ , Upcall_Proc_addr ] )  -> Session-id


              This call initiates RSVP processing for a session, defined
              by DestAddress together with ProtocolId and possibly a
              port number DstPort.  If successful, the SESSION call
              returns immediately with a local session identifier
              Session-id, which may be used in subsequent calls.

              The Upcall_Proc_addr parameter defines the address of an
              upcall procedure to receive asynchronous error or event
              notification; see below.  The SESSION_object parameter is
              included as an escape mechanism to support some more
              general definition of the session ("generalized
              destination port"), should that be necessary in the
              future.  Normally SESSION_object will be omitted.

         o    Define Sender

              Call: SENDER( Session-id

                         [ , Source_Address ]  [ , Source_Port ]

                         [ , Sender_Template ]

                         [ , Sender_Tspec ]    [ , Adspec ]

                         [ , Data_TTL ]        [ , Policy_data ] )



Braden, Ed., et. al.        Standards Track                    [Page 63]

RFC 2205                          RSVP                    September 1997


              A sender uses this call to define, or to modify the
              definition of, the attributes of the data flow.  The first
              SENDER call for the session registered as `Session-id'
              will cause RSVP to begin sending Path messages for this
              session; later calls will modify the path information.

              The SENDER parameters are interpreted as follows:

              -    Source_Address

                   This is the address of the interface from which the
                   data will be sent.  If it is omitted, a default
                   interface will be used.  This parameter is needed
                   only on a multihomed sender host.

              -    Source_Port

                   This is the UDP/TCP port from which the data will be
                   sent.

              -    Sender_Template

                   This parameter is included as an escape mechanism to
                   support a more general definition of the sender
                   ("generalized source port").  Normally this parameter
                   may be omitted.

              -    Sender_Tspec

                   This parameter describes the traffic flow to be sent;
                   see [RFC 2210].

              -    Adspec

                   This parameter may be specified to initialize the
                   computation of QoS properties along the path; see
                   [RFC 2210].

              -    Data_TTL

                   This is the (non-default) IP Time-To-Live parameter
                   that is being supplied on the data packets.  It is
                   needed to ensure that Path messages do not have a
                   scope larger than multicast data packets.







Braden, Ed., et. al.        Standards Track                    [Page 64]

RFC 2205                          RSVP                    September 1997


              -    Policy_data

                   This optional parameter passes policy data for the
                   sender.  This data may be supplied by a system
                   service, with the application treating it as opaque.

         o    Reserve

              Call: RESERVE( session-id, [ receiver_address , ]

                        [ CONF_flag, ] [ Policy_data, ]

                         style, style-dependent-parms )


              A receiver uses this call to make or to modify a resource
              reservation for the session registered as `session-id'.
              The first RESERVE call will initiate the periodic
              transmission of Resv messages.  A later RESERVE call may
              be given to modify the parameters of the earlier call (but
              note that changing existing reservations may result in
              admission control failures).

              The optional `receiver_address' parameter may be used by a
              receiver on a multihomed host (or router); it is the IP
              address of one of the node's interfaces.  The CONF_flag
              should be set on if a reservation confirmation is desired,
              off otherwise.  The `Policy_data' parameter specifies
              policy data for the receiver, while the `style' parameter
              indicates the reservation style.  The rest of the
              parameters depend upon the style; generally these will be
              appropriate flowspecs and filter specs.

              The RESERVE call returns immediately.  Following a RESERVE
              call, an asynchronous ERROR/EVENT upcall may occur at any
              time.

         o    Release

              Call: RELEASE( session-id )

              This call removes RSVP state for the session specified by
              session-id.  The node then sends appropriate teardown
              messages and ceases sending refreshes for this session-id.







Braden, Ed., et. al.        Standards Track                    [Page 65]

RFC 2205                          RSVP                    September 1997


         o    Error/Event Upcalls

              The general form of a upcall is as follows:

              Upcall: <Upcall_Proc>( ) -> session-id, Info_type,

                            information_parameters


              Here "Upcall_Proc" represents the upcall procedure whose
              address was supplied in the SESSION call.  This upcall may
              occur asynchronously at any time after a SESSION call and
              before a RELEASE call, to indicate an error or an event.

              Currently there are five upcall types, distinguished by
              the Info_type parameter.  The selection of information
              parameters depends upon the type.

              1.   Info_type = PATH_EVENT

                   A Path Event upcall results from receipt of the first
                   Path message for this session, indicating to a
                   receiver application that there is at least one
                   active sender, or if the path state changes.

                   Upcall: <Upcall_Proc>( ) -> session-id,

                               Info_type=PATH_EVENT,

                               Sender_Tspec, Sender_Template

                               [ , Adspec ] [ , Policy_data ]


                   This upcall presents the Sender_Tspec, the
                   Sender_Template, the Adspec, and any policy data from
                   a Path message.

              2.   Info_type = RESV_EVENT

                   A Resv Event upcall is triggered by the receipt of
                   the first RESV message, or by modification of a
                   previous reservation state, for this session.








Braden, Ed., et. al.        Standards Track                    [Page 66]

RFC 2205                          RSVP                    September 1997


                   Upcall: <Upcall_Proc>( ) -> session-id,

                               Info_type=RESV_EVENT,

                               Style, Flowspec, Filter_Spec_list

                               [ , Policy_data ]


                   Here `Flowspec' will be the effective QoS that has
                   been received.  Note that an FF-style Resv message
                   may result in multiple RESV_EVENT upcalls, one for
                   each flow descriptor.

              3.   Info_type = PATH_ERROR

                   An Path Error event indicates an error in sender
                   information that was specified in a SENDER call.

                   Upcall: <Upcall_Proc>( ) -> session-id,

                                 Info_type=PATH_ERROR,

                                 Error_code , Error_value ,

                                 Error_Node , Sender_Template

                                 [ , Policy_data_list ]


                   The Error_code parameter will define the error, and
                   Error_value may supply some additional (perhaps
                   system-specific) data about the error.  The
                   Error_Node parameter will specify the IP address of
                   the node that detected the error.  The
                   Policy_data_list parameter, if present, will contain
                   any POLICY_DATA objects from the failed Path message.

              4.   Info_type = RESV_ERR

                   An Resv Error event indicates an error in a
                   reservation message to which this application
                   contributed.

                   Upcall: <Upcall_Proc>( ) -> session-id,

                                 Info_type=RESV_ERROR,




Braden, Ed., et. al.        Standards Track                    [Page 67]

RFC 2205                          RSVP                    September 1997


                                 Error_code , Error_value ,

                                 Error_Node , Error_flags ,

                                 Flowspec, Filter_spec_list

                                 [ , Policy_data_list ]


                   The Error_code parameter will define the error and
                   Error_value may supply some additional (perhaps
                   system-specific) data.  The Error_Node parameter will
                   specify the IP address of the node that detected the
                   event being reported.

                   There are two Error_flags:

                   -    InPlace

                        This flag may be on for an Admission Control
                        failure, to indicate that there was, and is, a
                        reservation in place at the failure node.  This
                        flag is set at the failure point and forwarded
                        in ResvErr messages.

                   -    NotGuilty

                        This flag may be on for an Admission Control
                        failure, to indicate that the flowspec requested
                        by this receiver was strictly less than the
                        flowspec that got the error.  This flag is set
                        at the receiver API.

                   Filter_spec_list and Flowspec will contain the
                   corresponding objects from the error flow descriptor
                   (see Section 3.1.8).  List_count will specify the
                   number of FILTER_SPECS in Filter_spec_list.  The
                   Policy_data_list parameter will contain any
                   POLICY_DATA objects from the ResvErr message.

              5.   Info_type = RESV_CONFIRM

                   A Confirmation event indicates that a ResvConf
                   message was received.

                   Upcall: <Upcall_Proc>( ) -> session-id,

                                 Info_type=RESV_CONFIRM,



Braden, Ed., et. al.        Standards Track                    [Page 68]

RFC 2205                          RSVP                    September 1997


                                 Style, List_count,

                                 Flowspec, Filter_spec_list

                                 [ , Policy_data ]


                   The parameters are interpreted as in the Resv Error
                   upcall.




              Although RSVP messages indicating path or resv events may
              be received periodically, the API should make the
              corresponding asynchronous upcall to the application only
              on the first occurrence or when the information to be
              reported changes.  All error and confirmation events
              should be reported to the application.


      3.11.2 RSVP/Traffic Control Interface

         It is difficult to present a generic interface to traffic
         control, because the details of establishing a reservation
         depend strongly upon the particular link layer technology in
         use on an interface.

         Merging of RSVP reservations is required because of multicast
         data delivery, which replicates data packets for delivery to
         different next-hop nodes.  At each such replication point, RSVP
         must merge reservation requests from the corresponding next
         hops by computing the "maximum" of their flowspecs.  At a given
         router or host, one or more of the following three replication
         locations may be in use.

         1.   IP layer

              IP multicast forwarding performs replication in the IP
              layer.  In this case, RSVP must merge the reservations
              that are in place on the corresponding outgoing interfaces
              in order to forward a request upstream.

         2.   "The network"

              Replication might take place downstream from the node,
              e.g., in a broadcast LAN, in link-layer switches, or in a
              mesh of non-RSVP-capable routers (see Section 2.8).   In



Braden, Ed., et. al.        Standards Track                    [Page 69]

RFC 2205                          RSVP                    September 1997


              these cases, RSVP must merge the reservations from the
              different next hops in order to make the reservation on
              the single outgoing interface.  It must also merge
              reservations requests from all outgoing interfaces in
              order to forward a request upstream.

         3.   Link-layer driver

              For a multi-access technology, replication may occur in
              the link layer driver or interface card.  For example,
              this case might arise when there is a separate ATM point-
              to-point VC towards each next hop.  RSVP may need to apply
              traffic control independently to each VC, without merging
              requests from different next hops.

         In general, these complexities do not impact the protocol
         processing that is required by RSVP, except to determine
         exactly what reservation requests need to be merged.  It may be
         desirable to organize an RSVP implementation into two parts: a
         core that performs link-layer-independent processing, and a
         link-layer-dependent adaptation layer.  However, we present
         here a generic interface that assumes that replication can
         occur only at the IP layer or in "the network".

         o    Make a Reservation

              Call: TC_AddFlowspec( Interface, TC_Flowspec,

                                TC_Tspec, TC_Adspec, Police_Flags )

                                        -> RHandle [, Fwd_Flowspec]


              The TC_Flowspec parameter defines the desired effective
              QoS to admission control; its value is computed as the
              maximum over the flowspecs of different next hops (see the
              Compare_Flowspecs call below).  The TC_Tspec parameter
              defines the effective sender Tspec Path_Te (see Section
              2.2).  The TC_Adspec parameter defines the effective
              Adspec.  The Police_Flags parameter carries the three
              flags E_Police_Flag, M_Police_Flag, and B_Police_Flag; see
              Section 3.8.

              If this call is successful, it establishes a new
              reservation channel corresponding to RHandle; otherwise,
              it returns an error code.  The opaque number RHandle is
              used by the caller for subsequent references to this
              reservation.  If the traffic control service updates the



Braden, Ed., et. al.        Standards Track                    [Page 70]

RFC 2205                          RSVP                    September 1997


              flowspec, the call will also return the updated object as
              Fwd_Flowspec.

         o    Modify Reservation

              Call: TC_ModFlowspec( Interface, RHandle, TC_Flowspec,

                                  TC_Tspec, TC_Adspec, Police_flags )

                                        [ -> Fwd_Flowspec ]


              This call is used to modify an existing reservation.
              TC_Flowspec is passed to Admission Control; if it is
              rejected, the current flowspec is left in force.  The
              corresponding filter specs, if any, are not affected.  The
              other parameters are defined as in TC_AddFlowspec.  If the
              service updates the flowspec, the call will also return
              the updated object as Fwd_Flowspec.

         o    Delete Flowspec

              Call: TC_DelFlowspec( Interface, RHandle )


              This call will delete an existing reservation, including
              the flowspec and all associated filter specs.

         o    Add Filter Spec

              Call: TC_AddFilter( Interface, RHandle,

                              Session , FilterSpec ) -> FHandle


              This call is used to associate an additional filter spec
              with the reservation specified by the given RHandle,
              following a successful TC_AddFlowspec call.  This call
              returns a filter handle FHandle.

         o    Delete Filter Spec

              Call: TC_DelFilter( Interface, FHandle )


              This call is used to remove a specific filter, specified
              by FHandle.




Braden, Ed., et. al.        Standards Track                    [Page 71]

RFC 2205                          RSVP                    September 1997


         o    OPWA Update

              Call: TC_Advertise( Interface, Adspec,

                                  Non_RSVP_Hop_flag ) -> New_Adspec


              This call is used for OPWA to compute the outgoing
              advertisement New_Adspec for a specified interface.  The
              flag bit Non_RSVP_Hop_flag should be set whenever the RSVP
              daemon detects that the previous RSVP hop included one or
              more non-RSVP-capable routers.  TC_Advertise will insert
              this information into New_Adspec to indicate that a non-
              integrated-service hop was found; see Section 3.8.

         o    Preemption Upcall

              Upcall: TC_Preempt() -> RHandle, Reason_code


              In order to grant a new reservation request, the admission
              control and/or policy control modules may preempt one or
              more existing reservations.  This will trigger a
              TC_Preempt() upcall to RSVP for each preempted
              reservation, passing the RHandle of the reservation and a
              sub-code indicating the reason.


      3.11.3 RSVP/Policy Control Interface

         This interface will be specified in a future document.

      3.11.4 RSVP/Routing Interface

         An RSVP implementation needs the following support from the
         routing mechanisms of the node.

         o    Route Query

              To forward Path and PathTear messages, an RSVP process
              must be able to query the routing process(s) for routes.

                 Ucast_Route_Query( [ SrcAddress, ] DestAddress,

                                     Notify_flag ) -> OutInterface

                 Mcast_Route_Query( [ SrcAddress, ] DestAddress,




Braden, Ed., et. al.        Standards Track                    [Page 72]

RFC 2205                          RSVP                    September 1997


                                     Notify_flag )

                                 -> [ IncInterface, ] OutInterface_list


              Depending upon the routing protocol, the query may or may
              not depend upon SrcAddress, i.e., upon the sender host IP
              address, which is also the IP source address of the
              message.  Here IncInterface is the interface through which
              the packet is expected to arrive; some multicast routing
              protocols may not provide it.  If the Notify_flag is True,
              routing will save state necessary to issue unsolicited
              route change notification callbacks (see below) whenever
              the specified route changes.

              A multicast route query may return an empty
              OutInterface_list if there are no receivers downstream of
              a particular router.  A route query may also return a `No
              such route' error, probably as a result of a transient
              inconsistency in the routing (since a Path or PathTear
              message for the requested route did arrive at this node).
              In either case, the local state should be updated as
              requested by the message, which cannot be forwarded
              further.  Updating local state will make path state
              available immediately for a new local receiver, or it will
              tear down path state immediately.

         o    Route Change Notification

              If requested by a route query with the Notify_flag True,
              the routing process may provide an asynchronous callback
              to the RSVP process that a specified route has changed.

                 Ucast_Route_Change( ) -> [ SrcAddress, ] DestAddress,

                                                OutInterface

                 Mcast_Route_Change( ) -> [ SrcAddress, ] DestAddress,

                               [ IncInterface, ] OutInterface_list


         o    Interface List Discovery

              RSVP must be able to learn what real and virtual
              interfaces are active, with their IP addresses.





Braden, Ed., et. al.        Standards Track                    [Page 73]

RFC 2205                          RSVP                    September 1997


              It should be possible to logically disable an interface
              for RSVP.  When an interface is disabled for RSVP, a Path
              message should never be forwarded out that interface, and
              if an RSVP message is received on that interface, the
              message should be silently discarded (perhaps with local
              logging).

      3.11.5 RSVP/Packet I/O Interface

         An RSVP implementation needs the following support from the
         packet I/O and forwarding mechanisms of the node.

         o    Promiscuous Receive Mode for RSVP Messages

              Packets received for IP protocol 46 but not addressed to
              the node must be diverted to the RSVP program for
              processing, without being forwarded.  The RSVP messages to
              be diverted in this manner will include Path, PathTear,
              and ResvConf messages.  These message types carry the
              Router Alert IP option, which can be used to pick them out
              of a high-speed forwarding path.  Alternatively, the node
              can intercept all protocol 46 packets.

              On a router or multi-homed host, the identity of the
              interface (real or virtual) on which a diverted message is
              received, as well as the IP source address and IP TTL with
              which it arrived, must also be available to the RSVP
              process.

         o    Outgoing Link Specification

              RSVP must be able to force a (multicast) datagram to be
              sent on a specific outgoing real or virtual link,
              bypassing the normal routing mechanism.  A virtual link
              might be a multicast tunnel, for example.  Outgoing link
              specification is necessary to send different versions of
              an outgoing Path message on different interfaces, and to
              avoid routing loops in some cases.

         o    Source Address and TTL Specification

              RSVP must be able to specify the IP source address and IP
              TTL to be used when sending Path messages.

         o    Router Alert

              RSVP must be able to cause Path, PathTear, and ResvConf
              message to be sent with the Router Alert IP option.



Braden, Ed., et. al.        Standards Track                    [Page 74]

RFC 2205                          RSVP                    September 1997


      3.11.6 Service-Dependent Manipulations

         Flowspecs, Tspecs, and Adspecs are opaque objects to RSVP;
         their contents are defined in service specification documents.
         In order to manipulate these objects, RSVP process must have
         available to it the following service-dependent routines.

         o    Compare Flowspecs


                 Compare_Flowspecs( Flowspec_1, Flowspec_2 ) ->

                                                        result_code


              The possible result_codes indicate: flowspecs are equal,
              Flowspec_1 is greater, Flowspec_2 is greater, flowspecs
              are incomparable but LUB can be computed, or flowspecs are
              incompatible.

              Note that comparing two flowspecs implicitly compares the
              Tspecs that are contained.  Although the RSVP process
              cannot itself parse a flowspec to extract the Tspec, it
              can use the Compare_Flowspecs call to implicitly calculate
              Resv_Te (see Section 2.2).

         o    Compute LUB of Flowspecs


                 LUB_of_Flowspecs( Flowspec_1, Flowspec_2 ) ->

                                                     Flowspec_LUB


         o    Compute GLB of Flowspecs


                 GLB_of_Flowspecs( Flowspec_1, Flowspec_2 ) ->

                                                     Flowspec_GLB


         o    Compare Tspecs


                 Compare_Tspecs( Tspec_1, Tspec_2 ) -> result_code





Braden, Ed., et. al.        Standards Track                    [Page 75]

RFC 2205                          RSVP                    September 1997


              The possible result_codes indicate: Tspecs are equal, or
              Tspecs are unequal.

         o    Sum Tspecs


                 Sum_Tspecs( Tspec_1, Tspec_2 ) -> Tspec_sum


              This call is used to compute Path_Te (see Section 2.2).

4. Acknowledgments

   The design of RSVP is based upon research performed in 1992-1993 by a
   collaboration including Lixia Zhang (UCLA), Deborah Estrin
   (USC/ISI), Scott Shenker (Xerox PARC), Sugih Jamin (USC/Xerox PARC),
   and Daniel Zappala (USC).  Sugih Jamin developed the first prototype
   implementation of RSVP and successfully demonstrated it in May 1993.
   Shai Herzog, and later Steve Berson, continued development of RSVP
   prototypes.

   Since 1993, many members of the Internet research community have
   contributed to the design and development of RSVP; these include (in
   alphabetical order) Steve Berson, Bob Braden, Lee Breslau, Dave
   Clark, Deborah Estrin, Shai Herzog, Craig Partridge, Scott Shenker,
   John Wroclawski, Daniel Zappala, and Lixia Zhang.  In addition, a
   number of host and router vendors have made valuable contributions to
   the RSVP documents, particularly Fred Baker (Cisco), Mark Baugher
   (Intel), Lou Berger (Fore Systems), Don Hoffman (Sun), Steve Jakowski
   (NetManage), John Krawczyk (Bay Networks), and Bill Nowicki (SGI), as
   well as many others.




















Braden, Ed., et. al.        Standards Track                    [Page 76]

RFC 2205                          RSVP                    September 1997


APPENDIX A. Object Definitions

   C-Types are defined for the two Internet address families IPv4 and
   IPv6.  To accommodate other address families, additional C-Types
   could easily be defined.  These definitions are contained as an
   Appendix, to ease updating.

   All unused fields should be sent as zero and ignored on receipt.

   A.1 SESSION Class

      SESSION Class = 1.

      o    IPv4/UDP SESSION object: Class = 1, C-Type = 1

           +-------------+-------------+-------------+-------------+
           |             IPv4 DestAddress (4 bytes)                |
           +-------------+-------------+-------------+-------------+
           | Protocol Id |    Flags    |          DstPort          |
           +-------------+-------------+-------------+-------------+


      o    IPv6/UDP SESSION object: Class = 1, C-Type = 2

           +-------------+-------------+-------------+-------------+
           |                                                       |
           +                                                       +
           |                                                       |
           +               IPv6 DestAddress (16 bytes)             +
           |                                                       |
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+-------------+
           | Protocol Id |     Flags   |          DstPort          |
           +-------------+-------------+-------------+-------------+



      DestAddress

           The IP unicast or multicast destination address of the
           session.  This field must be non-zero.

      Protocol Id

           The IP Protocol Identifier for the data flow.  This field
           must be non-zero.




Braden, Ed., et. al.        Standards Track                    [Page 77]

RFC 2205                          RSVP                    September 1997


      Flags

           0x01 = E_Police flag

                The E_Police flag is used in Path messages to determine
                the effective "edge" of the network, to control traffic
                policing.  If the sender host is not itself capable of
                traffic policing, it will set this bit on in Path
                messages it sends.  The first node whose RSVP is capable
                of traffic policing will do so (if appropriate to the
                service) and turn the flag off.

      DstPort

           The UDP/TCP destination port for the session.  Zero may be
           used to indicate `none'.

           Other SESSION C-Types could be defined in the future to
           support other demultiplexing conventions in the transport-
           layer or application layer.































Braden, Ed., et. al.        Standards Track                    [Page 78]

RFC 2205                          RSVP                    September 1997


   A.2 RSVP_HOP Class

      RSVP_HOP class = 3.

      o    IPv4 RSVP_HOP object: Class = 3, C-Type = 1

           +-------------+-------------+-------------+-------------+
           |             IPv4 Next/Previous Hop Address            |
           +-------------+-------------+-------------+-------------+
           |                 Logical Interface Handle              |
           +-------------+-------------+-------------+-------------+

      o    IPv6 RSVP_HOP object: Class = 3, C-Type = 2

           +-------------+-------------+-------------+-------------+
           |                                                       |
           +                                                       +
           |                                                       |
           +             IPv6 Next/Previous Hop Address            +
           |                                                       |
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+-------------+
           |                Logical Interface Handle               |
           +-------------+-------------+-------------+-------------+


      This object carries the IP address of the interface through which
      the last RSVP-knowledgeable hop forwarded this message.  The
      Logical Interface Handle (LIH) is used to distinguish logical
      outgoing interfaces, as discussed in Sections 3.3 and 3.9.  A node
      receiving an LIH in a Path message saves its value and returns it
      in the HOP objects of subsequent Resv messages sent to the node
      that originated the LIH.  The LIH should be identically zero if
      there is no logical interface handle.
















Braden, Ed., et. al.        Standards Track                    [Page 79]

RFC 2205                          RSVP                    September 1997


   A.3 INTEGRITY Class

      INTEGRITY class = 4.

      See [Baker96].

   A.4 TIME_VALUES Class

      TIME_VALUES class = 5.

      o    TIME_VALUES Object: Class = 5, C-Type = 1


           +-------------+-------------+-------------+-------------+
           |                   Refresh Period R                    |
           +-------------+-------------+-------------+-------------+



      Refresh Period

           The refresh timeout period R used to generate this message;
           in milliseconds.




























Braden, Ed., et. al.        Standards Track                    [Page 80]

RFC 2205                          RSVP                    September 1997


   A.5 ERROR_SPEC Class

      ERROR_SPEC class = 6.

      o    IPv4 ERROR_SPEC object: Class = 6, C-Type = 1


           +-------------+-------------+-------------+-------------+
           |            IPv4 Error Node Address (4 bytes)          |
           +-------------+-------------+-------------+-------------+
           |    Flags    |  Error Code |        Error Value        |
           +-------------+-------------+-------------+-------------+


      o    IPv6 ERROR_SPEC object: Class = 6, C-Type = 2


           +-------------+-------------+-------------+-------------+
           |                                                       |
           +                                                       +
           |                                                       |
           +           IPv6 Error Node Address (16 bytes)          +
           |                                                       |
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+-------------+
           |    Flags    |  Error Code |        Error Value        |
           +-------------+-------------+-------------+-------------+



      Error Node Address

           The IP address of the node in which the error was detected.

      Flags

           0x01 = InPlace

                This flag is used only for an ERROR_SPEC object in a
                ResvErr message.  If it on, this flag indicates that
                there was, and still is, a reservation in place at the
                failure point.

           0x02 = NotGuilty

                This flag is used only for an ERROR_SPEC object in a
                ResvErr message, and it is only set in the interface to



Braden, Ed., et. al.        Standards Track                    [Page 81]

RFC 2205                          RSVP                    September 1997


                the receiver application.  If it on, this flag indicates
                that the FLOWSPEC that failed was strictly greater than
                the FLOWSPEC requested by this receiver.

      Error Code

           A one-octet error description.

      Error Value

           A two-octet field containing additional information about the
                error.  Its contents depend upon the Error Type.

      The values for Error Code and Error Value are defined in Appendix
      B.




































Braden, Ed., et. al.        Standards Track                    [Page 82]

RFC 2205                          RSVP                    September 1997


   A.6 SCOPE Class

      SCOPE class = 7.

      This object contains a list of IP addresses, used for routing
      messages with wildcard scope without loops.  The addresses must be
      listed in ascending numerical order.

      o    IPv4 SCOPE List object: Class = 7, C-Type = 1


           +-------------+-------------+-------------+-------------+
           |                IPv4 Src Address (4 bytes)             |
           +-------------+-------------+-------------+-------------+
           //                                                      //
           +-------------+-------------+-------------+-------------+
           |                IPv4 Src Address (4 bytes)             |
           +-------------+-------------+-------------+-------------+


      o    IPv6  SCOPE list object: Class = 7, C-Type = 2


           +-------------+-------------+-------------+-------------+
           |                                                       |
           +                                                       +
           |                                                       |
           +                IPv6 Src Address (16 bytes)            +
           |                                                       |
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+-------------+
           //                                                      //
           +-------------+-------------+-------------+-------------+
           |                                                       |
           +                                                       +
           |                                                       |
           +                IPv6 Src Address (16 bytes)            +
           |                                                       |
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+-------------+









Braden, Ed., et. al.        Standards Track                    [Page 83]

RFC 2205                          RSVP                    September 1997


   A.7 STYLE Class

      STYLE class = 8.

      o    STYLE object: Class = 8, C-Type = 1

           +-------------+-------------+-------------+-------------+
           |   Flags     |              Option Vector              |
           +-------------+-------------+-------------+-------------+



      Flags: 8 bits

           (None assigned yet)

      Option Vector: 24 bits

           A set of bit fields giving values for the reservation
           options.  If new options are added in the future,
           corresponding fields in the option vector will be assigned
           from the least-significant end.  If a node does not recognize
           a style ID, it may interpret as much of the option vector as
           it can, ignoring new fields that may have been defined.

           The option vector bits are assigned (from the left) as
           follows:

           19 bits: Reserved

           2 bits: Sharing control

                00b: Reserved

                01b: Distinct reservations

                10b: Shared reservations

                11b: Reserved

           3 bits: Sender selection control

                000b: Reserved

                001b: Wildcard

                010b: Explicit




Braden, Ed., et. al.        Standards Track                    [Page 84]

RFC 2205                          RSVP                    September 1997


                011b - 111b: Reserved

      The low order bits of the option vector are determined by the
      style, as follows:

              WF 10001b
              FF 01010b
              SE 10010b











































Braden, Ed., et. al.        Standards Track                    [Page 85]

RFC 2205                          RSVP                    September 1997


   A.8 FLOWSPEC Class

      FLOWSPEC class = 9.

      o    Reserved (obsolete) flowspec object: Class = 9, C-Type = 1

      o    Inv-serv Flowspec object: Class = 9, C-Type = 2

           The contents and encoding rules for this object are specified
           in documents prepared by the int-serv working group [RFC
           2210].








































Braden, Ed., et. al.        Standards Track                    [Page 86]

RFC 2205                          RSVP                    September 1997


   A.9 FILTER_SPEC Class

      FILTER_SPEC class = 10.

      o    IPv4 FILTER_SPEC object: Class = 10, C-Type = 1

           +-------------+-------------+-------------+-------------+
           |               IPv4 SrcAddress (4 bytes)               |
           +-------------+-------------+-------------+-------------+
           |    //////   |    //////   |          SrcPort          |
           +-------------+-------------+-------------+-------------+


      o    IPv6 FILTER_SPEC object: Class = 10, C-Type = 2

           +-------------+-------------+-------------+-------------+
           |                                                       |
           +                                                       +
           |                                                       |
           +               IPv6 SrcAddress (16 bytes)              +
           |                                                       |
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+-------------+
           |    //////   |    //////   |          SrcPort          |
           +-------------+-------------+-------------+-------------+


      o    IPv6 Flow-label FILTER_SPEC object: Class = 10, C-Type = 3

           +-------------+-------------+-------------+-------------+
           |                                                       |
           +                                                       +
           |                                                       |
           +               IPv6 SrcAddress (16 bytes)              +
           |                                                       |
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+-------------+
           |   ///////   |         Flow Label (24 bits)            |
           +-------------+-------------+-------------+-------------+



      SrcAddress

           The IP source address for a sender host.  Must be non-zero.




Braden, Ed., et. al.        Standards Track                    [Page 87]

RFC 2205                          RSVP                    September 1997


      SrcPort

           The UDP/TCP source port for a sender, or zero to indicate
           `none'.

      Flow Label

           A 24-bit Flow Label, defined in IPv6.  This value may be used
           by the packet classifier to efficiently identify the packets
           belonging to a particular (sender->destination) data flow.









































Braden, Ed., et. al.        Standards Track                    [Page 88]

RFC 2205                          RSVP                    September 1997


   A.10 SENDER_TEMPLATE Class

      SENDER_TEMPLATE class = 11.

      o    IPv4 SENDER_TEMPLATE object: Class = 11, C-Type = 1

           Definition same as IPv4/UDP FILTER_SPEC object.

      o    IPv6 SENDER_TEMPLATE object: Class = 11, C-Type = 2

           Definition same as IPv6/UDP FILTER_SPEC object.

      o    IPv6 Flow-label SENDER_TEMPLATE object: Class = 11, C-Type =
           3

   A.11 SENDER_TSPEC Class

      SENDER_TSPEC class = 12.

      o    Intserv SENDER_TSPEC object: Class = 12, C-Type = 2

           The contents and encoding rules for this object are specified
           in documents prepared by the int-serv working group.

   A.12 ADSPEC Class

      ADSPEC class = 13.

      o    Intserv ADSPEC object: Class = 13, C-Type = 2

           The contents and format for this object are specified in
           documents prepared by the int-serv working group.



















Braden, Ed., et. al.        Standards Track                    [Page 89]

RFC 2205                          RSVP                    September 1997


   A.13 POLICY_DATA Class

      POLICY_DATA class = 14.

      o    Type 1 POLICY_DATA object: Class = 14, C-Type = 1

           The contents of this object are for further study.












































Braden, Ed., et. al.        Standards Track                    [Page 90]

RFC 2205                          RSVP                    September 1997


   A.14 Resv_CONFIRM Class

      RESV_CONFIRM class = 15.

      o    IPv4 RESV_CONFIRM object: Class = 15, C-Type = 1

           +-------------+-------------+-------------+-------------+
           |            IPv4 Receiver Address (4 bytes)            |
           +-------------+-------------+-------------+-------------+


      o    IPv6 RESV_CONFIRM object: Class = 15, C-Type = 2

           +-------------+-------------+-------------+-------------+
           |                                                       |
           +                                                       +
           |                                                       |
           +            IPv6 Receiver Address (16 bytes)           +
           |                                                       |
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+-------------+





























Braden, Ed., et. al.        Standards Track                    [Page 91]

RFC 2205                          RSVP                    September 1997


APPENDIX B. Error Codes and Values

   The following Error Codes may appear in ERROR_SPEC objects and be
   passed to end systems.  Except where noted, these Error Codes may
   appear only in ResvErr messages.

   o    Error Code = 00: Confirmation

        This code is reserved for use in the ERROR_SPEC object of a
        ResvConf message.  The Error Value will also be zero.

   o    Error Code = 01: Admission Control failure

        Reservation request was rejected by Admission Control due to
        unavailable resources.

        For this Error Code, the 16 bits of the Error Value field are:

           ssur cccc cccc cccc

        where the bits are:




        ss = 00: Low order 12 bits contain a globally-defined sub-code
             (values listed below).


        ss = 10: Low order 12 bits contain a organization-specific sub-
             code.  RSVP is not expected to be able to interpret this
             except as a numeric value.


        ss = 11: Low order 12 bits contain a service-specific sub-code.
             RSVP is not expected to be able to interpret this except as
             a numeric value.

             Since the traffic control mechanism might substitute a
             different service, this encoding may include some
             representation of the service in use.

             u = 0: RSVP rejects the message without updating local
             state.


        u = 1: RSVP may use message to update local state and forward
             the message.  This means that the message is informational.



Braden, Ed., et. al.        Standards Track                    [Page 92]

RFC 2205                          RSVP                    September 1997


        r: Reserved bit, should be zero.


        cccc cccc cccc: 12 bit code.

        The following globally-defined sub-codes may appear in the low-
        order 12 bits when ssur = 0000:

        -    Sub-code = 1: Delay bound cannot be met

        -    Sub-code = 2: Requested bandwidth unavailable

        -    Sub-code = 3: MTU in flowspec larger than interface MTU.

   o    Error Code = 02: Policy Control failure

        Reservation or path message has been rejected for administrative
        reasons, for example, required credentials not submitted,
        insufficient quota or balance, or administrative preemption.
        This Error Code may appear in a PathErr or ResvErr message.

        Contents of the Error Value field are to be determined in the
        future.

   o    Error Code = 03: No path information for this Resv message.

        No path state for this session.  Resv message cannot be
        forwarded.

   o    Error Code = 04: No sender information for this Resv message.

        There is path state for this session, but it does not include
        the sender matching some flow descriptor contained in the Resv
        message.  Resv message cannot be forwarded.

   o    Error Code = 05: Conflicting reservation style

        Reservation style conflicts with style(s) of existing
        reservation state.  The Error Value field contains the low-order
        16 bits of the Option Vector of the existing style with which
        the conflict occurred.  This Resv message cannot be forwarded.

   o    Error Code = 06: Unknown reservation style

        Reservation style is unknown.  This Resv message cannot be
        forwarded.





Braden, Ed., et. al.        Standards Track                    [Page 93]

RFC 2205                          RSVP                    September 1997


   o    Error Code = 07: Conflicting dest ports

        Sessions for same destination address and protocol have appeared
        with both zero and non-zero dest port fields.  This Error Code
        may appear in a PathErr or ResvErr message.

   o    Error Code = 08: Conflicting sender ports

        Sender port is both zero and non-zero in Path messages for the
        same session.  This Error Code may appear only in a PathErr
        message.

   o    Error Code = 09, 10, 11: (reserved)

   o    Error Code = 12: Service preempted

        The service request defined by the STYLE object and the flow
        descriptor has been administratively preempted.

        For this Error Code, the 16 bits of the Error Value field are:


           ssur cccc cccc cccc

        Here the high-order bits ssur are as defined under Error Code
        01.  The globally-defined sub-codes that may appear in the low-
        order 12 bits when ssur = 0000 are to be defined in the future.

   o    Error Code = 13: Unknown object class

        Error Value contains 16-bit value composed of (Class-Num, C-
        Type) of unknown object.  This error should be sent only if RSVP
        is going to reject the message, as determined by the high-order
        bits of the Class-Num.  This Error Code may appear in a PathErr
        or ResvErr message.

   o    Error Code = 14: Unknown object C-Type

        Error Value contains 16-bit value composed of (Class-Num, C-
        Type) of object.

   o    Error Code = 15-19: (reserved)

   o    Error Code = 20: Reserved for API

        Error Value field contains an API error code, for an API error
        that was detected asynchronously and must be reported via an
        upcall.



Braden, Ed., et. al.        Standards Track                    [Page 94]

RFC 2205                          RSVP                    September 1997


   o    Error Code = 21: Traffic Control Error

        Traffic Control call failed due to the format or contents of the
        parameters to the request.  The Resv or Path message that caused
        the call cannot be forwarded, and repeating the call would be
        futile.

        For this Error Code, the 16 bits of the Error Value field are:


           ss00 cccc cccc cccc

        Here the high-order bits ss are as defined under Error Code 01.

        The following globally-defined sub-codes may appear in the low
        order 12 bits (cccc cccc cccc) when ss = 00:

        -    Sub-code = 01: Service conflict

             Trying to merge two incompatible service requests.

        -    Sub-code = 02: Service unsupported

             Traffic control can provide neither the requested service
             nor an acceptable replacement.

        -    Sub-code = 03: Bad Flowspec value

             Malformed or unreasonable request.

        -    Sub-code = 04: Bad Tspec value

             Malformed or unreasonable request.

        -    Sub-code = 05: Bad Adspec value

             Malformed or unreasonable request.

   o    Error Code = 22: Traffic Control System error

        A system error was detected and reported by the traffic control
        modules.  The Error Value will contain a system-specific value
        giving more information about the error.  RSVP is not expected
        to be able to interpret this value.







Braden, Ed., et. al.        Standards Track                    [Page 95]

RFC 2205                          RSVP                    September 1997


   o    Error Code = 23: RSVP System error

        The Error Value field will provide implementation-dependent
        information on the error.  RSVP is not expected to be able to
        interpret this value.

   In general, every RSVP message is rebuilt at each hop, and the node
   that creates an RSVP message is responsible for its correct
   construction.  Similarly, each node is required to verify the correct
   construction of each RSVP message it receives.  Should a programming
   error allow an RSVP to create a malformed message, the error is not
   generally reported to end systems in an ERROR_SPEC object; instead,
   the error is simply logged locally, and perhaps reported through
   network management mechanisms.

   The only message formatting errors that are reported to end systems
   are those that may reflect version mismatches, and which the end
   system might be able to circumvent, e.g., by falling back to a
   previous CType for an object; see code 13 and 14 above.

   The choice of message formatting errors that an RSVP may detect and
   log locally is implementation-specific, but it will typically include
   the following:

   o    Wrong-length message: RSVP Length field does not match message
        length.

   o    Unknown or unsupported RSVP version.

   o    Bad RSVP checksum

   o    INTEGRITY failure

   o    Illegal RSVP message Type

   o    Illegal object length: not a multiple of 4, or less than 4.

   o    Next hop/Previous hop address in HOP object is illegal.

   o    Bad source port: Source port is non-zero in a filter spec or
        sender template for a session with destination port zero.

   o    Required object class (specify) missing

   o    Illegal object class (specify) in this message type.

   o    Violation of required object order




Braden, Ed., et. al.        Standards Track                    [Page 96]

RFC 2205                          RSVP                    September 1997


   o    Flow descriptor count wrong for style or message type

   o    Logical Interface Handle invalid

   o    Unknown object Class-Num.

   o    Destination address of ResvConf message does not match Receiver
        Address in the RESV_CONFIRM object it contains.











































Braden, Ed., et. al.        Standards Track                    [Page 97]

RFC 2205                          RSVP                    September 1997


APPENDIX C. UDP Encapsulation

   An RSVP implementation will generally require the ability to perform
   "raw" network I/O, i.e., to send and receive IP datagrams using
   protocol 46.  However, some important classes of host systems may not
   support raw network I/O.  To use RSVP, such hosts must encapsulate
   RSVP messages in UDP.

   The basic UDP encapsulation scheme makes two assumptions:

   1.   All hosts are capable of sending and receiving multicast packets
        if multicast destinations are to be supported.

   2.   The first/last-hop routers are RSVP-capable.

   A method of relaxing the second assumption is given later.

   Let Hu be a "UDP-only" host that requires UDP encapsulation, and Hr a
   host that can do raw network I/O.  The UDP encapsulation scheme must
   allow RSVP interoperation among an arbitrary topology of Hr hosts, Hu
   hosts, and routers.

   Resv, ResvErr, ResvTear, and PathErr messages are sent to unicast
   addresses learned from the path or reservation state in the node.  If
   the node keeps track of which previous hops and which interfaces need
   UDP encapsulation, these messages can be sent using UDP encapsulation
   when necessary.  On the other hand, Path and PathTear messages are
   sent to the destination address for the session, which may be unicast
   or multicast.

   The tables in Figures 13 and 14 show the basic rules for UDP
   encapsulation of Path and PathTear messages, for unicast DestAddress
   and multicast DestAddress, respectively.  The other message types,
   which are sent unicast, should follow the unicast rules in Figure 13.
   Under the `RSVP Send' columns in these figures, the notation is
   `mode(destaddr, destport)'; destport is omitted for raw packets.  The
   `Receive' columns show the group that is joined and, where relevant,
   the UDP Listen port.

   It is useful to define two flavors of UDP encapsulation, one to be
   sent by Hu and the other to be sent by Hr and R, to avoid double
   processing by the recipient.  In practice, these two flavors are
   distinguished by differing UDP port numbers Pu and Pu'.








Braden, Ed., et. al.        Standards Track                    [Page 98]

RFC 2205                          RSVP                    September 1997


   The following symbols are used in the tables.

   o    D is the DestAddress for the particular session.

   o    G* is a well-known group address of the form 224.0.0.14, i.e., a
        group that is limited to the local connected network.

   o    Pu and Pu' are two well-known UDP ports for UDP encapsulation of
        RSVP, with values 1698 and 1699.

   o    Ra is the IP address of the router interface `a'.

   o    Router interface `a' is on the local network connected to Hu and
        Hr.

   o

   The following notes apply to these figures:


      [Note 1] Hu sends a unicast Path message either to the destination
      address D, if D is local, or to the address Ra of the first-hop
      router.  Ra is presumably known to the host.

      [Note 2] Here D is the address of the local interface through
      which the message arrived.

      [Note 3] This assumes that the application has joined the group D.























Braden, Ed., et. al.        Standards Track                    [Page 99]

RFC 2205                          RSVP                    September 1997



   UNICAST DESTINATION D:

                   RSVP               RSVP
   Node            Send               Receive
   ___       _____________          _______________
   Hu         UDP(D/Ra,Pu)          UDP(D,Pu)
                 [Note 1]       and UDP(D,Pu')
                                       [Note 2]


   Hr         Raw(D)                Raw()
               and if (UDP)     and UDP(D, Pu)
               then UDP(D,Pu')         [Note 2]
                                    (Ignore Pu')

   R (Interface a):
              Raw(D)                Raw()
               and if (UDP)     and UDP(Ra, Pu)
               then UDP(D,Pu')      (Ignore Pu')


   Figure 13: UDP Encapsulation Rules for Unicast Path and Resv Messages



   MULTICAST DESTINATION D:

                  RSVP                    RSVP
   Node           Send                    Receive
   ___           _____________        _________________
   Hu             UDP(G*,Pu)              UDP(D,Pu')
                                              [Note 3]
                                      and UDP(G*,Pu)


   Hr             Raw(D,Tr)               Raw()
                   and if (UDP)       and UDP(G*,Pu)
                     then UDP(D,Pu')     (Ignore Pu')

   R (Interface a):
                  Raw(D,Tr)               Raw()
                   and if (UDP)       and UDP(G*,Pu)
                     then UDP(D,Pu')     (Ignore Pu')

      Figure 14: UDP Encapsulation Rules for Multicast Path Messages





Braden, Ed., et. al.        Standards Track                   [Page 100]

RFC 2205                          RSVP                    September 1997


   A router may determine if its interface X needs UDP encapsulation by
   listening for UDP-encapsulated Path messages that were sent to either
   G* (multicast D) or to the address of interface X (unicast D).  There
   is one failure mode for this scheme:  if no host on the connected
   network acts as an RSVP sender, there will be no Path messages to
   trigger UDP encapsulation.  In this (unlikely) case, it will be
   necessary to explicitly configure UDP encapsulation on the local
   network interface of the router.

   When a UDP-encapsulated packet is received, the IP TTL is not
   available to the application on most systems.  The RSVP process that
   receives a UDP-encapsulated Path or PathTear message should therefore
   use the Send_TTL field of the RSVP common header as the effective
   receive TTL.  This may be overridden by manual configuration.

   We have assumed that the first-hop RSVP-capable router R is on the
   directly-connected network.  There are several possible approaches if
   this is not the case.

   1.   Hu can send both unicast and multicast sessions to UDP(Ra,Pu)
        with TTL=Ta

        Here Ta must be the TTL to exactly reach R.  If Ta is too small,
        the Path message will not reach R.  If Ta is too large, R and
        succeeding routers may forward the UDP packet until its hop
        count expires.  This will turn on UDP encapsulation between
        routers within the Internet, perhaps causing bogus UDP traffic.
        The host Hu must be explicitly configured with Ra and Ta.

   2.   A particular host on the LAN connected to Hu could be designated
        as an "RSVP relay host".  A relay host would listen on (G*,Pu)
        and forward any Path messages directly to R, although it would
        not be in the data path.  The relay host would have to be
        configured with Ra and Ta.

















Braden, Ed., et. al.        Standards Track                   [Page 101]

RFC 2205                          RSVP                    September 1997


APPENDIX D. Glossary

   o    Admission control

        A traffic control function that decides whether the packet
        scheduler in the node can supply the requested QoS while
        continuing to provide the QoS requested by previously-admitted
        requests.  See also "policy control" and "traffic control".

   o    Adspec

        An Adspec is a data element (object) in a Path message that
        carries a package of OPWA advertising information.  See "OPWA".

   o    Auto-refresh loop

        An auto-refresh loop is an error condition that occurs when a
        topological loop of routers continues to refresh existing
        reservation state even though all receivers have stopped
        requesting these reservations.  See section 3.4 for more
        information.

   o    Blockade state

        Blockade state helps to solve a "killer reservation" problem.
        See sections 2.5 and 3.5, and "killer reservation".

   o    Branch policing

        Traffic policing at a multicast branching point on an outgoing
        interface that has "less" resources reserved than another
        outgoing interface for the same flow.  See "traffic policing".

   o    C-Type

        The class type of an object; unique within class-name.  See
        "class-name".

   o    Class-name

        The class of an object.  See "object".

   o    DestAddress

        The IP destination address; part of session identification.  See
        "session".





Braden, Ed., et. al.        Standards Track                   [Page 102]

RFC 2205                          RSVP                    September 1997


   o    Distinct style

        A (reservation) style attribute; separate resources are reserved
        for each different sender.  See also "shared style".

   o    Downstream

        Towards the data receiver(s).

   o    DstPort

        The IP (generalized) destination port used as part of a session.
        See "generalized destination port".

   o    Entry policing

        Traffic policing done at the first RSVP- (and policing-) capable
        router on a data path.

   o    ERROR_SPEC

        Object that carries the error report in a PathErr or ResvErr
        message.

   o    Explicit sender selection

        A (reservation) style attribute; all reserved senders are to be
        listed explicitly in the reservation message.  See also
        "wildcard sender selection".

   o    FF style

        Fixed Filter reservation style, which has explicit sender
        selection and distinct attributes.

   o    FilterSpec

        Together with the session information, defines the set of data
        packets to receive the QoS specified in a flowspec.  The
        filterspec is used to set parameters in the packet classifier
        function.  A filterspec may be carried in a FILTER_SPEC or
        SENDER_TEMPLATE object.

   o    Flow descriptor

        The combination of a flowspec and a filterspec.





Braden, Ed., et. al.        Standards Track                   [Page 103]

RFC 2205                          RSVP                    September 1997


   o    Flowspec

        Defines the QoS to be provided for a flow.  The flowspec is used
        to set parameters in the packet scheduling function to provide
        the requested quality of service.  A flowspec is carried in a
        FLOWSPEC object.  The flowspec format is opaque to RSVP and is
        defined by the Integrated Services Working Group.

   o    Generalized destination port

        The component of a session definition that provides further
        transport or application protocol layer demultiplexing beyond
        DestAddress.  See "session".

   o    Generalized source port

        The component of a filter spec that provides further transport
        or application protocol layer demultiplexing beyond the sender
        address.

   o    GLB

        Greatest Lower Bound

   o    Incoming interface

        The interface on which data packets are expected to arrive, and
        on which Resv messages are sent.

   o    INTEGRITY

        Object of an RSVP control message that contains cryptographic
        data to authenticate the originating node and to verify the
        contents of an RSVP message.

   o    Killer reservation problem

        The killer reservation problem describes a case where a receiver
        attempting and failing to make a large QoS reservation prevents
        smaller QoS reservations from being established.  See Sections
        2.5 and 3.5 for more information.

   o    LIH

        The LIH (Logical Interface Handle) is used to help deal with
        non-RSVP clouds.  See Section 2.9 for more information.





Braden, Ed., et. al.        Standards Track                   [Page 104]

RFC 2205                          RSVP                    September 1997


   o    Local repair

        Allows RSVP to rapidly adapt its reservations to changes in
        routing.  See Section 3.6 for more information.

   o    LPM

        Local Policy Module. the function that exerts policy control.

   o    LUB

        Least Upper Bound.

   o    Merge policing

        Traffic policing that takes place at data merge point of a
        shared reservation.

   o    Merging

        The process of taking the maximum (or more generally the least
        upper bound) of the reservations arriving on outgoing
        interfaces, and forwarding this maximum on the incoming
        interface.  See Section 2.2 for more information.

   o    MTU

        Maximum Transmission Unit.

   o    Next hop

        The next router in the direction of traffic flow.

   o    NHOP

        An object that carries the Next Hop information in RSVP control
        messages.

   o    Node

        A router or host system.

   o    Non-RSVP clouds

        Groups of hosts and routers that do not run RSVP.  Dealing with
        nodes that do not support RSVP is important for backwards
        compatibility.  See section 2.9.




Braden, Ed., et. al.        Standards Track                   [Page 105]

RFC 2205                          RSVP                    September 1997


   o    Object

        An element of an RSVP control message; a type, length, value
        triplet.

   o    OPWA

        Abbreviation for "One Pass With Advertising".  Describes a
        reservation setup model in which (Path) messages sent downstream
        gather information that the receiver(s) can use to predict the
        end-to-end service.  The information that is gathered is called
        an advertisement.  See also "Adspec".

   o    Outgoing interface

        Interface through which data packets and Path messages are
        forwarded.

   o    Packet classifier

        Traffic control function in the primary data packet forwarding
        path that selects a service class for each packet, in accordance
        with the reservation state set up by RSVP.  The packet
        classifier may be combined with the routing function.  See also
        "traffic control".

   o    Packet scheduler

        Traffic control function in the primary data packet forwarding
        path that implements QoS for each flow, using one of the service
        models defined by the Integrated Services Working Group.  See
        also " traffic control".

   o    Path state

        Information kept in routers and hosts about all RSVP senders.

   o    PathErr

        Path Error RSVP control message.

   o    PathTear

        Path Teardown RSVP control message.







Braden, Ed., et. al.        Standards Track                   [Page 106]

RFC 2205                          RSVP                    September 1997


   o    PHOP

        An object that carries the Previous Hop information in RSVP
        control messages.


   o    Police

        See traffic policing.

   o    Policy control

        A function that determines whether a new request for quality of
        service has administrative permission to make the requested
        reservation.  Policy control may also perform accounting (usage
        feedback) for a reservation.

   o    Policy data

        Data carried in a Path or Resv message and used as input to
        policy control to determine authorization and/or usage feedback
        for the given flow.

   o    Previous hop

        The previous router in the direction of traffic flow.  Resv
        messages flow towards previous hops.

   o    ProtocolId

        The component of session identification that specifies the IP
        protocol number used by the data stream.

   o    QoS

        Quality of Service.

   o    Reservation state

        Information kept in RSVP-capable nodes about successful RSVP
        reservation requests.


   o    Reservation style

        Describes a set of attributes for a reservation, including the
        sharing attributes and sender selection attributes.  See Section
        1.3 for details.



Braden, Ed., et. al.        Standards Track                   [Page 107]

RFC 2205                          RSVP                    September 1997


   o    Resv message

        Reservation request RSVP control message.


   o    ResvConf

        Reservation Confirmation RSVP control message, confirms
        successful installation of a reservation at some upstream node.

   o    ResvErr

        Reservation Error control message, indicates that a reservation
        request has failed or an active reservation has been preempted.

   o    ResvTear

        Reservation Teardown RSVP control message, deletes reservation
        state.

   o    Rspec

        The component of a flowspec that defines a desired QoS.  The
        Rspec format is opaque to RSVP and is defined by the Integrated
        Services Working Group of the IETF.

   o    RSVP_HOP

        Object of an RSVP control message that carries the PHOP or NHOP
        address of the source of the message.

   o    Scope

        The set of sender hosts to which a given reservation request is
        to be propagated.

   o    SE style

        Shared Explicit reservation style, which has explicit sender
        selection and shared attributes.

   o    Semantic fragmentation

        A method of fragmenting a large RSVP message using information
        about the structure and contents of the message, so that each
        fragment is a logically complete RSVP message.





Braden, Ed., et. al.        Standards Track                   [Page 108]

RFC 2205                          RSVP                    September 1997


   o    Sender template

        Parameter in a Path message that defines a sender; carried in a
        SENDER_TEMPLATE object.  It has the form of a filter spec that
        can be used to select this sender's packets from other packets
        in the same session on the same link.

   o    Sender Tspec

        Parameter in a Path message, a Tspec that characterizes the
        traffic parameters for the data flow from the corresponding
        sender.  It is carried in a SENDER_TSPEC object.

   o    Session

        An RSVP session defines one simplex unicast or multicast data
        flow for which reservations are required.  A session is
        identified by the destination address, transport-layer protocol,
        and an optional (generalized) destination port.

   o    Shared style

        A (reservation) style attribute: all reserved senders share the
        same reserved resources.  See also "distinct style".

   o    Soft state

        Control state in hosts and routers that will expire if not
        refreshed within a specified amount of time.

   o    STYLE

        Object of an RSVP message that specifies the desired reservation
        style.

   o    Style

        See "reservation style"

   o    TIME_VALUES

        Object in an RSVP control message that specifies the time period
        timer used for refreshing the state in this message.








Braden, Ed., et. al.        Standards Track                   [Page 109]

RFC 2205                          RSVP                    September 1997


   o    Traffic control

        The entire set of machinery in the node that supplies requested
        QoS to data streams.  Traffic control includes packet
        classifier, packet scheduler, and admission control functions.


   o    Traffic policing

        The function, performed by traffic control, of forcing a given
        data flow into compliance with the traffic parameters implied by
        the reservation.  It may involve dropping non-compliant packets
        or sending them with lower priority, for example.

   o    TSpec

        A traffic parameter set that describes a flow.  The format of a
        Tspec is opaque to RSVP and is defined by the Integrated Service
        Working Group.

   o    UDP encapsulation

        A way for hosts that cannot use raw sockets to participate in
        RSVP by encapsulating the RSVP protocol (raw) packets in
        ordinary UDP packets.  See Section APPENDIX C for more
        information.

   o    Upstream

        Towards the traffic source.  RSVP Resv messages flow upstream.

   o    WF style

        Wildcard Filter reservation style, which has wildcard sender
        selection and shared attributes.

   o    Wildcard sender selection

        A (reservation) style attribute: traffic from any sender to a
        specific session receives the same QoS.  See also "explicit
        sender selection".










Braden, Ed., et. al.        Standards Track                   [Page 110]

RFC 2205                          RSVP                    September 1997


References

[Baker96]  Baker, F., "RSVP Cryptographic Authentication", Work in
    Progress.

[RFC 1633]  Braden, R., Clark, D., and S. Shenker, "Integrated Services
    in the Internet Architecture: an Overview", RFC 1633, ISI, MIT, and
    PARC, June 1994.

[FJ94]  Floyd, S. and V. Jacobson, "Synchronization of Periodic Routing
    Messages", IEEE/ACM Transactions on Networking, Vol. 2, No. 2,
    April, 1994.

[RFC 2207]  Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data
    Flows", RFC 2207, September 1997.

[RFC 2113]  Katz, D., "IP Router Alert Option", RFC 2113, cisco Systems,
    February 1997.

[RFC 2210]  Wroclawski, J., "The Use of RSVP with Integrated Services",
    RFC 2210, September 1997.

[PolArch96]  Herzog, S., "Policy Control for RSVP: Architectural
    Overview".  Work in Progress.

[OPWA95]  Shenker, S. and L. Breslau, "Two Issues in Reservation
    Establishment", Proc. ACM SIGCOMM '95, Cambridge, MA, August 1995.

[RSVP93]  Zhang, L., Deering, S., Estrin, D., Shenker, S., and D.
    Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE Network,
    September 1993.



Security Considerations

   See Section 2.8.














Braden, Ed., et. al.        Standards Track                   [Page 111]

RFC 2205                          RSVP                    September 1997


Authors' Addresses


   Bob Braden
   USC Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292

   Phone: (310) 822-1511
   EMail: Braden@ISI.EDU

   Lixia Zhang
   UCLA Computer Science Department
   4531G Boelter Hall
   Los Angeles, CA 90095-1596 USA

   Phone: 310-825-2695
   EMail: lixia@cs.ucla.edu

   Steve Berson
   USC Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292

   Phone: (310) 822-1511
   EMail: Berson@ISI.EDU


   Shai Herzog
   IBM T. J. Watson Research Center
   P.O Box 704
   Yorktown Heights, NY 10598

   Phone: (914) 784-6059
   EMail: Herzog@WATSON.IBM.COM


   Sugih Jamin
   University of Michigan
   CSE/EECS
   1301 Beal Ave.
   Ann Arbor, MI 48109-2122

   Phone: (313) 763-1583

   EMail: jamin@EECS.UMICH.EDU




Braden, Ed., et. al.        Standards Track                   [Page 112]