File: rfc2210.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 (1851 lines) | stat: -rw-r--r-- 77,613 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






Network Working Group                                      J. Wroclawski
Request for Comments: 2210                                       MIT LCS
Category: Standards Track                                 September 1997



             The Use of RSVP with IETF Integrated Services


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 note describes the use of the RSVP resource reservation protocol
   with the Controlled-Load and Guaranteed QoS control services.  The
   RSVP protocol defines several data objects which carry resource
   reservation information but are opaque to RSVP itself.  The usage and
   data format of those objects is given here.

1. Introduction

   The Internet integrated services framework provides the ability for
   applications to choose among multiple, controlled levels of delivery
   service for their data packets. To support this capability, two
   things are required:

      - Individual network elements (subnets and IP routers) along the
      path followed by an application's data packets must support
      mechanisms to control the quality of service delivered to those
      packets.

      - A way to communicate the application's requirements to network
      elements along the path and to convey QoS management information
      between network elements and the application must be provided.

   In the integrated services framework the first function is provided
   by QoS control services such as Controlled-Load [RFC 2211] and
   Guaranteed [RFC 2212].  The second function may be provided in a
   number of ways, but is frequently implemented by a resource
   reservation setup protocol such as RSVP [RFC 2205].





Wroclawski                  Standards Track                     [Page 1]

RFC 2210                   RSVP with INTSERV              September 1997


   Because RSVP is designed to be used with a variety of QoS control
   services, and because the QoS control services are designed to be
   used with a variety of setup mechanisms, a logical separation exists
   between the two specifications. The RSVP specification does not
   define the internal format of those RSVP protocol fields, or objects,
   which are related to invoking QoS control services. Rather, RSVP
   treats these objects as opaque.  The objects can carry different
   information to meet different application and QoS control service
   requirements.

   Similarly, interfaces to the QoS control services are defined in a
   general format, so that the services can be used with a variety of
   setup mechanisms.

   This RFC provides the information required to use RSVP and the
   integrated service framework's QoS control services together. It
   defines the usage and contents of three RSVP protocol objects, the
   FLOWSPEC, ADSPEC, and SENDER_TSPEC, in an environment supporting the
   Controlled-Load and/or Guaranteed QoS control services. If new
   services or capabilities are added to the integrated services
   framework, this note will be revised as required.

2. Use of RSVP

   Several types of data must be transported between applications and
   network elements to correctly invoke QoS control services.

      NOTE: In addition to the data used to directly invoke QoS control
      services, RSVP carries authentication, accounting, and policy
      information needed to manage the use of these services. This note
      is concerned only with the RSVP objects needed to actually invoke
      QoS control services, and does not discuss accounting or policy
      objects.

   This data includes:

      - Information generated by each receiver describing the QoS
      control service desired, a description of the traffic flow to
      which the resource reservation should apply (the Receiver TSpec),
      and whatever parameters are required to invoke the service (the
      Receiver RSpec). This information is carried from the receivers to
      intermediate network elements and the sender(s) by RSVP FLOWSPEC
      objects. The information being carried in a FLOWSPEC object may
      change at intermediate points in the network due to reservation
      merging and other factors.






Wroclawski                  Standards Track                     [Page 2]

RFC 2210                   RSVP with INTSERV              September 1997


      - Information generated at each sender describing the data traffic
      generated by that sender (the Sender TSpec). This information is
      carried from the sender to intermediate network elements and the
      receiver(s) by RSVP, but is never modified by intermediate
      elements within the network. This information is carried in RSVP
      SENDER_TSPEC objects.

      - Information generated or modified within the network and used at
      the receivers to make reservation decisions.  This information
      might include available services, delay and bandwidth estimates,
      and operating parameters used by specific QoS control services.
      this information is collected from network elements and carried
      towards receivers in RSVP ADSPEC objects.  Rather than carrying
      information from each intermediate node separately to the
      receivers, the information in the ADSPEC represents a summary,
      computed as the ADSPEC passes each hop.  The size of this summary
      remains (roughly) constant as the ADSPEC flows through the
      network, giving good scaling properties.

   From the point of view of RSVP objects, the breakdown is as follows:

      - The RSVP SENDER_TSPEC object carries the traffic specification
      (sender TSpec) generated by each data source within an RSVP
      session.  It is transported unchanged through the network, and
      delivered to both intermediate nodes and receiving applications.

      - The RSVP ADSPEC object carries information which is generated at
      either data sources or intermediate network elements, is flowing
      downstream towards receivers, and may be used and updated inside
      the network before being delivered to receiving applications.
      This information includes both parameters describing the
      properties of the data path, including the availability of
      specific QoS control services, and parameters required by specific
      QoS control services to operate correctly.

      - The RSVP FLOWSPEC object carries reservation request
      (Receiver_TSpec and RSpec) information generated by data
      receivers.  The information in the FLOWSPEC flows upstream towards
      data sources.  It may be used or updated at intermediate network
      elements before arriving at the sending application.

        NOTE: The existence of both SENDER_TSPEC and ADSPEC RSVP objects
        is somewhat historical. Using the message format described in
        this note it would be possible to place all of the service
        control information carried "downstream" by RSVP in the same
        object. However, the distinction between data which is not
        updated within the network (in the SENDER_TSPEC object) and data
        which is updated within the network (in the ADSPEC object) may



Wroclawski                  Standards Track                     [Page 3]

RFC 2210                   RSVP with INTSERV              September 1997


        be useful to an implementation in practice, and is therefore
        retained.

2.1 Summary of operation

   Operation proceeds as follows:

   An application instance participating in an RSVP session as a data
   sender registers with RSVP. One piece of information provided by the
   application instance is the Sender TSpec describing the traffic the
   application expects to generate.  This information is used to
   construct an RSVP SENDER_TSPEC object, which is included in RSVP PATH
   messages generated for the application.

   The sending application also constructs an initial RSVP ADSPEC
   object.  This adspec carries information about the QoS control
   capabilities and requirements of the sending application itself, and
   forms the starting point for the accumulation of path properties
   described below. The ADSPEC is added to the RSVP PATH message created
   at the sender.

      NOTE: For the convenience of application programmers, a host RSVP
      implementation may allow the sending application not to provide an
      initial adspec, instead supplying its own default.  This usage is
      most likely when the application sender does not itself
      participate in the end-to-end QoS control process (by actively
      scheduling CPU usage and similar means) and does not itself care
      which QoS control service is selected by the receivers.

      Typically the default ADSPEC supplied by the host RSVP in this
      case would support all QoS control services known to the host.
      However, the exact behavior of this mechanism is implementation
      dependent.

   The ADSPEC is modified by subsequent network elements as the RSVP
   PATH message moves from sender to receiver(s).  At each network
   element, the ADSPEC is passed from RSVP to the traffic control
   module.  The traffic control module updates the ADSPEC, which may
   contain data for several QoS control services, by identifying the
   services mentioned in the ADSPEC and calling each such service to
   update its portion of the ADSPEC. If the traffic control module
   discovers a QoS control service mentioned in the ADSPEC but not
   implemented by the network element, a flag is set to report this to
   the receiver.  The updated ADSPEC is then returned to RSVP for
   delivery to the next hop along the path.






