File: rfc2382.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites:
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1683 lines) | stat: -rw-r--r-- 73,870 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683






Network Working Group                                 E. Crawley, Editor
Request for Comments: 2382                                Argon Networks
Category: Informational                                        L. Berger
                                                            Fore Systems
                                                               S. Berson
                                                                    ISI
                                                                F. Baker
                                                           Cisco Systems
                                                               M. Borden
                                                            Bay Networks
                                                             J. Krawczyk
                                               ArrowPoint Communications
                                                             August 1998


         A Framework for Integrated Services and RSVP over ATM

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

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

Abstract

   This document outlines the issues and framework related to providing
   IP Integrated Services with RSVP over ATM. It provides an overall
   approach to the problem(s) and related issues.  These issues and
   problems are to be addressed in further documents from the ISATM
   subgroup of the ISSLL working group.

1. Introduction

   The Internet currently has one class of service normally referred to
   as "best effort."  This service is typified by first-come, first-
   serve scheduling at each hop in the network.  Best effort service has
   worked well for electronic mail, World Wide Web (WWW) access, file
   transfer (e.g. ftp), etc.  For real-time traffic such as voice and
   video, the current Internet has performed well only across unloaded
   portions of the network.  In order to provide quality real-time
   traffic, new classes of service and a QoS signalling protocol are






Crawley, et. al.             Informational                      [Page 1]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


   being introduced in the Internet [1,6,7], while retaining the
   existing best effort service.  The QoS signalling protocol is RSVP
   [1], the Resource ReSerVation Protocol and the service models

   One of the important features of ATM technology is the ability to
   request a point-to-point Virtual Circuit (VC) with a specified
   Quality of Service (QoS).  An additional feature of ATM technology is
   the ability to request point-to-multipoint VCs with a specified QoS.
   Point-to-multipoint VCs allows leaf nodes to be added and removed
   from the VC dynamically and so provides a mechanism for supporting IP
   multicast. It is only natural that RSVP and the Internet Integrated
   Services (IIS) model would like to utilize the QoS properties of any
   underlying link layer including ATM, and this memo concentrates on
   ATM.

   Classical IP over ATM [10] has solved part of this problem,
   supporting IP unicast best effort traffic over ATM.  Classical IP
   over ATM is based on a Logical IP Subnetwork (LIS), which is a
   separately administered IP subnetwork.  Hosts within an LIS
   communicate using the ATM network, while hosts from different subnets
   communicate only by going through an IP router (even though it may be
   possible to open a direct VC between the two hosts over the ATM
   network).  Classical IP over ATM provides an Address Resolution
   Protocol (ATMARP) for ATM edge devices to resolve IP addresses to
   native ATM addresses.  For any pair of IP/ATM edge devices (i.e.
   hosts or routers), a single VC is created on demand and shared for
   all traffic between the two devices.  A second part of the RSVP and
   IIS over ATM problem, IP multicast, is being solved with MARS [5],
   the Multicast Address Resolution Server.

   MARS compliments ATMARP by allowing an IP address to resolve into a
   list of native ATM addresses, rather than just a single address.

   The ATM Forum's LAN Emulation (LANE) [17, 20] and Multiprotocol Over
   ATM (MPOA) [18] also address the support of IP best effort traffic
   over ATM through similar means.

   A key remaining issue for IP in an ATM environment is the integration
   of RSVP signalling and ATM signalling in support of the Internet
   Integrated Services (IIS) model.  There are two main areas involved
   in supporting the IIS model, QoS translation and VC management. QoS
   translation concerns mapping a QoS from the IIS model to a proper ATM
   QoS, while VC management concentrates on how many VCs are needed and
   which traffic flows are routed over which VCs.







Crawley, et. al.             Informational                      [Page 2]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


1.1 Structure and Related Documents

   This document provides a guide to the issues for IIS over ATM.  It is
   intended to frame the problems that are to be addressed in further
   documents. In this document, the modes and models for RSVP operation
   over ATM will be discussed followed by a discussion of management of
   ATM VCs for RSVP data and control. Lastly, the topic of
   encapsulations will be discussed in relation to the models presented.

   This document is part of a group of documents from the ISATM subgroup
   of the ISSLL working group related to the operation of IntServ and
   RSVP over ATM.  [14] discusses the mapping of the IntServ models for
   Controlled Load and Guaranteed Service to ATM.  [15 and 16] discuss
   detailed implementation requirements and guidelines for RSVP over
   ATM, respectively.  While these documents may not address all the
   issues raised in this document, they should provide enough
   information for development of solutions for IntServ and RSVP over
   ATM.

1.2 Terms

   Several term used in this document are used in many contexts, often
   with different meaning.  These terms are used in this document with
   the following meaning:

   - Sender is used in this document to mean the ingress point to the
     ATM network or "cloud".
   - Receiver is used in this document to refer to the egress point from
     the ATM network or "cloud".
   - Reservation is used in this document to refer to an RSVP initiated
     request for resources. RSVP initiates requests for resources based
     on RESV message processing. RESV messages that simply refresh state
     do not trigger resource requests.  Resource requests may be made
     based on RSVP sessions and RSVP reservation styles.  RSVP styles
     dictate whether the reserved resources are used by one sender or
     shared by multiple senders. See [1] for details of each. Each new
     request is referred to in this document as an RSVP reservation, or
     simply reservation.
   - Flow is used to refer to the data traffic associated with a
     particular reservation.  The specific meaning of flow is RSVP style
     dependent. For shared style reservations, there is one flow per
     session. For distinct style reservations, there is one flow per
     sender (per session).

2. Issues Regarding the Operation of RSVP and IntServ over ATM

   The issues related to RSVP and IntServ over ATM fall into several
   general classes:



Crawley, et. al.             Informational                      [Page 3]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


   - How to make RSVP run over ATM now and in the future
   - When to set up a virtual circuit (VC) for a specific Quality of
     Service (QoS) related to RSVP
   - How to map the IntServ models to ATM QoS models
   - How to know that an ATM network is providing the QoS necessary for
     a flow
   - How to handle the many-to-many connectionless features of IP
     multicast and RSVP in the one-to-many connection-oriented world of
     ATM

2.1 Modes/Models for RSVP and IntServ over ATM

   [3] Discusses several different models for running IP over ATM
   networks.  [17, 18, and 20] also provide models for IP in ATM
   environments.  Any one of these models would work as long as the RSVP
   control packets (IP protocol 46) and data packets can follow the same
   IP path through the network.  It is important that the RSVP PATH
   messages follow the same IP path as the data such that appropriate
   PATH state may be installed in the routers along the path.  For an
   ATM subnetwork, this means the ingress and egress points must be the
   same in both directions for the RSVP control and data messages.  Note
   that the RSVP protocol does not require symmetric routing.  The PATH
   state installed by RSVP allows the RESV messages to "retrace" the
   hops that the PATH message crossed.  Within each of the models for IP
   over ATM, there are decisions about using different types of data
   distribution in ATM as well as different connection initiation.  The
   following sections look at some of the different ways QoS connections
   can be set up for RSVP.