Wroclawski                  Standards Track                     [Page 4]

RFC 2210                   RSVP with INTSERV              September 1997


   Upon arrival of the PATH message at an application receiver, the data
   in the SENDER_TSPEC and ADSPEC objects is passed across the RSVP API
   to the application.  The application (perhaps with the help of a
   library of common resource-reservation functions) interprets the
   arriving data, and uses it to guide the selection of resource
   reservation parameters.  Examples of this include use of the arriving
   "PATH_MTU" composed characterization parameter [RFC 2215] to
   determine the maximum packet size parameter in the reservation
   request and use of the arriving Guaranteed service "C" and "D"
   parameters [RFC 2212] to calculate a mathematical bound on delivered
   packet delay when using the Guaranteed service.

   An application receiver wishing to make a resource reservation
   supplies its local RSVP with the necessary reservation parameters.
   Among these are the QoS control service desired (Guaranteed or
   Controlled-Load), the traffic specifier (TSpec) describing the level
   of traffic for which resources should be reserved, and, if needed by
   the selected QoS control service, an RSpec describing the level of
   service desired.  These parameters are composed into an RSVP FLOWSPEC
   object and transmitted upstream by RSVP.

   At each RSVP-aware point in the network, the SENDER_TSPECs arriving
   in PATH messages and the FLOWSPECs arriving in RESV messages are used
   to request an appropriate resource reservation from the desired QoS
   control service.  State merging, message forwarding, and error
   handling proceed according to the rules of the RSVP protocol.

   Finally, the merged FLOWSPEC object arriving at each of an RSVP
   session's data senders is delivered to the application to inform each
   sender of the merged reservation request and properties of the data
   path.

2.2. RSVP support for multiple QoS control services

   The design described in this note supports RSVP sessions in which the
   receivers choose a QoS control service at runtime.

   To make this possible, a receiver must have all the information
   needed to choose a particular service before it makes the choice.
   This means that the RSVP SENDER_TSPEC and ADSPEC objects must provide
   the receivers with information for all services which might be
   chosen.

   The Sender TSpec used by the two currently defined QoS control
   services is identical.  This simplifies the RSVP SENDER_TSPEC object,
   which need carry only a single TSpec data structure in this shared
   format.  This common SENDER_TSPEC can be used with either Guaranteed
   or Controlled-Load service.



Wroclawski                  Standards Track                     [Page 5]

RFC 2210                   RSVP with INTSERV              September 1997


   The RSVP ADSPEC carries information needed by receivers to choose a
   service and determine the reservation parameters. This includes:

      - Whether or not there is a non-RSVP hop along the path. If there
      is a non-RSVP hop, the application's traffic will receive
      reservationless best-effort service at at least one point on the
      path.

      - Whether or not a specific QoS control service is implemented at
      every hop along the path. For example, a receiver might learn that
      at least one integrated-services aware hop along the path supports
      the Controlled-Load service but not the Guaranteed service.

      - Default or global values for the general characterization
      parameters described in [RFC 2215]. These values describe
      properties of the path itself, irrespective of the selected QoS
      control service. A value reported in this section of the ADSPEC
      applies to all services unless a different, service-specific value
      is also present in the ADSPEC.

      - A service-specific value for one or more general
      characterization parameters, if the service-specific value differs
      from the default value.

      - Values of the per-service characterization parameters defined by
      each supported service.

   Data in the ADSPEC is divided into blocks or fragments, each of which
   is associated with a specific service.  This allows the adspec to
   carry information about multiple services, allows new services to be
   deployed in the future without immediately updating existing code,
   and allows an application which will never use a particular service
   to omit the ADSPEC data for that service.  The structure of the
   ADSPEC is described in detail in Section 3.3.

   A sender may indicate that a specific QoS control service should
   *not* be used by the receivers within an RSVP session.  This is done
   by omitting all mention of that service from the ADSPEC, as described
   in Section 3.3.  Upon arrival at a receiver, the complete absence of
   an ADSPEC fragment for a specific service indicates to receivers that
   the service should not be used.

      NOTE: In RSVP Version 1, all receivers within a session are
      required to choose the same QoS control service.  This restriction
      is imposed by the difficulty of merging reservations requesting
      different QoS control services, and the current lack of a general
      service replacement mechanism.  The restriction may be eliminated
      in the future.



Wroclawski                  Standards Track                     [Page 6]

RFC 2210                   RSVP with INTSERV              September 1997


      Considering this restriction, it may be useful to coordinate the
      receivers' selection of a QoS control service by having the
      sender(s) offer only one choice, using the ADSPEC mechanism
      mentioned above.  All receivers must then select the same service.
      Alternatively, the coordination might be accomplished by using a
      higher-level session announcement and setup mechanism to inform
      the receivers of the QoS control service in use, by manual
      configuration of the receivers, or by an agreement protocol
      running among the session receivers themselves.

      As with the ADSPEC, the FLOWSPEC and SENDER_TSPEC object formats
      described in Section 3 are capable of carrying TSpecs and RSpecs
      for more than one QoS control service in separate data fragments.
      Currently, use of a FLOWSPEC or SENDER_TSPEC containing fragments
      for more than one QoS control service is not supported.  In the
      future, this capability may be used to implement a more flexible
      service request and replacement scheme, allowing applications to
      obtain useful end-to-end QoS control when not all intermediate
      nodes support the same set of QoS services.  RSVP-application APIs
      should be designed to support passing SENDER_TSPEC, FLOWSPEC, and
      ADSPEC objects of variable size and containing information about
      multiple QoS control services between RSVP and its clients.

2.3. Use of ADSPEC Information

   This section gives some details about setting reservation parameters
   and the use of information conveyed by the RSVP ADSPEC object.

2.3.1. Determining the availability of a QoS control service

   The RSVP ADSPEC carries flag bits telling the application receivers
   whether or not a completely reservation-capable path exists between
   each sender and the receiver. These bits are called "break bits",
   because they indicate breaks in the QoS control along a network path.
   Break bits are carried within the header which begins each per-
   service data fragment of an RSVP ADSPEC.

   Service number 1 is used within the ADSPEC to identify a fragment
   carrying information about global parameter values that apply to all
   services (see [RFC 2215] for more details). The break bit in service
   1's per-service header is used to tell the receiver(s) whether all of
   the network elements along the path from sender to receiver support
   RSVP and integrated services.  If a receiver finds this bit set, at
   least one network element along the data transmission path between
   the ADSPEC's sender and the receiver can not provide QoS control
   services at all.  This bit corresponds to the global NON_IS_HOP
   characterization parameter defined in [RFC 2215].




Wroclawski                  Standards Track                     [Page 7]