2.1.1 UNI 3.x and 4.0

   In the User Network Interface (UNI) 3.0 and 3.1 specifications [8,9]
   and 4.0 specification, both permanent and switched virtual circuits
   (PVC and SVC) may be established with a specified service category
   (CBR, VBR, and UBR for UNI 3.x and VBR-rt and ABR for 4.0) and
   specific traffic descriptors in point-to-point and point-to-
   multipoint configurations.  Additional QoS parameters are not
   available in UNI 3.x and those that are available are vendor-
   specific.  Consequently, the level of QoS control available in
   standard UNI 3.x networks is somewhat limited.  However, using these
   building blocks, it is possible to use RSVP and the IntServ models.
   ATM 4.0 with the Traffic Management (TM) 4.0 specification [21]
   allows much greater control of QoS.  [14] provides the details of
   mapping the IntServ models to UNI 3.x and 4.0 service categories and
   traffic parameters.






Crawley, et. al.             Informational                      [Page 4]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


2.1.1.1 Permanent Virtual Circuits (PVCs)

   PVCs emulate dedicated point-to-point lines in a network, so the
   operation of RSVP can be identical to the operation over any point-
   to-point network.  The QoS of the PVC must be consistent and
   equivalent to the type of traffic and service model used.  The
   devices on either end of the PVC have to provide traffic control
   services in order to multiplex multiple flows over the same PVC.
   With PVCs, there is no issue of when or how long it takes to set up
   VCs, since they are made in advance but the resources of the PVC are
   limited to what has been pre-allocated.  PVCs that are not fully
   utilized can tie up ATM network resources that could be used for
   SVCs.

   An additional issue for using PVCs is one of network engineering.
   Frequently, multiple PVCs are set up such that if all the PVCs were
   running at full capacity, the link would be over-subscribed.  This
   frequently used "statistical multiplexing gain" makes providing IIS
   over PVCs very difficult and unreliable.  Any application of IIS over
   PVCs has to be assured that the PVCs are able to receive all the
   requested QoS.

2.1.1.2 Switched Virtual Circuits (SVCs)

   SVCs allow paths in the ATM network to be set up "on demand".  This
   allows flexibility in the use of RSVP over ATM along with some
   complexity.  Parallel VCs can be set up to allow best-effort and
   better service class paths through the network, as shown in Figure 1.
   The cost and time to set up SVCs can impact their use.  For example,
   it may be better to initially route QoS traffic over existing VCs
   until a SVC with the desired QoS can be set up for the flow.  Scaling
   issues can come into play if a single RSVP flow is used per VC, as
   will be discussed in Section 4.3.1.1. The number of VCs in any ATM
   device may also be limited so the number of RSVP flows that can be
   supported by a device can be strictly limited to the number of VCs
   available, if we assume one flow per VC.  Section 4 discusses the
   topic of VC management for RSVP in greater detail.














Crawley, et. al.             Informational                      [Page 5]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


                             Data Flow ==========>

                     +-----+
                     |     |      -------------->  +----+
                     | Src |    -------------->    | R1 |
                     |    *|  -------------->      +----+
                     +-----+       QoS VCs
                          /\
                          ||
                      VC  ||
                      Initiator

                    Figure 1: Data Flow VC Initiation

   While RSVP is receiver oriented, ATM is sender oriented.  This might
   seem like a problem but the sender or ingress point receives RSVP
   RESV messages and can determine whether a new VC has to be set up to
   the destination or egress point.

2.1.1.3 Point to MultiPoint

   In order to provide QoS for IP multicast, an important feature of
   RSVP, data flows must be distributed to multiple destinations from a
   given source.  Point-to-multipoint VCs provide such a mechanism.  It
   is important to map the actions of IP multicasting and RSVP (e.g.
   IGMP JOIN/LEAVE and RSVP RESV/RESV TEAR) to add party and drop party
   functions for ATM.  Point-to-multipoint VCs as defined in UNI 3.x and
   UNI 4.0 have a single service class for all destinations.  This is
   contrary to the RSVP "heterogeneous receiver" concept.  It is
   possible to set up a different VC to each receiver requesting a
   different QoS, as shown in Figure 2. This again can run into scaling
   and resource problems when managing multiple VCs on the same
   interface to different destinations.


















Crawley, et. al.             Informational                      [Page 6]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


                                    +----+
                           +------> | R1 |
                           |        +----+
                           |
                           |        +----+
              +-----+ -----+   +--> | R2 |
              |     | ---------+    +----+  Receiver Request Types:
              | Src |                       ---->  QoS 1 and QoS 2
              |     | .........+    +----+  ....>  Best-Effort
              +-----+ .....+   +..> | R3 |
                           :        +----+
                       /\  :
                       ||  :        +----+
                       ||  +......> | R4 |
                       ||           +----+
                     Single
                  IP Multicast
                     Group

                    Figure 2: Types of Multicast Receivers

   RSVP sends messages both up and down the multicast distribution tree.
   In the case of a large ATM cloud, this could result in a RSVP message
   implosion at an ATM ingress point with many receivers.

   ATM 4.0 expands on the point-to-multipoint VCs by adding a Leaf
   Initiated Join (LIJ) capability. LIJ allows an ATM end point to join
   into an existing point-to-multipoint VC without necessarily
   contacting the source of the VC.  This can reduce the burden on the
   ATM source point for setting up new branches and more closely matches
   the receiver-based model of RSVP and IP multicast.  However, many of
   the same scaling issues exist and the new branches added to a point-
   to-multipoint VC must use the same QoS as existing branches.

2.1.1.4 Multicast Servers

   IP-over-ATM has the concept of a multicast server or reflector that
   can accept cells from multiple senders and send them via a point-to-
   multipoint VC to a set of receivers.  This moves the VC scaling
   issues noted previously for point-to-multipoint VCs to the multicast
   server.  Additionally, the multicast server will need to know how to
   interpret RSVP packets or receive instruction from another node so it
   will be able to provide VCs of the appropriate QoS for the RSVP
   flows.







Crawley, et. al.             Informational                      [Page 7]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


2.1.2 Hop-by-Hop vs. Short Cut

   If the ATM "cloud" is made up a number of logical IP subnets (LISs),
   then it is possible to use "short cuts" from a node on one LIS
   directly to a node on another LIS, avoiding router hops between the
   LISs. NHRP [4], is one mechanism for determining the ATM address of
   the egress point on the ATM network given a destination IP address.
   It is a topic for further study to determine if significant benefit
   is achieved from short cut routes vs. the extra state required.

2.1.3 Future Models

   ATM is constantly evolving.  If we assume that RSVP and IntServ
   applications are going to be wide-spread, it makes sense to consider
   changes to ATM that would improve the operation of RSVP and IntServ
   over ATM.  Similarly, the RSVP protocol and IntServ models will
   continue to evolve and changes that affect them should also be
   considered.  The following are a few ideas that have been discussed
   that would make the integration of the IntServ models and RSVP easier
   or more complete.  They are presented here to encourage continued
   development and discussion of ideas that can help aid in the
   integration of RSVP, IntServ, and ATM.

2.1.3.1 Heterogeneous Point-to-MultiPoint

   The IntServ models and RSVP support the idea of "heterogeneous
   receivers"; e.g., not all receivers of a particular multicast flow
   are required to ask for the same QoS from the network, as shown in
   Figure 2.

   The most important scenario that can utilize this feature occurs when
   some receivers in an RSVP session ask for a specific QoS while others
   receive the flow with a best-effort service.  In some cases where
   there are multiple senders on a shared-reservation flow (e.g., an
   audio conference), an individual receiver only needs to reserve
   enough resources to receive one sender at a time.  However, other
   receivers may elect to reserve more resources, perhaps to allow for
   some amount of "over-speaking" or in order to record the conference
   (post processing during playback can separate the senders by their
   source addresses).

   In order to prevent denial-of-service attacks via reservations, the
   service models do not allow the service elements to simply drop non-
   conforming packets.  For example, Controlled Load service model [7]
   assigns non-conformant packets to best-effort status (which may
   result in packet drops if there is congestion).





Crawley, et. al.             Informational                      [Page 8]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


   Emulating these behaviors over an ATM network is problematic and
   needs to be studied.  If a single maximum QoS is used over a point-
   to-multipoint VC, resources could be wasted if cells are sent over
   certain links where the reassembled packets will eventually be
   dropped.  In addition, the "maximum QoS" may actually cause a
   degradation in service to the best-effort branches.

   The term "variegated VC" has been coined to describe a point-to-
   multipoint VC that allows a different QoS on each branch.  This
   approach seems to match the spirit of the Integrated Service and RSVP
   models, but some thought has to be put into the cell drop strategy
   when traversing from a "bigger" branch to a "smaller" one.  The
   "best-effort for non-conforming packets" behavior must also be
   retained.  Early Packet Discard (EPD) schemes must be used so that
   all the cells for a given packet can be discarded at the same time
   rather than discarding only a few cells from several packets making
   all the packets useless to the receivers.

2.1.3.2 Lightweight Signalling

   Q.2931 signalling is very complete and carries with it a significant
   burden for signalling in all possible public and private connections.
   It might be worth investigating a lighter weight signalling mechanism
   for faster connection setup in private networks.

2.1.3.3 QoS Renegotiation

   Another change that would help RSVP over ATM is the ability to
   request a different QoS for an active VC.  This would eliminate the
   need to setup and tear down VCs as the QoS changed.  RSVP allows
   receivers to change their reservations and senders to change their
   traffic descriptors dynamically.  This, along with the merging of
   reservations, can create a situation where the QoS needs of a VC can
   change.  Allowing changes to the QoS of an existing VC would allow
   these features to work without creating a new VC.  In the ITU-T ATM
   specifications [24,25], some cell rates can be renegotiated or
   changed.  Specifically, the Peak Cell Rate (PCR) of an existing VC
   can be changed and, in some cases, QoS parameters may be renegotiated
   during the call setup phase. It is unclear if this is sufficient for
   the QoS renegotiation needs of the IntServ models.

2.1.3.4 Group Addressing

   The model of one-to-many communications provided by point-to-
   multipoint VCs does not really match the many-to-many communications
   provided by IP multicasting.  A scaleable mapping from IP multicast
   addresses to an ATM "group address" can address this problem.




Crawley, et. al.             Informational                      [Page 9]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


2.1.3.5 Label Switching

   The MultiProtocol Label Switching (MPLS) working group is discussing
   methods for optimizing the use of ATM and other switched networks for
   IP by encapsulating the data with a header that is used by the
   interior switches to achieve faster forwarding lookups.  [22]
   discusses a framework for this work.  It is unclear how this work
   will affect IntServ and RSVP over label switched networks but there
   may be some interactions.

2.1.4 QoS Routing

   RSVP is explicitly not a routing protocol.  However, since it conveys
   QoS information, it may prove to be a valuable input to a routing
   protocol that can make path determinations based on QoS and network
   load information.  In other words, instead of asking for just the IP
   next hop for a given destination address, it might be worthwhile for
   RSVP to provide information on the QoS needs of the flow if routing
   has the ability to use this information in order to determine a
   route.  Other forms of QoS routing have existed in the past such as
   using the IP TOS and Precedence bits to select a path through the
   network.  Some have discussed using these same bits to select one of
   a set of parallel ATM VCs as a form of QoS routing.  ATM routing has
   also considered the problem of QoS routing through the Private
   Network-to-Network Interface (PNNI) [26] routing protocol for routing
   ATM VCs on a path that can support their needs.  The work in this
   area is just starting and there are numerous issues to consider.
   [23], as part of the work of the QoSR working group frame the issues
   for QoS Routing in the Internet.

2.2 Reliance on Unicast and Multicast Routing

   RSVP was designed to support both unicast and IP multicast
   applications.  This means that RSVP needs to work closely with
   multicast and unicast routing.  Unicast routing over ATM has been
   addressed [10] and [11].  MARS [5] provides multicast address
   resolution for IP over ATM networks, an important part of the
   solution for multicast but still relies on multicast routing
   protocols to connect multicast senders and receivers on different
   subnets.

2.3 Aggregation of Flows

   Some of the scaling issues noted in previous sections can be
   addressed by aggregating several RSVP flows over a single VC if the
   destinations of the VC match for all the flows being aggregated.
   However, this causes considerable complexity in the management of VCs
   and in the scheduling of packets within each VC at the root point of



Crawley, et. al.             Informational                     [Page 10]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


   the VC.  Note that the rescheduling of flows within a VC is not
   possible in the switches in the core of the ATM network. Virtual
   Paths (VPs) can be used for aggregating multiple VCs. This topic is
   discussed in greater detail as it applies to multicast data
   distribution in section 4.2.3.4

2.4 Mapping QoS Parameters

   The mapping of QoS parameters from the IntServ models to the ATM
   service classes is an important issue in making RSVP and IntServ work
   over ATM.  [14] addresses these issues very completely for the
   Controlled Load and Guaranteed Service models.  An additional issue
   is that while some guidelines can be developed for mapping the
   parameters of a given service model to the traffic descriptors of an
   ATM traffic class, implementation variables, policy, and cost factors
   can make strict mapping problematic.  So, a set of workable mappings
   that can be applied to different network requirements and scenarios
   is needed as long as the mappings can satisfy the needs of the
   service model(s).

2.5 Directly Connected ATM Hosts

   It is obvious that the needs of hosts that are directly connected to
   ATM networks must be considered for RSVP and IntServ over ATM.
   Functionality for RSVP over ATM must not assume that an ATM host has
   all the functionality of a router, but such things as MARS and NHRP
   clients would be worthwhile features.  A host must manage VCs just
   like any other ATM sender or receiver as described later in section
   4.

2.6 Accounting and Policy Issues

   Since RSVP and IntServ create classes of preferential service, some
   form of administrative control and/or cost allocation is needed to
   control access.  There are certain types of policies specific to ATM
   and IP over ATM that need to be studied to determine how they
   interoperate with the IP and IntServ policies being developed.
   Typical IP policies would be that only certain users are allowed to
   make reservations.  This policy would translate well to IP over ATM
   due to the similarity to the mechanisms used for Call Admission
   Control (CAC).

   There may be a need for policies specific to IP over ATM.  For
   example, since signalling costs in ATM are high relative to IP, an IP
   over ATM specific policy might restrict the ability to change the
   prevailing QoS in a VC.  If VCs are relatively scarce, there also
   might be specific accounting costs in creating a new VC.  The work so
   far has been preliminary, and much work remains to be done.  The



Crawley, et. al.             Informational                     [Page 11]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


   policy mechanisms outlined in [12] and [13] provide the basic
   mechanisms for implementing policies for RSVP and IntServ over any
   media, not just ATM.