RFC 2210                   RSVP with INTSERV              September 1997


      NOTE: If this bit is set, the values of all other parameters in
      the ADSPEC are unreliable. The bit being set indicates that at
      least one node along the sender-receiver path did not fully
      process the ADSPEC.

   Service-specific break bits tell the receiver(s) whether all of the
   network elements along the path from sender to receiver support a
   particular QoS control service.  The break bit for each service is
   carried within the ADSPEC's per-service header for that service.  If
   a bit is set at the receiver, at least one network element along the
   data transmission path supports RSVP but does not support the QoS
   control service corresponding to the per-service header.  These bits
   correspond to the service-specific NON_IS_HOP characterization
   parameters defined in [RFC 2215].

   Section 3 gives more information about break bits.

2.3.2. Determining Path MTU

   Both Guaranteed and Controlled-Load QoS control services place an
   upper bound on packet size, and require that the application limit
   the maximum size of packets subject to resource reservation. For both
   services, the desired maximum packet size is a parameter of the
   reservation request, and the service will reject (with an admission
   control error) reservation requests specifying a packet size larger
   than that supported by the service.

   Since RSVP reservation requests are made by receivers, this implies
   that the *receivers* in an RSVP session, as well as the senders, need
   to know the MTU supported by the QoS control services along a data
   path.  Further, in some unusual cases the MTU supported by a QoS
   control service may differ from that supported by the same router
   when providing best effort service.

   A scalable form of MTU negotiation is used to address these problems.
   MTU negotiation in an RSVP system works as follows:

      - Each sending application joining an RSVP session fills in the M
      (maximum packet size) parameter in its generated Sender_TSpec
      (carried from senders to receivers in a SENDER_TSPEC object) with
      the maximum packet size it wishes to send covered by resource
      reservation.

      - Each RSVP PATH message from a sending application also carries
      an ADSPEC object containing at least one PATH_MTU characterization
      parameter. When it arrives at the receiver, this parameter gives
      the minimum MTU at any point along the path from sender to
      receiver.  Generally, only the "global" PATH_MTU parameter



Wroclawski                  Standards Track                     [Page 8]

RFC 2210                   RSVP with INTSERV              September 1997


      (service 1, parameter 9) will be present, in which case its value
      is a legal MTU for all reservation requests. If a service specific
      PATH_MTU parameter is present, its value will be smaller than that
      of the global parameter, and should be used for reservation
      requests for that service.

      - Each receiver takes the minimum of all the PATH_MTU values (for
      the desired QoS control service) arriving in ADSPEC messages from
      different senders and uses that value as the MTU in its
      reservation requests.  This value is used to fill in the M
      parameter of the TSpec created at the receiver.  In the case of a
      FF style reservation, a receiver may also choose to use the MTU
      derived from each sender's ADSPEC in the FLOWSPEC generated for
      that sender, if the receiver is concerned about obtaining the
      maximum MTU on each data path. To accomodate changes in the data
      path, the receiver may continue to watch the arriving ADSPECS, and
      modify the reservation if a newly arriving ADSPEC indicates a
      smaller MTU than is currently in use.

      - As reservation requests (RESV messages) move from receivers to
      senders, reservation parameters are merged at intermediate nodes.
      As part of this merging, the smaller of two M parameters arriving
      at a merge point will be forwarded in the upstream RESV message.

      - As reservation requests arrive at intermediate RSVPs, the
      minimum of the receivers' requested TSpec and the sum of the
      sender TSpecs is taken, and a reservation for the resulting TSpec
      is made. The reservation will use the smaller of the actual path
      MTU value computed by the receivers and the largest maximum packet
      size declared by any of the sender(s). (The TSpec sum() function
      result's M parameter is the max of the summed TSpec M parameters).

      - When the completely merged RESV message arrives at each sender,
      the MTU value (M parameter) in the merged FLOWSPEC object will
      have been set to the smallest acceptable MTU of the data paths
      from that sender to any session receiver. This MTU should be used
      by the sending application to size its packets. Any packets larger
      than this MTU may be delivered as best-effort rather than being
      covered by the session's resource reservation.

      Note that senders do *not* adjust the value of their
      Sender_TSpec's M field to match the actual packet size selected in
      this step. The value of M represents the largest packet the sender
      could send, not the largest packet the sender is currently
      sending.






Wroclawski                  Standards Track                     [Page 9]

RFC 2210                   RSVP with INTSERV              September 1997


   Note that the scheme above will allow each sender in a session to use
   the largest MTU appropriate for that sender, in cases where different
   data paths or receivers have different acceptable MTU's.

3. RSVP Object Formats

   This section specifies the detailed contents and wire format of RSVP
   SENDER_TSPEC, ADSPEC, and FLOWSPEC objects for use with the
   Guaranteed and Controlled-Load QoS control services. The object
   formats specified here are based on the general message construction
   rules given in Appendix 1.

3.1. RSVP SENDER_TSPEC Object

   The RSVP SENDER_TSPEC object carries information about a data
   source's generated traffic. The required RSVP SENDER_TSPEC object
   contains a global Token_Bucket_TSpec parameter (service_number 1,
   parameter 127, as defined in [RFC 2215]). This TSpec carries traffic
   information usable by either the Guaranteed or Controlled-Load QoS
   control services.































Wroclawski                  Standards Track                    [Page 10]

RFC 2210                   RSVP with INTSERV              September 1997


        31           24 23           16 15            8 7             0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   1   | 0 (a) |    reserved           |             7 (b)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   2   |    1  (c)     |0| reserved    |             6 (d)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   3   |   127 (e)     |    0 (f)      |             5 (g)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   4   |  Token Bucket Rate [r] (32-bit IEEE floating point number)    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   5   |  Token Bucket Size [b] (32-bit IEEE floating point number)    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   6   |  Peak Data Rate [p] (32-bit IEEE floating point number)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   7   |  Minimum Policed Unit [m] (32-bit integer)                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   8   |  Maximum Packet Size [M]  (32-bit integer)                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     (a) - Message format version number (0)
     (b) - Overall length (7 words not including header)
     (c) - Service header, service number 1 (default/global information)
     (d) - Length of service 1 data, 6 words not including header
     (e) - Parameter ID, parameter 127 (Token_Bucket_TSpec)
     (f) - Parameter 127 flags (none set)
     (g) - Parameter 127 length, 5 words not including header


   In this TSpec, the parameters [r] and [b] are set to reflect the
   sender's view of its generated traffic. The peak rate parameter [p]
   may be set to the sender's peak traffic generation rate (if known and
   controlled), the physical interface line rate (if known), or positive
   infinity (if no better value is available).  Positive infinity is
   represented as an IEEE single-precision floating-point number with an
   exponent of all ones (255) and a sign and mantissa of all zeros.  The
   format of IEEE floating-point numbers is further summarized in [RFC
   1832].

   The minimum policed unit parameter [m] should generally be set equal
   to the size of the smallest packet generated by the application. This
   packet size includes the application data and all protocol headers at
   or above the IP level (IP, TCP, UDP, RTP, etc.). The size given does
   not include any link-level headers, because these headers will change
   as the packet crosses different portions of the internetwork.






Wroclawski                  Standards Track                    [Page 11]