3. Framework for IntServ and RSVP over ATM

   Now that we have defined some of the issues for IntServ and RSVP over
   ATM, we can formulate a framework for solutions.  The problem breaks
   down to two very distinct areas; the mapping of IntServ models to ATM
   service categories and QoS parameters and the operation of RSVP over
   ATM.

   Mapping IntServ models to ATM service categories and QoS parameters
   is a matter of determining which categories can support the goals of
   the service models and matching up the parameters and variables
   between the IntServ description and the ATM description(s).  Since
   ATM has such a wide variety of service categories and parameters,
   more than one ATM service category should be able to support each of
   the two IntServ models.  This will provide a good bit of flexibility
   in configuration and deployment.  [14] examines this topic
   completely.

   The operation of RSVP over ATM requires careful management of VCs in
   order to match the dynamics of the RSVP protocol.  VCs need to be
   managed for both the RSVP QoS data and the RSVP signalling messages.
   The remainder of this document will discuss several approaches to
   managing VCs for RSVP and [15] and [16] discuss their application for
   implementations in term of interoperability requirement and
   implementation guidelines.

4. RSVP VC Management

   This section provides more detail on the issues related to the
   management of SVCs for RSVP and IntServ.

4.1 VC Initiation

   As discussed in section 2.1.1.2, there is an apparent mismatch
   between RSVP and ATM. Specifically, RSVP control is receiver oriented
   and ATM control is sender oriented.  This initially may seem like a
   major issue, but really is not.  While RSVP reservation (RESV)
   requests are generated at the receiver, actual allocation of
   resources takes place at the subnet sender. For data flows, this
   means that subnet senders will establish all QoS VCs and the subnet
   receiver must be able to accept incoming QoS VCs, as illustrated in
   Figure 1.  These restrictions are consistent with RSVP version 1
   processing rules and allow senders to use different flow to VC
   mappings and even different QoS renegotiation techniques without



Crawley, et. al.             Informational                     [Page 12]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


   interoperability problems.

   The use of the reverse path provided by point-to-point VCs by
   receivers is for further study. There are two related issues. The
   first is that use of the reverse path requires the VC initiator to
   set appropriate reverse path QoS parameters. The second issue is that
   reverse paths are not available with point-to-multipoint VCs, so
   reverse paths could only be used to support unicast RSVP
   reservations.

4.2 Data VC Management

   Any RSVP over ATM implementation must map RSVP and RSVP associated
   data flows to ATM Virtual Circuits (VCs). LAN Emulation [17],
   Classical IP [10] and, more recently, NHRP [4] discuss mapping IP
   traffic onto ATM SVCs, but they only cover a single QoS class, i.e.,
   best effort traffic. When QoS is introduced, VC mapping must be
   revisited. For RSVP controlled QoS flows, one issue is VCs to use for
   QoS data flows.

   In the Classic IP over ATM and current NHRP models, a single point-
   to-point VC is used for all traffic between two ATM attached hosts
   (routers and end-stations).  It is likely that such a single VC will
   not be adequate or optimal when supporting data flows with multiple
   .bp QoS types. RSVP's basic purpose is to install support for flows
   with multiple QoS types, so it is essential for any RSVP over ATM
   solution to address VC usage for QoS data flows, as shown in Figure
   1.

   RSVP reservation styles must also be taken into account in any VC
   usage strategy.

   This section describes issues and methods for management of VCs
   associated with QoS data flows. When establishing and maintaining
   VCs, the subnet sender will need to deal with several complicating
   factors including multiple QoS reservations, requests for QoS
   changes, ATM short-cuts, and several multicast specific issues. The
   multicast specific issues result from the nature of ATM connections.
   The key multicast related issues are heterogeneity, data
   distribution, receiver transitions, and end-point identification.

4.2.1 Reservation to VC Mapping

   There are various approaches available for mapping reservations on to
   VCs.  A distinguishing attribute of all approaches is how
   reservations are combined on to individual VCs.  When mapping
   reservations on to VCs, individual VCs can be used to support a
   single reservation, or reservation can be combined with others on to



Crawley, et. al.             Informational                     [Page 13]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


   "aggregate" VCs.  In the first case, each reservation will be
   supported by one or more VCs.  Multicast reservation requests may
   translate into the setup of multiple VCs as is described in more
   detail in section 4.2.2.  Unicast reservation requests will always
   translate into the setup of a single QoS VC.  In both cases, each VC
   will only carry data associated with a single reservation.  The
   greatest benefit if this approach is ease of implementation, but it
   comes at the cost of increased (VC) setup time and the consumption of
   greater number of VC and associated resources.

   When multiple reservations are combined onto a single VC, it is
   referred to as the "aggregation" model. With this model, large VCs
   could be set up between IP routers and hosts in an ATM network. These
   VCs could be managed much like IP Integrated Service (IIS) point-to-
   point links (e.g. T-1, DS-3) are managed now.  Traffic from multiple
   sources over multiple RSVP sessions might be multiplexed on the same
   VC.  This approach has a number of advantages. First, there is
   typically no signalling latency as VCs would be in existence when the
   traffic started flowing, so no time is wasted in setting up VCs.
   Second, the heterogeneity problem (section 4.2.2) in full over ATM
   has been reduced to a solved problem. Finally, the dynamic QoS
   problem (section 4.2.7) for ATM has also been reduced to a solved
   problem.

   The aggregation model can be used with point-to-point and point-to-
   multipoint VCs.  The problem with the aggregation model is that the
   choice of what QoS to use for the VCs may be difficult, without
   knowledge of the likely reservation types and sizes but is made
   easier since the VCs can be changed as needed.

4.2.2 Unicast Data VC Management

   Unicast data VC management is much simpler than multicast data VC
   management but there are still some similar issues.  If one considers
   unicast to be a devolved case of multicast, then implementing the
   multicast solutions will cover unicast.  However, some may want to
   consider unicast-only implementations.  In these situations, the
   choice of using a single flow per VC or aggregation of flows onto a
   single VC remains but the problem of heterogeneity discussed in the
   following section is removed.

4.2.3 Multicast Heterogeneity

   As mentioned in section 2.1.3.1 and shown in figure 2, multicast
   heterogeneity occurs when receivers request different qualities of
   service within a single session.  This means that the amount of
   requested resources differs on a per next hop basis. A related type
   of heterogeneity occurs due to best-effort receivers.  In any IP



Crawley, et. al.             Informational                     [Page 14]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


   multicast group, it is possible that some receivers will request QoS
   (via RSVP) and some receivers will not. In shared media networks,
   like Ethernet, receivers that have not requested resources can
   typically be given identical service to those that have without
   complications.  This is not the case with ATM. In ATM networks, any
   additional end-points of a VC must be explicitly added. There may be
   costs associated with adding the best-effort receiver, and there
   might not be adequate resources.  An RSVP over ATM solution will need
   to support heterogeneous receivers even though ATM does not currently
   provide such support directly.

   RSVP heterogeneity is supported over ATM in the way RSVP reservations
   are mapped into ATM VCs.  There are four alternative approaches this
   mapping. There are multiple models for supporting RSVP heterogeneity
   over ATM.  Section 4.2.3.1 examines the multiple VCs per RSVP
   reservation (or full heterogeneity) model where a single reservation
   can be forwarded onto several VCs each with a different QoS. Section
   4.2.3.2 presents a limited heterogeneity model where exactly one QoS
   VC is used along with a best effort VC.  Section 4.2.3.3 examines the
   VC per RSVP reservation (or homogeneous) model, where each RSVP
   reservation is mapped to a single ATM VC.  Section 4.2.3.4 describes
   the aggregation model allowing aggregation of multiple RSVP
   reservations into a single VC.

4.2.3.1 Full Heterogeneity Model

   RSVP supports heterogeneous QoS, meaning that different receivers of
   the same multicast group can request a different QoS.  But
   importantly, some receivers might have no reservation at all and want
   to receive the traffic on a best effort service basis.  The IP model
   allows receivers to join a multicast group at any time on a best
   effort basis, and it is important that ATM as part of the Internet
   continue to provide this service. We define the "full heterogeneity"
   model as providing a separate VC for each distinct QoS for a
   multicast session including best effort and one or more qualities of
   service.

   Note that while full heterogeneity gives users exactly what they
   request, it requires more resources of the network than other
   possible approaches. The exact amount of bandwidth used for duplicate
   traffic depends on the network topology and group membership.

4.2.3.2 Limited Heterogeneity Model

   We define the "limited heterogeneity" model as the case where the
   receivers of a multicast session are limited to use either best
   effort service or a single alternate quality of service.  The
   alternate QoS can be chosen either by higher level protocols or by



Crawley, et. al.             Informational                     [Page 15]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


   dynamic renegotiation of QoS as described below.

   In order to support limited heterogeneity, each ATM edge device
   participating in a session would need at most two VCs.  One VC would
   be a point-to-multipoint best effort service VC and would serve all
   best effort service IP destinations for this RSVP session.

   The other VC would be a point to multipoint VC with QoS and would
   serve all IP destinations for this RSVP session that have an RSVP
   reservation established.

   As with full heterogeneity, a disadvantage of the limited
   heterogeneity scheme is that each packet will need to be duplicated
   at the network layer and one copy sent into each of the 2 VCs.
   Again, the exact amount of excess traffic will depend on the network
   topology and group membership. If any of the existing QoS VC end-
   points cannot upgrade to the new QoS, then the new reservation fails
   though the resources exist for the new receiver.

4.2.3.3 Homogeneous and Modified Homogeneous Models

   We define the "homogeneous" model as the case where all receivers of
   a multicast session use a single quality of service VC. Best-effort
   receivers also use the single RSVP triggered QoS VC.  The single VC
   can be a point-to-point or point-to-multipoint as appropriate. The
   QoS VC is sized to provide the maximum resources requested by all
   RSVP next- hops.

   This model matches the way the current RSVP specification addresses
   heterogeneous requests. The current processing rules and traffic
   control interface describe a model where the largest requested
   reservation for a specific outgoing interface is used in resource
   allocation, and traffic is transmitted at the higher rate to all
   next-hops. This approach would be the simplest method for RSVP over
   ATM implementations.

   While this approach is simple to implement, providing better than
   best-effort service may actually be the opposite of what the user
   desires.  There may be charges incurred or resources that are
   wrongfully allocated.  There are two specific problems. The first
   problem is that a user making a small or no reservation would share a
   QoS VC resources without making (and perhaps paying for) an RSVP
   reservation. The second problem is that a receiver may not receive
   any data.  This may occur when there is insufficient resources to add
   a receiver.  The rejected user would not be added to the single VC
   and it would not even receive traffic on a best effort basis.





Crawley, et. al.             Informational                     [Page 16]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


   Not sending data traffic to best-effort receivers because of another
   receiver's RSVP request is clearly unacceptable.  The previously
   described limited heterogeneous model ensures that data is always
   sent to both QoS and best-effort receivers, but it does so by
   requiring replication of data at the sender in all cases.  It is
   possible to extend the homogeneous model to both ensure that data is
   always sent to best-effort receivers and also to avoid replication in
   the normal case.  This extension is to add special handling for the
   case where a best- effort receiver cannot be added to the QoS VC.  In
   this case, a best effort VC can be established to any receivers that
   could not be added to the QoS VC. Only in this special error case
   would senders be required to replicate data.  We define this approach
   as the "modified homogeneous" model.

4.2.3.4 Aggregation

   The last scheme is the multiple RSVP reservations per VC (or
   aggregation) model. With this model, large VCs could be set up
   between IP routers and hosts in an ATM network. These VCs could be
   managed much like IP Integrated Service (IIS) point-to-point links
   (e.g. T-1, DS-3) are managed now. Traffic from multiple sources over
   multiple RSVP sessions might be multiplexed on the same VC. This
   approach has a number of advantages. First, there is typically no
   signalling latency as VCs would be in existence when the traffic
   started flowing, so no time is wasted in setting up VCs.   Second,
   the heterogeneity problem in full over ATM has been reduced to a
   solved problem. Finally, the dynamic QoS problem for ATM has also
   been reduced to a solved problem.  This approach can be used with
   point-to-point and point-to-multipoint VCs. The problem with the
   aggregation approach is that the choice of what QoS to use for which
   of the VCs is difficult, but is made easier if the VCs can be changed
   as needed.

4.2.4 Multicast End-Point Identification

   Implementations must be able to identify ATM end-points participating
   in an IP multicast group.  The ATM end-points will be IP multicast
   receivers and/or next-hops.  Both QoS and best-effort end-points must
   be identified.  RSVP next-hop information will provide QoS end-
   points, but not best-effort end-points. Another issue is identifying
   end-points of multicast traffic handled by non-RSVP capable next-
   hops. In this case a PATH message travels through a non-RSVP egress
   router on the way to the next hop RSVP node.  When the next hop RSVP
   node sends a RESV message it may arrive at the source over a
   different route than what the data is using. The source will get the
   RESV message, but will not know which egress router needs the QoS.
   For unicast sessions, there is no problem since the ATM end-point
   will be the IP next-hop router.  Unfortunately, multicast routing may



Crawley, et. al.             Informational                     [Page 17]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


   not be able to uniquely identify the IP next-hop router.  So it is
   possible that a multicast end-point can not be identified.

   In the most common case, MARS will be used to identify all end-points
   of a multicast group.  In the router to router case, a multicast
   routing protocol may provide all next-hops for a particular multicast
   group.  In either case, RSVP over ATM implementations must obtain a
   full list of end-points, both QoS and non-QoS, using the appropriate
   mechanisms.  The full list can be compared against the RSVP
   identified end-points to determine the list of best-effort receivers.
   There is no straightforward solution to uniquely identifying end-
   points of multicast traffic handled by non-RSVP next hops.  The
   preferred solution is to use multicast routing protocols that support
   unique end-point identification.  In cases where such routing
   protocols are unavailable, all IP routers that will be used to
   support RSVP over ATM should support RSVP.  To ensure proper
   behavior, implementations should, by default, only establish RSVP-
   initiated VCs to RSVP capable end-points.