RFC 2210                   RSVP with INTSERV              September 1997


   The [m] parameter is used by nodes within the network to compute the
   maximum bandwidth overhead needed to carry a flow's packets over the
   particular link-level technology, based on the ratio of [m] to the
   link-level header size. This allows the correct amount of bandwidth
   to be allocated to the flow at each point in the net.  Note that
   smaller values of this parameter lead to increased overhead
   estimates, and thus increased likelyhood of a reservation request
   being rejected by the node. In some cases, an application
   transmitting a low percentage of very small packets may therefore
   choose to set the value of [m] larger than the actual minimum
   transmitted packet size. This will increase the likelyhood of the
   reservation succeeding, at the expense of policing packets of size
   less than [m] as if they were of size [m].

   Note that the an [m] value of zero is illegal. A value of zero would
   indicate that no data or IP headers are present, and would give an
   infinite amount of link-level overhead.

   The maximum packet size parameter [M] should be set to the size of
   the largest packet the application might wish to generate, as
   described in Section 2.3.2. This value must, by definition, be equal
   to or larger than the value of [m].

3.2. RSVP FLOWSPEC Object

   The RSVP FLOWSPEC object carries information necessary to make
   reservation requests from the receiver(s) into the network. This
   includes an indication of which QoS control service is being
   requested, and the parameters needed for that service.

   The QoS control service requested is indicated by the service_number
   in the FLOWSPEC's per-service header.

3.2.1 FLOWSPEC object when requesting Controlled-Load service

   The format of an RSVP FLOWSPEC object originating at a receiver
   requesting Controlled-Load service is shown below. Each of the TSpec
   fields is represented using the preferred concrete representation
   specified in the 'Invocation Information' section of [RFC 2211]. The
   value of 5 in the per-service header (field (c), below) indicates
   that Controlled-Load service is being requested.










Wroclawski                  Standards Track                    [Page 12]

RFC 2210                   RSVP with INTSERV              September 1997


        31           24 23           16 15            8 7             0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   1   | 0 (a) |    reserved           |             7 (b)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   2   |    5  (c)     |0| reserved    |             6 (d)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   3   |   127 (e)     |    0 (f)      |             5 (g)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   4   |  Token Bucket Rate [r] (32-bit IEEE floating point number)    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   5   |  Token Bucket Size [b] (32-bit IEEE floating point number)    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   6   |  Peak Data Rate [p] (32-bit IEEE floating point number)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   7   |  Minimum Policed Unit [m] (32-bit integer)                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   8   |  Maximum Packet Size [M]  (32-bit integer)                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     (a) - Message format version number (0)
     (b) - Overall length (7 words not including header)
     (c) - Service header, service number 5 (Controlled-Load)
     (d) - Length of controlled-load data, 6 words not including
           per-service header
     (e) - Parameter ID, parameter 127 (Token Bucket TSpec)
     (f) - Parameter 127 flags (none set)
     (g) - Parameter 127 length, 5 words not including per-service
           header


   In this object, the TSpec parameters [r], [b], and [p] are set to
   reflect the traffic parameters of the receiver's desired reservation
   (the Reservation TSpec). The meaning of these fields is discussed
   fully in [RFC 2211]. Note that it is unlikely to make sense for the
   [p] term to be smaller than the [r] term.

   The maximum packet size parameter [M] should be set to the value of
   the smallest path MTU, which the receiver learns from information in
   arriving RSVP ADSPEC objects.  Alternatively, if the receiving
   application has built-in knowledge of the maximum packet size in use
   within the RSVP session, and this value is smaller than the smallest
   path MTU, [M] may be set to this value.  Note that requesting a value
   of [M] larger than the service modules along the data path can
   support will cause the reservation to fail. See section 2.3.2 for
   further discussion of the MTU value.






Wroclawski                  Standards Track                    [Page 13]

RFC 2210                   RSVP with INTSERV              September 1997


   The value of [m] can be chosen in several ways. Recall that when a
   resource reservation is installed at each intermediate node, the
   value used for [m] is the smaller of the receiver's request and the
   values in each sender's SENDER_TSPEC.

   If the application has a fixed, known minimum packet size, than that
   value should be used for [m]. This is the most desirable case.

   For a shared reservation style, the receiver may choose between two
   options, or pick some intermediate point between them.

      - if the receiver chooses a large value for [m], then the
      reservation will allocate less overhead for link-level headers.
      However, if a new sender with a smaller SENDER_TSPEC [m] joins the
      session later, an already-installed reservation may fail at that
      time.

      - if the receiver chooses a value of [m] equal to the smallest
      value which might be used by any sender, then the reservation will
      be forced to allocate more overhead for link-level headers.
      However it will not fail later if a new sender with a smaller
      SENDER_TSPEC [m] joins the session.

   For a FF reservation style, if no application-specific value is known
   the receiver should simply use the value of [m] arriving in each
   sender's SENDER_TSPEC for its reservation request to that sender.

3.2.2. FLOWSPEC Object when Requesting Guaranteed Service

   The format of an RSVP FLOWSPEC object originating at a receiver
   requesting Guaranteed service is shown below. The flowspec object
   used to request guaranteed service carries a TSpec and RSpec
   specifying the traffic parameters of the flow desired by the
   receiver.

   Each of the TSpec and RSpec fields is represented using the preferred
   concrete representation specified in the 'Invocation Information'
   section of [RFC 2212]. The value of 2 for the service header
   identifier (field (c) in the picture below) indicates that Guaranteed
   service is being requested.











Wroclawski                  Standards Track                    [Page 14]

RFC 2210                   RSVP with INTSERV              September 1997


        31           24 23           16 15            8 7             0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   1   | 0 (a) |    Unused             |            10 (b)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   2   |    2  (c)     |0| reserved    |             9 (d)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   3   |   127 (e)     |    0 (f)      |             5 (g)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   4   |  Token Bucket Rate [r] (32-bit IEEE floating point number)    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   5   |  Token Bucket Size [b] (32-bit IEEE floating point number)    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   6   |  Peak Data Rate [p] (32-bit IEEE floating point number)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   7   |  Minimum Policed Unit [m] (32-bit integer)                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   8   |  Maximum Packet Size [M]  (32-bit integer)                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   9   |     130 (h)   |    0 (i)      |            2 (j)              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   10  |  Rate [R]  (32-bit IEEE floating point number)                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   11  |  Slack Term [S]  (32-bit integer)                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     (a) - Message format version number (0)
     (b) - Overall length (9 words not including header)
     (c) - Service header, service number 2 (Guaranteed)
     (d) - Length of per-service data, 9 words not including per-service
           header
     (e) - Parameter ID, parameter 127 (Token Bucket TSpec)
     (f) - Parameter 127 flags (none set)
     (g) - Parameter 127 length, 5 words not including parameter header
     (h) - Parameter ID, parameter 130 (Guaranteed Service RSpec)
     (i) - Parameter 130 flags (none set)
     (j) - Parameter 130 length, 2 words not including parameter header


   In this object, the TSpec parameters [r], [b], and [p] are set to
   reflect the traffic parameters of the receiver's desired reservation
   (the Reservation TSpec). The meaning of these fields is discussed
   fully in [RFC 2212]. Note that it is unlikely to make sense for the
   [p] term to be smaller than the [r] term.

   The RSpec terms [R] and [S] are selected to obtain the desired
   bandwidth and delay guarantees. This selection is described in [RFC
   2212].