4.2.5 Multicast Data Distribution

   Two models are planned for IP multicast data distribution over ATM.
   In one model, senders establish point-to-multipoint VCs to all ATM
   attached destinations, and data is then sent over these VCs.  This
   model is often called "multicast mesh" or "VC mesh" mode
   distribution.  In the second model, senders send data over point-to-
   point VCs to a central point and the central point relays the data
   onto point-to-multipoint VCs that have been established to all
   receivers of the IP multicast group.  This model is often referred to
   as "multicast server" mode distribution. RSVP over ATM solutions must
   ensure that IP multicast data is distributed with appropriate QoS.

   In the Classical IP context, multicast server support is provided via
   MARS [5].  MARS does not currently provide a way to communicate QoS
   requirements to a MARS multicast server.  Therefore, RSVP over ATM
   implementations must, by default, support "mesh-mode" distribution
   for RSVP controlled multicast flows.  When using multicast servers
   that do not support QoS requests, a sender must set the service, not
   global, break bit(s).

4.2.6 Receiver Transitions

   When setting up a point-to-multipoint VCs for multicast RSVP
   sessions, there will be a time when some receivers have been added to
   a QoS VC and some have not.  During such transition times it is
   possible to start sending data on the newly established VC.  The
   issue is when to start send data on the new VC.  If data is sent both
   on the new VC and the old VC, then data will be delivered with proper



Crawley, et. al.             Informational                     [Page 18]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


   QoS to some receivers and with the old QoS to all receivers.  This
   means the QoS receivers can get duplicate data.  If data is sent just
   on the new QoS VC, the receivers that have not yet been added will
   lose information.  So, the issue comes down to whether to send to
   both the old and new VCs, or to send to just one of the VCs.  In one
   case duplicate information will be received, in the other some
   information may not be received.

   This issue needs to be considered for three cases:

   - When establishing the first QoS VC
   - When establishing a VC to support a QoS change
   - When adding a new end-point to an already established QoS VC

   The first two cases are very similar.  It both, it is possible to
   send data on the partially completed new VC, and the issue of
   duplicate versus lost information is the same. The last case is when
   an end-point must be added to an existing QoS VC.  In this case the
   end-point must be both added to the QoS VC and dropped from a best-
   effort VC.  The issue is which to do first.  If the add is first
   requested, then the end-point may get duplicate information.  If the
   drop is requested first, then the end-point may loose information.

   In order to ensure predictable behavior and delivery of data to all
   receivers, data can only be sent on a new VCs once all parties have
   been added.  This will ensure that all data is only delivered once to
   all receivers.  This approach does not quite apply for the last case.
   In the last case, the add operation should be completed first, then
   the drop operation.  This means that receivers must be prepared to
   receive some duplicate packets at times of QoS setup.

4.2.7 Dynamic QoS

   RSVP provides dynamic quality of service (QoS) in that the resources
   that are requested may change at any time. There are several common
   reasons for a change of reservation QoS.

   1. An existing receiver can request a new larger (or smaller) QoS.
   2. A sender may change its traffic specification (TSpec), which can
      trigger a change in the reservation requests of the receivers.
   3. A new sender can start sending to a multicast group with a larger
      traffic specification than existing senders, triggering larger
      reservations.
   4. A new receiver can make a reservation that is larger than existing
      reservations.






Crawley, et. al.             Informational                     [Page 19]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


   If the limited heterogeneity model is being used and the merge node
   for the larger reservation is an ATM edge device, a new larger
   reservation must be set up across the ATM network. Since ATM service,
   as currently defined in UNI 3.x and UNI 4.0, does not allow
   renegotiating the QoS of a VC, dynamically changing the reservation
   means creating a new VC with the new QoS, and tearing down an
   established VC. Tearing down a VC and setting up a new VC in ATM are
   complex operations that involve a non-trivial amount of processing
   time, and may have a substantial latency.  There are several options
   for dealing with this mismatch in service.  A specific approach will
   need to be a part of any RSVP over ATM solution.

   The default method for supporting changes in RSVP reservations is to
   attempt to replace an existing VC with a new appropriately sized VC.
   During setup of the replacement VC, the old VC must be left in place
   unmodified. The old VC is left unmodified to minimize interruption of
   QoS data delivery.  Once the replacement VC is established, data
   transmission is shifted to the new VC, and the old VC is then closed.
   If setup of the replacement VC fails, then the old QoS VC should
   continue to be used. When the new reservation is greater than the old
   reservation, the reservation request should be answered with an
   error.  When the new reservation is less than the old reservation,
   the request should be treated as if the modification was successful.
   While leaving the larger allocation in place is suboptimal, it
   maximizes delivery of service to the user. Implementations should
   retry replacing the too large VC after some appropriate elapsed time.

   One additional issue is that only one QoS change can be processed at
   one time per reservation. If the (RSVP) requested QoS is changed
   while the first replacement VC is still being setup, then the
   replacement VC is released and the whole VC replacement process is
   restarted. To limit the number of changes and to avoid excessive
   signalling load, implementations may limit the number of changes that
   will be processed in a given period.  One implementation approach
   would have each ATM edge device configured with a time parameter T
   (which can change over time) that gives the minimum amount of time
   the edge device will wait between successive changes of the QoS of a
   particular VC.  Thus if the QoS of a VC is changed at time t, all
   messages that would change the QoS of that VC that arrive before time
   t+T would be queued. If several messages changing the QoS of a VC
   arrive during the interval, redundant messages can be discarded. At
   time t+T, the remaining change(s) of QoS, if any, can be executed.
   This timer approach would apply more generally to any network
   structure, and might be worthwhile to incorporate into RSVP.







Crawley, et. al.             Informational                     [Page 20]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


   The sequence of events for a single VC would be

   - Wait if timer is active
   - Establish VC with new QoS
   - Remap data traffic to new VC
   - Tear down old VC
   - Activate timer

   There is an interesting interaction between heterogeneous
   reservations and dynamic QoS. In the case where a RESV message is
   received from a new next-hop and the requested resources are larger
   than any existing reservation, both dynamic QoS and heterogeneity
   need to be addressed. A key issue is whether to first add the new
   next-hop or to change to the new QoS. This is a fairly straight
   forward special case. Since the older, smaller reservation does not
   support the new next-hop, the dynamic QoS process should be initiated
   first. Since the new QoS is only needed by the new next-hop, it
   should be the first end-point of the new VC.  This way signalling is
   minimized when the setup to the new next-hop fails.

4.2.8 Short-Cuts

   Short-cuts [4] allow ATM attached routers and hosts to directly
   establish point-to-point VCs across LIS boundaries, i.e., the VC
   end-points are on different IP subnets.  The ability for short-cuts
   and RSVP to interoperate has been raised as a general question.  An
   area of concern is the ability to handle asymmetric short-cuts.
   Specifically how RSVP can handle the case where a downstream short-
   cut may not have a matching upstream short-cut.  In this case, PATH
   and RESV messages following different paths.

   Examination of RSVP shows that the protocol already includes
   mechanisms that will support short-cuts.  The mechanism is the same
   one used to support RESV messages arriving at the wrong router and
   the wrong interface.  The key aspect of this mechanism is RSVP only
   processing messages that arrive at the proper interface and RSVP
   forwarding of messages that arrive on the wrong interface.  The
   proper interface is indicated in the NHOP object of the message.  So,
   existing RSVP mechanisms will support asymmetric short-cuts. The
   short-cut model of VC establishment still poses several issues when
   running with RSVP. The major issues are dealing with established
   best-effort short-cuts, when to establish short-cuts, and QoS only
   short-cuts. These issues will need to be addressed by RSVP
   implementations.

   The key issue to be addressed by any RSVP over ATM solution is when
   to establish a short-cut for a QoS data flow. The default behavior is
   to simply follow best-effort traffic. When a short-cut has been