Wroclawski                  Standards Track                    [Page 15]

RFC 2210                   RSVP with INTSERV              September 1997


   The [m] and [M] parameters are set identically to those for the
   Controlled-Load service FLOWSPEC, described in the previous section.

3.3. RSVP ADSPEC Object

   An RSVP ADSPEC object is constructed from data fragments contributed
   by each service which might be used by the application.  The ADSPEC
   begins with an overall message header, followed by a fragment for the
   default general parameters, followed by fragments for every QoS
   control service which may be selected by application receivers. The
   size of the ADSPEC varies depending on the number and size of per-
   service data fragments present and the presence of non-default
   general parameters (described in Section 3.3.5).

   The complete absence of a data fragment for a particular service
   means that the application sender does not know or care about that
   service, and is a signal to intermediate nodes not to add or update
   information about that service to the ADSPEC. It is also a signal to
   application receivers that they should not select that service when
   making reservations.

   Each fragment present is identified by a per-service data header.
   Each header contains a field identifying the service, a break bit,
   and a length field.

   The length field allows the ADSPEC information for a service to be
   skipped over by a network elements which does not recognize or
   implement the service.  When an element does this, it sets the break
   bit, indicating that the service's ADSPEC data was not updated at at
   least one hop. Note that a service's break bit can be set without
   otherwise supporting the service in any way.  In all cases, a network
   element encountering a per-service data header it does not understand
   simply sets bit 23 to report that the service is not supported, then
   skips over the rest of the fragment.

   Data fragments must always appear in an ADSPEC in service_number
   order. In particular, the default general parameters fragment
   (service_number 1) always comes first.

   Within a data fragment, the service-specific data must alway come
   first, followed by any non-default general parameters which may be
   present, ordered by parameter_number. The size and structure of the
   service-specific data is fixed by the service definition, and does
   not require run-time parsing. The remainder of the fragment, which
   carries non-default general parameters, varies in size and structure
   depending on which, if any, of these parameters are present. This
   part of the fragment must be parsed by examining the per-parameter
   headers.



Wroclawski                  Standards Track                    [Page 16]

RFC 2210                   RSVP with INTSERV              September 1997


   Since the overall size of each data fragment is variable, it is
   always necessary to examine the length field to find the end of the
   fragment, rather than assuming a fixed-size structure.

   3.3.1. RSVP ADSPEC format

   The basic ADSPEC format is shown below. The message header and the
   default general parameters fragment are always present. The fragments
   for Guaranteed or Controlled-Load service may be omitted if the
   service is not to be used by the RSVP session. Additional data
   fragments will be added if new services are defined.

       31           24 23            16 15            8 7             0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | 0 (a) |      reserved         |  Msg length - 1 (b)           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |    Default General Parameters fragment (Service 1)  (c)       |
       |    (Always Present)                                           |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |    Guaranteed Service Fragment (Service 2)    (d)             |
       |    (Present if application might use Guaranteed Service)      |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |    Controlled-Load Service Fragment (Service 5)  (e)          |
       |    (Present if application might use Controlled-Load Service) |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     (a) - Message format version number (0)
     (b) - Overall message length not including header word
     (c, d, e) - Data fragments

3.3.2. Default General Characterization Parameters ADSPEC data fragment

   All RSVP ADSPECs carry the general characterization parameters
   defined in [RFC 2215].  Values for global or default general
   parameters (values which apply to the all services or the path
   itself) are carried in the per-service data fragment for service
   number 1, as shown in the picture above.  This fragment is always
   present, and always first in the message.







Wroclawski                  Standards Track                    [Page 17]

RFC 2210                   RSVP with INTSERV              September 1997


       31            24 23           16 15            8 7             0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   1   |    1  (c)     |x| reserved    |           8 (d)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   2   |    4 (e)      |    (f)        |           1 (g)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   3   |        IS hop cnt (32-bit unsigned integer)                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   4   |    6 (h)      |    (i)        |           1 (j)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   5   |  Path b/w estimate  (32-bit IEEE floating point number)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   6   |     8 (k)     |    (l)        |           1 (m)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   7   |        Minimum path latency (32-bit integer)                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   8   |     10 (n)    |      (o)      |           1 (p)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   9   |      Composed MTU (32-bit unsigned integer)                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     (c) - Per-Service header, service number 1 (Default General
           Parameters)
     (d) - Global Break bit ([RFC 2215], Parameter 2) (marked x) and
           length of General Parameters data block.
     (e) - Parameter ID, parameter 4 (Number-of-IS-hops param from
           [RFC 2215])
     (f) - Parameter 4 flag byte
     (g) - Parameter 4 length, 1 word not including header
     (h) - Parameter ID, parameter 6 (Path-BW param from [RFC 2215])
     (i) - Parameter 6 flag byte
     (j) - Parameter 6 length, 1 word not including header
     (k) - Parameter ID, parameter 8 (minimum path latency from [RFC
           2215])
     (l) - Parameter 8 flag byte
     (m) - Parameter 8 length, 1 word not including header
     (n) - Parameter ID, parameter 10 (composed path MTU from [RFC 2215])
     (o) - Parameter 10 flag byte
     (p) - Parameter 10 length, 1 word not including header


   Rules for composing general parameters appear in [RFC 2215].

   In the above fragment, the global break bit (bit 23 of word 1, marked
   with (x) in the picture) is used to indicate the existence of a
   network element not supporting QoS control services somewhere in the
   data path.  This bit is cleared when the ADSPEC is created, and set
   to one if a network element which does not support RSVP or integrated



Wroclawski                  Standards Track                    [Page 18]

RFC 2210                   RSVP with INTSERV              September 1997


   services is encountered.  An ADSPEC arriving at a receiver with this
   bit set indicates that all other parameters in the ADSPEC may be
   invalid, since not all network elements along the path support
   updating of the ADSPEC.

   The general parameters are updated at every network node which
   supports RSVP:

      - When a PATH message ADSPEC encounters a network element
      implementing integrated services, the portion of the ADSPEC
      associated with service number 1 is passed to the module
      implementing general parameters. This module updates the global
      general parameters.

      - When a PATH message ADSPEC encounters a network element that
      does *not* support RSVP or implement integrated services, the
      break bit in the general parameters service header must be set. In
      practice, this bit will usually be set by another network element
      which supports RSVP, but has been made aware of the gap in
      integrated services coverage.

      - In either case, the ADSPEC is passed back to RSVP for delivery
      to the next hop along the path.

3.3.3. Guaranteed Service ADSPEC data fragment

   The Guaranteed service uses the RSVP ADSPEC to carry data needed to
   compute the C and D terms passed from the network to the application.
   The minimum size of a non-empty guaranteed service data fragment is 8
   32-bit words.  The ADSPEC fragment for Guaranteed service has the
   following format:




