Crawley, et. al.             Informational                     [Page 21]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


   established for best-effort traffic to a destination or next-hop,
   that same end-point should be used when setting up RSVP triggered VCs
   for QoS traffic to the same destination or next-hop. This will happen
   naturally when PATH messages are forwarded over the best-effort
   short-cut.  Note that in this approach when best-effort short-cuts
   are never established, RSVP triggered QoS short-cuts will also never
   be established.  More study is expected in this area.

4.2.9 VC Teardown

   RSVP can identify from either explicit messages or timeouts when a
   data VC is no longer needed.  Therefore, data VCs set up to support
   RSVP controlled flows should only be released at the direction of
   RSVP. VCs must not be timed out due to inactivity by either the VC
   initiator or the VC receiver.   This conflicts with VCs timing out as
   described in RFC 1755 [11], section 3.4 on VC Teardown.  RFC 1755
   recommends tearing down a VC that is inactive for a certain length of
   time. Twenty minutes is recommended. This timeout is typically
   implemented at both the VC initiator and the VC receiver.   Although,
   section 3.1 of the update to RFC 1755 [11] states that inactivity
   timers must not be used at the VC receiver.

   When this timeout occurs for an RSVP initiated VC, a valid VC with
   QoS will be torn down unexpectedly.  While this behavior is
   acceptable for best-effort traffic, it is important that RSVP
   controlled VCs not be torn down.  If there is no choice about the VC
   being torn down, the RSVP daemon must be notified, so a reservation
   failure message can be sent.

   For VCs initiated at the request of RSVP, the configurable inactivity
   timer mentioned in [11] must be set to "infinite".  Setting the
   inactivity timer value at the VC initiator should not be problematic
   since the proper value can be relayed internally at the originator.
   Setting the inactivity timer at the VC receiver is more difficult,
   and would require some mechanism to signal that an incoming VC was
   RSVP initiated.  To avoid this complexity and to conform to [11]
   implementations must not use an inactivity timer to clear received
   connections.

4.3 RSVP Control Management

   One last important issue is providing a data path for the RSVP
   messages themselves.  There are two main types of messages in RSVP,
   PATH and RESV. PATH messages are sent to unicast or multicast
   addresses, while RESV messages are sent only to unicast addresses.
   Other RSVP messages are handled similar to either PATH or RESV,
   although this might be more complicated for RERR messages.  So ATM
   VCs used for RSVP signalling messages need to provide both unicast



Crawley, et. al.             Informational                     [Page 22]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


   and multicast functionality.  There are several different approaches
   for how to assign VCs to use for RSVP signalling messages.

   The main approaches are:

      - use same VC as data
      - single VC per session
      - single point-to-multipoint VC multiplexed among sessions
      - multiple point-to-point VCs multiplexed among sessions

   There are several different issues that affect the choice of how to
   assign VCs for RSVP signalling. One issue is the number of additional
   VCs needed for RSVP signalling. Related to this issue is the degree
   of multiplexing on the RSVP VCs. In general more multiplexing means
   fewer VCs. An additional issue is the latency in dynamically setting
   up new RSVP signalling VCs. A final issue is complexity of
   implementation. The remainder of this section discusses the issues
   and tradeoffs among these different approaches and suggests
   guidelines for when to use which alternative.

4.3.1 Mixed data and control traffic

   In this scheme RSVP signalling messages are sent on the same VCs as
   is the data traffic. The main advantage of this scheme is that no
   additional VCs are needed beyond what is needed for the data traffic.
   An additional advantage is that there is no ATM signalling latency
   for PATH messages (which follow the same routing as the data
   messages).  However there can be a major problem when data traffic on
   a VC is nonconforming. With nonconforming traffic, RSVP signalling
   messages may be dropped. While RSVP is resilient to a moderate level
   of dropped messages, excessive drops would lead to repeated tearing
   down and re-establishing of QoS VCs, a very undesirable behavior for
   ATM. Due to these problems, this may not be a good choice for
   providing RSVP signalling messages, even though the number of VCs
   needed for this scheme is minimized. One variation of this scheme is
   to use the best effort data path for signalling traffic. In this
   scheme, there is no issue with nonconforming traffic, but there is an
   issue with congestion in the ATM network. RSVP provides some
   resiliency to message loss due to congestion, but RSVP control
   messages should be offered a preferred class of service. A related
   variation of this scheme that is hopeful but requires further study
   is to have a packet scheduling algorithm (before entering the ATM
   network) that gives priority to the RSVP signalling traffic. This can
   be difficult to do at the IP layer.







Crawley, et. al.             Informational                     [Page 23]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


4.3.1.1 Single RSVP VC per RSVP Reservation

   In this scheme, there is a parallel RSVP signalling VC for each RSVP
   reservation. This scheme results in twice the number of VCs, but
   means that RSVP signalling messages have the advantage of a separate
   VC.  This separate VC means that RSVP signalling messages have their
   own traffic contract and compliant signalling messages are not
   subject to dropping due to other noncompliant traffic (such as can
   happen with the scheme in section 4.3.1). The advantage of this
   scheme is its simplicity - whenever a data VC is created, a separate
   RSVP signalling VC is created.  The disadvantage of the extra VC is
   that extra ATM signalling needs to be done. Additionally, this scheme
   requires twice the minimum number of VCs and also additional latency,
   but is quite simple.

4.3.1.2 Multiplexed point-to-multipoint RSVP VCs

   In this scheme, there is a single point-to-multipoint RSVP signalling
   VC for each unique ingress router and unique set of egress routers.
   This scheme allows multiplexing of RSVP signalling traffic that
   shares the same ingress router and the same egress routers.  This can
   save on the number of VCs, by multiplexing, but there are problems
   when the destinations of the multiplexed point-to-multipoint VCs are
   changing.  Several alternatives exist in these cases, that have
   applicability in different situations. First, when the egress routers
   change, the ingress router can check if it already has a point-to-
   multipoint RSVP signalling VC for the new list of egress routers. If
   the RSVP signalling VC already exists, then the RSVP signalling
   traffic can be switched to this existing VC. If no such VC exists,
   one approach would be to create a new VC with the new list of egress
   routers. Other approaches include modifying the existing VC to add an
   egress router or using a separate new VC for the new egress routers.
   When a destination drops out of a group, an alternative would be to
   keep sending to the existing VC even though some traffic is wasted.
   The number of VCs used in this scheme is a function of traffic
   patterns across the ATM network, but is always less than the number
   used with the Single RSVP VC per data VC. In addition, existing best
   effort data VCs could be used for RSVP signalling. Reusing best
   effort VCs saves on the number of VCs at the cost of higher
   probability of RSVP signalling packet loss.  One possible place where
   this scheme will work well is in the core of the network where there
   is the most opportunity to take advantage of the savings due to
   multiplexing.  The exact savings depend on the patterns of traffic
   and the topology of the ATM network.







Crawley, et. al.             Informational                     [Page 24]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