Wroclawski                  Standards Track                    [Page 19]

RFC 2210                   RSVP with INTSERV              September 1997


       31            24 23           16 15            8 7             0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   1   |     2 (a)     |x|  reserved   |             N-1 (b)           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   2   |    133 (c)    |     0 (d)     |             1 (e)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   3   |   End-to-end composed value for C [Ctot] (32-bit integer)     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   4   |     134 (f)   |       (g)     |             1 (h)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   5   |   End-to-end composed value for D [Dtot] (32-bit integer)     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   6   |     135 (i)   |       (j)     |             1 (k)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   7   | Since-last-reshaping point composed C [Csum] (32-bit integer) |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   8   |     136 (l)   |       (m)     |             1 (n)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   9   | Since-last-reshaping point composed D [Dsum] (32-bit integer) |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   10  | Service-specific general parameter headers/values, if present |
    .  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .
   N   |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     (a) - Per-Service header, service number 2 (Guaranteed)
     (b) - Break bit and Length of per-service data in 32-bit
           words not including header word.
     (c) - Parameter ID, parameter 133 (Composed Ctot)
     (d) - Parameter 133 flag byte
     (e) - Parameter 133 length, 1 word not including header
     (f) - Parameter ID, parameter 134 (Composed Dtot)
     (g) - Parameter 134 flag byte
     (h) - Parameter 134 length, 1 word not including header
     (i) - Parameter ID, parameter 135 (Composed Csum).
     (j) - Parameter 135 flag byte
     (k) - Parameter 135 length, 1 word not including header
     (l) - Parameter ID, parameter 136 (Composed Dsum).
     (m) - Parameter 136 flag byte
     (n) - Parameter 136 length, 1 word not including header

   When a node which actually implements guaranteed service creates the
   guaranteed service adspec fragment, the parameter values are set to
   the local values for each parameter. When an application or network






Wroclawski                  Standards Track                    [Page 20]

RFC 2210                   RSVP with INTSERV              September 1997


   element which does not itself implement guaranteed service creates a
   guaranteed service adspec fragment, it should set the values of each
   parameter to zero, and set the break bit to indicate that the service
   is not actually implemented at the node.

   An application or host RSVP which is creating a guaranteed service
   adspec fragment but does not itself implement the guaranteed service
   may create a truncated "empty" guaranteed adspec fragment consisting
   of only a header word:


       31            24 23           16 15            8 7             0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   1   |     2 (a)     |1|    (b)      |         0 (c)                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     (a) - Per-Service header, service number 2 (Guaranteed)
     (b) - Break bit (set, service not implemented)
     (c) - Length of per-service data in 32-bit words not
           including header word.


   This might occur if the sending application or host does not do
   resource reservation iself, but still wants the network to do so.
   Note that in this case the break bit will always be set, since the
   creator of the adspec fragment does not itself implement guaranteed
   service.

   When a PATH message ADSPEC containing a per-service header for
   Guaranteed service encounters a network element implementing
   Guaranteed service, the guaranteed service data fragment is updated:

      - If the data block in the ADSPEC is an empty (header-only) block
      the header-only fragment must first be expanded into the complete
      data fragment described above, with initial values of Ctot, Dtot,
      Csum, and Dsum set to zero. An empty fragment can be recognized
      quickly by checking for a size field of zero.  The value of the
      break bit in the header is preserved when the additional
      Guaranteed service data is added. The overall message length and
      the guaranteed-service data fragment size (field (b) in the
      pictures above) are changed to reflect the increased message
      length.

      The values of Ctot, Csum, Dtot, and Dsum in the ADSPEC data
      fragment are then composed with the local values exported by the
      network element according to the composition functions defined in
      [RFC 2212].




Wroclawski                  Standards Track                    [Page 21]

RFC 2210                   RSVP with INTSERV              September 1997


      - When a PATH message ADSPEC with a Guaranteed service header
      encounters a network element that supports RSVP but does *not*
      implement Guaranteed service, the network element sets the break
      bit in the Guaranteed service header.

      - The new values are placed in the correct fields of the ADSPEC,
      and the ADSPEC is passed back to RSVP for delivery to the next hop
      along the path.

   When a PATH message ADSPEC containing a Guaranteed service data
   fragment encounters a network element that supports RSVP but does
   *not* implement Guaranteed service, the network element sets the
   break bit in the Guaranteed service header.

   When a PATH message ADSPEC *without* a Guaranteed service header
   encounters a network element implementing Guaranteed service, the
   Guaranteed service module of the network element leaves the ADSPEC
   unchanged. The absence of a Guaranteed service per-service header in
   the ADSPEC indicates that the application does not care about
   Guaranteed service.


3.3.4. Controlled-Load Service ADSPEC data fragment

   Unlike the Guaranteed service, the Controlled-Load service does not
   require extra ADSPEC data to function correctly. The only ADSPEC data
   specific to the Controlled-Load service is the Controlled-Load break
   bit.  Therefore the usual Controlled-Load service data block contains
   no extra information. The minimum size of the controlled-load service
   data fragment is 1 32-bit word.



       31            24 23           16 15            8 7             0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   1   |     5 (a)     |x|  (b)        |            N-1 (c)            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   2   | Service-specific general parameter headers/values, if present |
    .  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .
   N   |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     (a) - Per-Service header, service number 5 (Controlled-Load)
     (b) - Break bit
     (c) - Length of per-service data in 32 bit words not including
           header word.





Wroclawski                  Standards Track                    [Page 22]

RFC 2210                   RSVP with INTSERV              September 1997


   The Controlled-Load portion of the ADSPEC is processed according to
   the following rules:

      - When a PATH message ADSPEC with a Controlled-Load service header
      encounters a network element implementing Controlled-Load service,
      the network element makes no changes to the service header.

      - When a PATH message ADSPEC with a Controlled-Load service header
      encounters a network element that supports RSVP but does *not*
      implement Controlled-Load service, the network element sets the
      break bit in the Controlled-Load service header.

      - In either case, the ADSPEC is passed back to RSVP for delivery
      to the next hop along the path.

3.3.5. Overriding Global ADSPEC Data with Service-Specific Information

   In some cases, the default values for the general parameters are not
   correct for a particular service. For example, an implementation of
   Guaranteed service may accept only packets with a smaller maximum
   size than the link MTU, or the percentage of outgoing link bandwidth
   made available to the Controlled-Load service at a network element
   may be administratively limited to less than the overall bandwidth.

   In these cases, a service-specific value, as well as the default
   value, is reported to the receiver receiving the ADSPEC.  Service-
   specific information which overrides general information is carried
   by a parameter with the same name as the general parameter, placed
   within the data fragment of the QoS control service to which it
   applies. These service-specific values are referred to as override or
   service-specific general parameters.

   For example, the following Controlled-Load ADSPEC fragment carries
   information overriding the global path bandwidth estimate with a
   different value:
















Wroclawski                  Standards Track                    [Page 23]