4.3.1.3 Multiplexed point-to-point RSVP VCs

   In this scheme, multiple point-to-point RSVP signalling VCs are used
   for a single point-to-multipoint data VC.  This scheme allows
   multiplexing of RSVP signalling traffic but requires the same traffic
   to be sent on each of several VCs. This scheme is quite flexible and
   allows a large amount of multiplexing.

   Since point-to-point VCs can set up a reverse channel at the same
   time as setting up the forward channel, this scheme could save
   substantially on signalling cost.  In addition, signalling traffic
   could share existing best effort VCs.  Sharing existing best effort
   VCs reduces the total number of VCs needed, but might cause
   signalling traffic drops if there is congestion in the ATM network.
   This point-to-point scheme would work well in the core of the network
   where there is much opportunity for multiplexing. Also in the core of
   the network, RSVP VCs can stay permanently established either as
   Permanent Virtual Circuits (PVCs) or  as long lived Switched Virtual
   Circuits (SVCs). The number of VCs in this scheme will depend on
   traffic patterns, but in the core of a network would be approximately
   n(n-1)/2 where n is the number of IP nodes in the network.  In the
   core of the network, this will typically be small compared to the
   total number of VCs.

4.3.2 QoS for RSVP VCs

   There is an issue of what QoS, if any, to assign to the RSVP
   signalling VCs. For other RSVP VC schemes, a QoS (possibly best
   effort) will be needed.  What QoS to use partially depends on the
   expected level of multiplexing that is being done on the VCs, and the
   expected reliability of best effort VCs. Since RSVP signalling is
   infrequent (typically every 30 seconds), only a relatively small QoS
   should be needed. This is important since using a larger QoS risks
   the VC setup being rejected for lack of resources. Falling back to
   best effort when a QoS call is rejected is possible, but if the ATM
   net is congested, there will likely be problems with RSVP packet loss
   on the best effort VC also. Additional experimentation is needed in
   this area.

5. Encapsulation

   Since RSVP is a signalling protocol used to control flows of IP data
   packets, encapsulation for both RSVP packets and associated IP data
   packets must be defined. The methods for transmitting IP packets over
   ATM (Classical IP over ATM[10], LANE[17], and MPOA[18]) are all based
   on the encapsulations defined in RFC1483 [19].  RFC1483 specifies two
   encapsulations, LLC Encapsulation and VC-based multiplexing.  The
   former allows multiple protocols to be encapsulated over the same VC



Crawley, et. al.             Informational                     [Page 25]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


   and the latter requires different VCs for different protocols.

   For the purposes of RSVP over ATM, any encapsulation can be used as
   long as the VCs are managed in accordance to the methods outlined in
   Section 4.  Obviously, running multiple protocol data streams over
   the same VC with LLC encapsulation can cause the same problems as
   running multiple flows over the same VC.

   While none of the transmission methods directly address the issue of
   QoS, RFC1755 [11] does suggest some common values for VC setup for
   best-effort traffic.  [14] discusses the relationship of the RFC1755
   setup parameters and those needed to support IntServ flows in greater
   detail.

6. Security Considerations

   The same considerations stated in [1] and [11] apply to this
   document.  There are no additional security issues raised in this
   document.

7. References

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

   [2] Borden, M., Crawley, E., Davie, B., and S. Batsell, "Integration
       of Realtime Services in an IP-ATM Network Architecture", RFC
       1821, August 1995.

   [3] Cole, R., Shur, D., and C. Villamizar, "IP over ATM: A Framework
       Document", RFC 1932, April 1996.

   [4] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N.
       Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332,
       April 1998.

   [5] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM
       Networks", RFC 2022, November 1996.

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

   [7] Wroclawski, J., "Specification of the Controlled-Load Network
       Element Service", RFC 2211, September 1997.

   [8] ATM Forum. ATM User-Network Interface Specification Version 3.0.
       Prentice Hall, September 1993.



Crawley, et. al.             Informational                     [Page 26]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


   [9] ATM Forum. ATM User Network Interface (UNI) Specification Version
       3.1. Prentice Hall, June 1995.

   [10] Laubach, M., "Classical IP and ARP over ATM", RFC 2225, April
        1998.

   [11] Perez, M., Mankin, A., Hoffman, E., Grossman, G., and A. Malis,
        "ATM Signalling Support for IP over ATM", RFC 1755, February
        1995.

   [12] Herzog, S., "RSVP Extensions for Policy Control", Work in
        Progress.

   [13] Herzog, S., "Local Policy Modules (LPM): Policy Control for
        RSVP", Work in Progress.

   [14] Borden, M., and M. Garrett, "Interoperation of Controlled-Load
        and Guaranteed Service with ATM", RFC 2381, August 1998.

   [15] Berger, L., "RSVP over ATM Implementation Requirements", RFC
        2380, August 1998.

   [16] Berger, L., "RSVP over ATM Implementation Guidelines", RFC 2379,
        August 1998.

   [17] ATM Forum Technical Committee. LAN Emulation over ATM, Version
        1.0 Specification, af-lane-0021.000, January 1995.

   [18] ATM Forum Technical Committee. Baseline Text for MPOA, af-95-
        0824r9, September 1996.

   [19] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation
        Layer 5", RFC 1483, July 1993.

   [20] ATM Forum Technical Committee. LAN Emulation over ATM Version 2
        - LUNI Specification, December 1996.

   [21] ATM Forum Technical Committee. Traffic Management Specification
        v4.0, af-tm-0056.000, April 1996.

   [22] Callon, R., et al., "A Framework for Multiprotocol Label
        Switching, Work in Progress.

   [23] Rajagopalan, B., Nair, R., Sandick, H., and E. Crawley, "A
        Framework for QoS-based Routing in the Internet", RFC 2386,
        August 1998.





Crawley, et. al.             Informational                     [Page 27]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


   [24] ITU-T. Digital Subscriber Signaling System No. 2-Connection
        modification: Peak cell rate modification by the connection
        owner, ITU-T Recommendation Q.2963.1, July 1996.

   [25] ITU-T. Digital Subscriber Signaling System No. 2-Connection
        characteristics negotiation during call/connection establishment
        phase, ITU-T Recommendation Q.2962, July 1996.

   [26] ATM Forum Technical Committee. Private Network-Network Interface
        Specification v1.0 (PNNI), March 1996.

8. Authors' Addresses

   Eric S. Crawley
   Argon Networks
   25 Porter Road
   Littleton, Ma 01460

   Phone: +1 978 486-0665
   EMail: esc@argon.com


   Lou Berger
   FORE Systems
   6905 Rockledge Drive
   Suite 800
   Bethesda, MD 20817

   Phone: +1 301 571-2534
   EMail: lberger@fore.com


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

   Phone: +1 310 822-1511
   EMail: berson@isi.edu


   Fred Baker
   Cisco Systems
   519 Lado Drive
   Santa Barbara, California 93111

   Phone: +1 805 681-0115
   EMail: fred@cisco.com



Crawley, et. al.             Informational                     [Page 28]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


   Marty Borden
   Bay Networks
   125 Nagog Park
   Acton, MA 01720

   Phone: +1 978 266-1011
   EMail: mborden@baynetworks.com


   John J. Krawczyk
   ArrowPoint Communications
   235 Littleton Road
   Westford, Massachusetts 01886

   Phone: +1 978 692-5875
   EMail: jj@arrowpoint.com



































Crawley, et. al.             Informational                     [Page 29]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


9.  Full Copyright Statement

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

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

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

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Crawley, et. al.             Informational                     [Page 30]