RFC 2210                   RSVP with INTSERV              September 1997


       31           24 23           16 15            8 7             0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   1   |     5 (a)     |x| (b)         |             2 (c)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   2   |     6 (d)     |      0 (d)    |             1 (e)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   3   |  Path b/w estimate for C-L service (32b IEEE FP number)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     (a) - Per-Service header, service number 5 (Controlled-Load)
     (b) - Break bit
     (c) - Length of per-service data, two words not including header
     (c) - Parameter ID, parameter 6
           (AVAILABLE_PATH_BANDWIDTH general parameter from [RFC 2215])
     (d) - Parameter 6 flags (none set)
     (e) - Parameter 6 length, one word not including header


   The presence of override parameters in a data fragment can be quickly
   detected by examining the fragment's length field, which will be
   larger than the "standard" length for the fragment.  Specific
   override parameters can be easily identified by examining the
   parameter headers, because they have parameter_number's from the
   general parameter portion of the number space (1-127), but are found
   in service-specific data blocks (those with service_numbers between 2
   and 254 in the per_service header field).

   The presence of override parameters in a data fragment is optional. A
   parameter header/value pair is added only when a particular
   application or QoS control service wishes to override the global
   value of a general parameter with a service-specific value.

   As with IP options, it is only the use of these override parameters
   that is optional. All implementations must be prepared to receive and
   process override parameters.

   The basic principle for handling override parameters is to use the
   override value (local or adspec) if it exists, and to use the default
   value otherwise. If a local node exports an override value for a
   general parameter, but there is no override value in the arriving
   adspec, the local node adds it. The following pseudo-code fragment
   gives more detail:









Wroclawski                  Standards Track                    [Page 24]

RFC 2210                   RSVP with INTSERV              September 1997


   /* Adspec parameter processing rules *

   <get arriving ADSPEC from RSVP>

   for ( <each service number N with a fragment in the ADSPEC> ) {
     if ( <the local node does not support the service> ) {
       <set the break bit in the service header>
     } else {
       for ( <each parameter in the data fragment for service N> ) {
         if ( < the local service N supplies a value for the parameter> ) {
            <compose the arriving and values and update the adspec>
         } else {
            /* Must be a general parameter, or service N would have
             * supplied a value..
             */
            <compose the arriving value with the local default value
             and update the adspec>
         }
       }
       for ( <any parameters supplied by the local service N
             implementation but not found in the adspec> ) {
            /*
             * Must be an override value for a general parameter,
             * or the adspec would have contained a value..
             */
            <compose the local override value with the arriving default
             value (from the service 1 data fragment) and add the parameter
             to the adspec's service N fragment in parameter_number order>
       }
     }
   }

   <pass updated ADSPEC back to RSVP>

   In practice, the two 'for' loops can be combined. Since override
   parameters within a service's fragment are transmitted in numerical
   order, it is possible to determine whether a parameter is present
   without scanning the entire fragment. Also, because the data
   fragments are ordered by service_number, the default values for
   general parameters will always be read before they might be needed to
   update local override values in the second for loop.

3.3.6. Example

   The picture below shows the complete adspec for an application which
   can use either controlled-load or guaranteed service. In the example,





Wroclawski                  Standards Track                    [Page 25]

RFC 2210                   RSVP with INTSERV              September 1997


   data fragments are present for general parameters, guaranteed, and
   controlled-load services. All fragments are of standard size, and
   there are no override parameters present.


       31            24 23           16 15            8 7             0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   1   | 0 (a) |    Unused             |          19 (b)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   2   |    1  (c)     |x| reserved (d)|           8 (e)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   3   |    4 (f)      |    (g)        |           1 (h)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   4   |  zero extension of ..           IS hop cnt (16-bit unsigned)  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   5   |    6 (i)      |    (j)        |           1 (k)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   6   |  Path b/w estimate  (32-bit IEEE floating point number)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   7   |     8 (l)     |    (m)        |           1 (n)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   8   |        Minimum path latency (32-bit integer)                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   9   |     10 (o)    |      (p)      |           1 (q)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   10  |  zero extension of ..        composed MTU (16-bit unsigned)   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   11  |     2 (r)     |x| reserved (s)|             8 (t)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   12  |    133 (u)    |       (v)     |             1 (w)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   13  |   End-to-end composed value for C [Ctot] (32-bit integer)     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   14  |     134 (x)   |       (y)     |             1 (z)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   15  |   End-to-end composed value for D [Dtot] (32-bit integer)     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   16  |     135 (aa   |       (bb     |             1 (cc)            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   17  | Since-last-reshaping point composed C [Csum] (32-bit integer) |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   18  |     136 (dd)  |       (ee)    |             1 (ff)            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   19  | Since-last-reshaping point composed D [Dsum] (32-bit integer) |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   20  |     5 (gg     |x   0  (hh)    |             0 (ii)            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Wroclawski                  Standards Track                    [Page 26]

RFC 2210                   RSVP with INTSERV              September 1997


     Word 1: Message Header:
     (a) - Message header and version number
     (b) - Message length - 19 words not including header

     Words 2-7: Default general characterization parameters
     (c) - Per-Service header, service number 1
           (Default General Parameters)
     (d) - Global Break bit (NON_IS_HOP general parameter 2) (marked x)
     (e) - Length of General Parameters data block (8 words)
     (f) - Parameter ID, parameter 4 (NUMBER_OF_IS_HOPS
           general parameter)
     (g) - Parameter 4 flag byte
     (h) - Parameter 4 length, 1 word not including header
     (i) - Parameter ID, parameter 6 (AVAILABLE_PATH_BANDWIDTH
           general parameter)
     (j) - Parameter 6 flag byte
     (k) - Parameter 6 length, 1 word not including header
     (l) - Parameter ID, parameter 8 (MINIMUM_PATH_LATENCY
           general parameter)
     (m) - Parameter 8 flag byte
     (n) - Parameter 8 length, 1 word not including header
     (o) - Parameter ID, parameter 10 (PATH_MTU general parameter)
     (p) - Parameter 10 flag byte
     (q) - Parameter 10 length, 1 word not including header

     Words 11-19: Guaranteed service parameters
     (r) - Per-Service header, service number 2 (Guaranteed)
     (s) - Break bit
     (t) - Length of per-service data, 8 words not including header
     (u) - Parameter ID, parameter 133 (Composed Ctot)
     (v) - Composed Ctot flag byte
     (w) - Composed Ctot length, 1 word not including header
     (x) - Parameter ID, parameter 134 (Composed Dtot)
     (y) - Composed Dtot flag byte
     (z) - Composed Dtot length, 1 word not including header
     (aa)- Parameter ID, parameter 135 (Composed Csum).
     (bb)- Composed Csum flag byte
     (cc)- Composed Csum length, 1 word not including header
     (dd)- Parameter ID, parameter 136 (Composed Dsum).
     (ee)- Composed Dsum flag byte
     (ff)- Composed Dsum length, 1 word not including header

     Word 20: Controlled-Load parameters
     (gg - Per-Service header, service number 5 (Controlled-Load)
     (hh)- Break bit
     (ii)- Length of controlled-load data, 0 words not including header





Wroclawski                  Standards Track                    [Page 27]

RFC 2210                   RSVP with INTSERV              September 1997


4. Security Considerations

   The message formatting and usage rules described in this note raise
   no security issues. The overall use of these rules to implement
   multiple qualities of service using RSVP and integrated services
   scheduling modules introduces a new security requirement; the need to
   control and authenticate access to enhanced qualities of service.
   This requirement is discussed further in [RFC 2205], [RFC 2212], and
   [RFC 2211]. [RFCRSVPMD5] describes the mechanism used to protect the
   integrity of RSVP messages carrying the information described here.









































Wroclawski                  Standards Track                    [Page 28]

RFC 2210                   RSVP with INTSERV              September 1997


Appendix 1: Message construction rules

   This section gives the rule used to generate the object formats of
   Section 3. It is a general wire format for encoding integrated
   services data objects within setup and management protocol messages.
   The format has a three-level structure:

      - An overall message header carries a version number and message
      length.  Providing this header in a standard format allows the
      same code library to handle data objects carried by multiple setup
      protocols.

      - Per-service fragments carry information about a specific QoS
      control service, such as guaranteed [RFC 2212] or controlled load
      [RFC 2211]. Each per-service fragment carries one or more
      parameters.  The set of parameters present in a fragment is
      determined by the needs of the protocol in use. Examples are given
      in Section 2.

      - Parameters are the actual data used to control or monitor a
      service. A parameter may be a single quantity such as an integer,
      or a composite data structure such as a TSpec. The parameters
      specific to a service are defined by the service specification.
      The available general parameters, with definitions shared by many
      services, are defined by [RFC 2215].


























Wroclawski                  Standards Track                    [Page 29]

RFC 2210                   RSVP with INTSERV              September 1997


A1.1. Message Header

   The 32-bit message header specifies the message format version number
   and total length of the message. The overall message must be aligned
   to a 32-bit boundary within the transport protocol's data packet.
   The message length is measured in 32-bit words *not including the
   word containing the header*. This is to lower the probability of an
   accidentally cleared word resulting in an infinite loop in the
   message parser.

   The Message Header is represented by a 32-bit bitfield laid out as
   shown below and then encoded as an XDR unsigned integer. Encoding as
   an XDR unsigned integer is equivalent to converting the bitfield from
   the machine's native format to big-endian network byte order.

   Message Header

       MSB                                                           LSB
       31    28 27                   16 15                            0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   V   |    Unused             |     OVERALL LENGTH            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   V               - Message format version; currently 0
   OVERALL LENGTH  - Message length in 32-bit words not including header


























Wroclawski                  Standards Track                    [Page 30]

RFC 2210                   RSVP with INTSERV              September 1997


A1.2. Per-Service Data Header

   The message header is followed by one or more service-specific data
   blocks, each containing the data associated with a specific QoS
   control service. Each service-specific data block begins with an
   identifying header. This 32-bit header contains the service number, a
   one-bit flag (the "break bit", because it indicates a break in the
   QoS control path) and a length field. The length field specifies the
   number of 32-bit words used to hold data specific to this service as
   a count of 32-bit words *not including the word containing the
   header*.

   The break bit, if set, indicates that the service specified by the
   header was unsupported or unrecognized at some point in the message's
   path through the network. This bit corresponds to the general
   parameter NON_IS_HOP defined in [RFC 2215]. It is cleared when a
   message is first generated, and set whenever the message passes
   through an element that does not recognize the service_number in the
   per-service header.

   The Per-Service Data Header is represented by a 32-bit bitfield laid
   out as shown below and then encoded as an XDR unsigned integer.

   Per-Service Data Header

       MSB                                                           LSB
       31            24 23           16 15                            0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  SVC_NUMBER   |B| Reserved    |            SVC_LENGTH         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   SVC_NUMBER      - Service ID number (defined in service specification).
   B               - Break bit - service unsupported/break in path.
   SVC_LENGTH      - Service-specific data length in 32-bit words,
                     not including header.















Wroclawski                  Standards Track                    [Page 31]

RFC 2210                   RSVP with INTSERV              September 1997


A1.3. Parameter Header

   The per-service header is followed by one or more service parameter
   blocks, each identified by a Parameter Header. This header contains
   the parameter identifier (parameter number), the length of the data
   carrying the parameter's value, and a flag field. The data field(s)
   of the parameter follow.  The parameter number, as well as the
   meaning and format of the data words following the header, are given
   by the specification which defines the parameter.

   The Parameter Header is represented by a 32-bit bitfield laid out as
   shown below and then encoded as an XDR unsigned integer.


   Parameter Header

       MSB                                                           LSB
       31            24 23           16 15                            0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  PARAM_NUM    |I   FLAGS      |         PARAM_LENGTH          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   PARAM_NUM       - Parameter number (defined in service specification)
   FLAGS           - Per-parameter flags
   PARAM_LENGTH    - Length of per-parameter data in 32-bit words, not
                     including the header word.

   The following flags are currently defined in the FLAGS field:

   I (bit 23)      - INVALID

                     This flag indicates that the parameter value was
                     not correctly processed at one or more network
                     elements along a data path.  It is intended for use
                     in a possible future service composition scheme.

   Other bits in the FLAGS field of the parameter header are currently
   reserved, and should be set to zero.













Wroclawski                  Standards Track                    [Page 32]

RFC 2210                   RSVP with INTSERV              September 1997


A1.4. Parameter Data

   Following the Parameter Header is the actual data representing the
   parameter value. Parameter values are encoded into one or more 32-bit
   words using the XDR external data representation described in [RFC
   1832], and the resulting words are placed in the message.

   The document defining a parameter should provide an XDR description
   of the parameter's data fields. If it does not, a description should
   be provided in this note.

References

   [RFC 2205] Braden, B., Ed., et. al., "Resource Reservation Protocol
   (RSVP) - Version 1 Functional Specification", RFC 2205, September
   1997.

   [RFC 2216] Shenker, S., and J. Wroclawski. "Network Element QoS
   Control Service Specification Template", RFC 2216, September 1997.

   [RFC 2212] Shenker, S., Partridge, C., and R Guerin, "Specification
   of Guaranteed Quality of Service", RFC 2212, September 1997.

   [RFC 2211] Wroclawski, J., "Specification of the Controlled Load
   Quality of Service", RFC 2211, September 1997.

   [RFC 2215] Shenker, S., and J. Wroclawski, "General Characterization
   Parameters for Integrated Service Network Elements", RFC 2215,
   September 1997.

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

   [RFC 1832] Srinivansan, R., "XDR: External Data Representation
   Standard", RFC 1832, August 1995.

Author's Address

   John Wroclawski
   MIT Laboratory for Computer Science
   545 Technology Sq.
   Cambridge, MA  02139

   Phone: 617-253-7885
   Fax:   617-253-2673 (FAX)
   EMail: jtw@lcs.mit.edu





Wroclawski                  Standards Track                    [Page 33]