File: rfc3170.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 (1571 lines) | stat: -rw-r--r-- 67,207 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






Network Working Group                                           B. Quinn
Request for Comments: 3170                                Celox Networks
Category: Informational                                      K. Almeroth
                                                        UC-Santa Barbara
                                                          September 2001


                       IP Multicast Applications:
                        Challenges and Solutions

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 (2001).  All Rights Reserved.

Abstract

   This document describes the challenges involved with designing and
   implementing multicast applications.  It is an introductory guide for
   application developers that highlights the unique considerations of
   multicast applications as compared to unicast applications.

   To this end, the document presents a taxonomy of multicast
   application I/O models and examples of the services they can support.
   It then describes the service requirements of these multicast
   applications, and the recent and ongoing efforts to build protocol
   solutions to support these services.

Table of Contents

   1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2
     1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2
     1.2 Focus and Scope. . . . . . . . . . . . . . . . . . . . . . . 3
   2. IP Multicast-enabled Network. . . . . . . . . . . . . . . . . . 3
     2.1 Essential Protocol Components. . . . . . . . . . . . . . . . 4
       2.1.1 Expedient Joins and Leaves . . . . . . . . . . . . . . . 5
       2.1.2 Send without a Join. . . . . . . . . . . . . . . . . . . 5
   3. IP Multicast Application Taxonomy . . . . . . . . . . . . . . . 6
     3.1 One-to-Many Applications . . . . . . . . . . . . . . . . . . 8
     3.2 Many-to-Many Applications. . . . . . . . . . . . . . . . . . 9
     3.3 Many-to-One Applications . . . . . . . . . . . . . . . . . .10
   4. Common Multicast Service Requirements . . . . . . . . . . . . .13
     4.1 Bandwidth Requirements . . . . . . . . . . . . . . . . . . .13



Quinn, et al.                Informational                      [Page 1]

RFC 3170               IP Multicast Applications          September 2001


     4.2 Delay Requirements . . . . . . . . . . . . . . . . . . . . .13
   5. Unique Multicast Service Requirements . . . . . . . . . . . . .14
     5.1 Address Management . . . . . . . . . . . . . . . . . . . . .16
     5.2 Session Management . . . . . . . . . . . . . . . . . . . . .16
     5.3 Heterogeneous Receiver Support . . . . . . . . . . . . . . .18
     5.4 Reliable Data Delivery . . . . . . . . . . . . . . . . . . .20
     5.5 Security . . . . . . . . . . . . . . . . . . . . . . . . . .21
     5.6 Synchronized Play-Out. . . . . . . . . . . . . . . . . . . .23
   6. Service APIs. . . . . . . . . . . . . . . . . . . . . . . . . .23
   7. Security Considerations . . . . . . . . . . . . . . . . . . . .24
   8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . .24
   9. References. . . . . . . . . . . . . . . . . . . . . . . . . . .24
   10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .27
   11. Full Copyright Statement . . . . . . . . . . . . . . . . . . .28

1. Introduction

   IP Multicast will play a prominent role on the Internet in the coming
   years.  It is a requirement, not an option, if the Internet is going
   to scale.  Multicast allows application developers to add more
   functionality without significantly impacting the network.

   Developing multicast-enabled applications is ostensibly simple.
   Having datagram access allows any application to send to a multicast
   address.  A multicast application need only increase the Internet
   Protocol (IP) time-to-live (TTL) value to more than 1 (the default
   value) to allow outgoing datagrams to traverse routers.  To receive a
   multicast datagram, applications join the multicast group, which
   transparently generates an [IGMPv2, IGMPv3] group membership report.

   This apparent simplicity is deceptive, however.  Enabling multicast
   support in applications and protocols that can scale well on a
   heterogeneous network is a significant challenge.  Specifically,
   sending constant bit rate datastreams, reliable data delivery,
   security, and managing many-to-many communications all require
   special consideration.  Some solutions are available, but many of
   these services are still active research areas.

1.1 Motivation

   The purpose of this document is to provide a framework for
   understanding the challenges of designing and implementing multicast
   applications.  In order to use multicast communications correctly,
   application developers must first understand the various I/O models
   and the network services (in addition to basic multicast
   communication) that are required.  Secondly, application developers





Quinn, et al.                Informational                      [Page 2]

RFC 3170               IP Multicast Applications          September 2001


   need to be aware of efforts underway to provide these services.  Such
   efforts range in maturity from deployed commercial products to basic
   research efforts to evaluate feasibility.

   Multicast-based applications and services will play an important role
   in the future of the Internet as continued multicast deployment
   encourages their use and development.  It is important that
   developers be aware of the issues and solutions available--and
   especially of their limitations--in order to avoid protocols that
   negatively impact networks (thereby counter-acting the benefits of
   multicast) or wasting their efforts "re-inventing the wheel".

   The hope is that by raising developers' awareness, we can adjust
   their expectations of finding solutions and lead them to successful,
   scalable, and "network-friendly" development efforts.

1.2 Focus and Scope

   Our initial premise is that the multicast infrastructure is
   transparent to applications, so it is not directly relevant to this
   discussion.  Our focus here is on multicast application protocol
   services, so this document explicitly avoids any discussion of
   multicast routing issues.  We identify and describe the multicast-
   specific issues involved with developing applications.

   We assume the reader has a general understanding of the mechanics of
   multicast, and in this respect we intend to compliment other
   introductory documents [BeauW, Maufer, Miller].  Since this is an
   introductory survey rather than a comprehensive examination, we refer
   readers to other multicast application requirements descriptions [RM,
   LSMA, Miller] for more detail.

   In the remainder of this document we first define the term "IP
   multicast enabled network", the multicast infrastructure and
   essential multicast services.  Next we describe the types of new
   functionality that multicast applications can enable and their
   requirements.  We then examine the services that satisfy these
   requirements, the challenges they present, and provide a brief survey
   of the solutions available or under development.  We wrap up with a
   discussion of application programming interfaces (APIs) for multicast
   services.

2. IP Multicast Enabled Network

   An "IP multicast-enabled network" provides end-to-end services in the
   IP network infrastructure to allow any IP host to send datagrams to
   an IP multicast address that any number of other IP hosts widely
   dispersed can receive.



Quinn, et al.                Informational                      [Page 3]

RFC 3170               IP Multicast Applications          September 2001


   There are two kinds of multicast-enabled networks available.  The
   first is based on the original multicast service model as defined in
   RFC 1112 [Deering].  In this model, a receiver simply joins the group
   and does not need to know the identity of the source(s).  This model
   is known by a number of names including Internet Standard Multicast
   (ISM), Internet Traditional Multicast (ITM), Deering multicast, etc.
   The second kind of multicast modifies the original service model such
   that in addition to knowing the group address, a receiver must know
   the set of relevant sources.  This type of multicast is called Source
   Specific Multicast (SSM) [SSM].  It becomes the application's
   responsibility to know what kind of multicast capability the network
   provides.  Currently, the only way for an application to know the
   type of multicast is based on the group address.  If the group is in
   the 232/8 range, the application should assume SSM is the service
   model.  Otherwise, the application should assume source-generic
   multicast is the service model.

   At the time of this writing, end-to-end "global" multicast service is
   not yet available, but the size of the "multicast-enabled" Internet
   is growing.  Recent development and deployment of interdomain
   multicast routing protocols and multicast-friendly Internet exchanges
   have enabled peering between major ISPs.  This, along with the
   increasing availability of compelling content, is spurring deployment
   and availability of the IP Multicast Enabled Network.

   In the remainder of this document we assume that the multicast-
   enabled network is already ubiquitous.  Since such a large and
   growing portion of the global Internet is IP multicast-enabled now,
   and many enterprise networks (intranets) are also, this perspective
   is relevant today.

2.1 Essential Protocol Components

   An IP multicast enabled network requires two essential protocol
   components:

     1) An IP host-based protocol to allow a receiver application to
        notify a local router(s) that it has joined the group, and
        initiate the data flow from all sender(s) within the scope

     2) An IP router-based protocol to allow any routers with multicast
        group members (receivers) on their local networks to communicate
        with other routers to ensure that all datagrams sent to the
        group address are forwarded to all receivers within the intended
        scope






Quinn, et al.                Informational                      [Page 4]

RFC 3170               IP Multicast Applications          September 2001


   Ideally, these protocol components are transparent to multicast
   applications.  However, there are two aspects of their functionality
   requirements that are worth mentioning specifically, since they
   affect application performance and design.  These are the multicast
   application requirements for:

     - Expedient Joins and Leaves
     - Sends without a Join

2.1.1 Expedient Joins and Leaves

   Some applications require expedient group joins and leaves, as their
   usability or functionality are sensitive to the latency involved with
   joining and leaving a group.

      Join Latency: The time it takes for data to begin flowing after an
      application issues a command to join a multicast group

      Leave Latency: The time it takes for data to stop flowing after an
      application issues a command to leave a multicast group
      [IGMPv2,IGMPv3]

   For example, using distributed a/v as a multicast-based "television"
   must allow users to "channel surf"--changing channels frequently.
   Each channel change generates a group leave and group join, so delays
   in either will affect usability.  In a sense, this is more of a user
   requirement than an application requirement.

   The functionality of distributed interactive simulations [DIS] is
   often sensitive to join/leave latency.  This is particularly true
   when trying to exchange information to represent fast moving objects
   that quickly enter and exit the scope of a simulated environment
   (e.g., low-flying, fast-moving aircraft).  If the join latency is too
   long, the information provided may be old by the time it is received.

   A fast leave phase is highly desirable both for effective congestion
   control mechanisms, to stop undesirable flows quickly, and for the
   network in general, to better filter unwanted traffic [Rizzo].
   Applications cannot affect control over either join or leave latency,
   but are dependent on the multicast infrastructure to enable expedient
   operations.  This is a basic multicast service requirement.

2.1.2 Sends without a Join

   Applications that send to a multicast address should be able to start
   sending immediately, without having to join the destination group
   first.  This is important for embedded devices and bursty-source
   applications with low-delay delivery requirements.



Quinn, et al.                Informational                      [Page 5]

RFC 3170               IP Multicast Applications          September 2001


   The current IGMP-based multicast host model and all current
   implementations allow senders to send to a group without joining it
   as a standard feature.

3. IP Multicast Application Taxonomy

   With an IP multicast-enabled network available, some unique and
   powerful applications and application services are possible.
   "Multicast enables coordination - it is well suited to loosely
   coupled distributed systems (of people, servers, databases,
   processes, devices...)" [Estrin].

   A "multicast application" is simply defined as any application that
   sends to and/or receives from an IP multicast address.  These may or
   may not also reference IP unicast addresses, as we describe later.

   What differentiates IP multicast applications from one-to-one unicast
   applications are the other sender and receiver relationships
   multicast enables.  There are three general categories of multicast
   applications:

      One-to-Many (1toM): A single host sending to two or more (n)
      receivers

      Many-to-Many (MtoM): Any number of hosts sending to the same
      multicast group address, as well as receiving from it

      Many-to-One (Mto1): Any number of receivers sending data back to a
      (source) sender via unicast or multicast






















Quinn, et al.                Informational                      [Page 6]

RFC 3170               IP Multicast Applications          September 2001


                            +-----------------------------------+
                            |        Host 2->n ("many")         |
                            +-------------+---------------------+
                            |   One-Way   |       Two-Way       |
                            +-------------+---------------------|
                            |  A      B   |   C      D      E   |
                +-----------+-------------+---------------------+
                |    I/O    |             |  S(m)/  S(u)/  S(m)/|
                | Operations| S(m)   R(m) |  R(m)   R(m)   R(u) |
    +-------+---+-----------+-------------+---------------------|
    |       | 1 | S(m)      |        1toM |  MtoM               |
    | Host  | 2 | R(m)      | Mto1        |  MtoM               |
    |       +---+-----------+-------------+                     |
    |  1    | 3 | S(m)/R(m) | Mto1   1toM    MtoM               |
    |       | 4 | S(m)/R(u) |                       Mto1        |
    |("one")| 5 | S(u)/R(m) |                              Mto1 |
    +-------+---+-----------+-----------------------------------+

          Legend:    S: "Send"          (u): "unicast"
          ------     R: "Receive"       (m): "multicast"

   Table 1: Application types characterized by I/O relationships
            and destination address types (multicast or unicast)

   Table 1 defines these application types in terms of the I/O
   relationships they represent.  These categories are defined in terms
   of the combination of communication mechanisms they use.  At the IP
   level, all multicast I/O is only 1toM or MtoM and unicast is always
   one-to-one (1to1).  The Mto1 category, for example, refers to several
   possible combinations of IP-level relationships, including unicast.
   We created the Mto1 category to help differentiate between the many
   applications and services that use multicast.

                 1toM:           MtoM:            Mto1:
                  R1             S1/R1             S1
                 /               / | \               \
                S-R2         S2/R2-+-S3/R3         S2-R
                 \...            \ | /            .../
                  Rn             Sn/Rn             Sn

                Legend:  S: "Sender"
                ------   R: "Receiver"

      Figure 1: Generalization of the three application categories

   Figure 1 illustrates the general model for each of the three
   multicast application categories.  Again it is worth emphasizing that
   Mto1 is an artificial category defined by the application-level



Quinn, et al.                Informational                      [Page 7]

RFC 3170               IP Multicast Applications          September 2001


   relationship between sender(s) and receiver.  At the IP-level,
   multicast does not provide an Mto1 I/O mechanism, since it does not
   allow senders to limit receivers, nor even know who they are.
   Receiver information and limitations are enabled at the application
   level, as required by the multicast application.

   We describe each of these general application types in more detail
   and provide application examples of each in the sub-sections below.
   The list of examples is not comprehensive, but attempts to define the
   prominent multicast application and service types in each of the
   three general categories.  We reference the items in these lists in
   the remainder of this document as we describe their specific service
   requirements, define the challenges they present, and reference
   solutions available or under development.

3.1 One-to-Many Applications

   One-to-Many (1toM) applications have a single sender, and multiple
   simultaneous receivers.  Entry B1 in Table 1 represents the classic
   1toM relationship.  Entry B3 differs only slightly, as the sender
   also acts as receiver (i.e., it has loopback enabled).

   When people think of multicast, they most often think of broadcast-
   based multimedia applications: television (video) and radio (audio).
   This is a reasonable analogy and indeed these are significant
   multicast applications, but these are far from the extent of
   applications that multicast can enable.  Audio/Video distribution
   represents a fraction of the multicast application possibilities, and
   most do not have analogs in today's consumer broadcast industry.

      a) Scheduled audio/video (a/v) distribution: Lectures,
         presentations, meetings, or any other type of scheduled event
         whose multimedia coverage could benefit an audience (i.e.
         television and radio "broadcasts").  One or more constant-bit-
         rate (CBR) datastreams and relatively high-bandwidth demands
         characterize these applications.  When more than one datastream
         is present--as with an audio/video combination--the two are
         synchronized and one typically has a higher priority than the
         other(s).  For example, in an a/v combination it is more
         important to ensure an intelligible audio stream, than perfect
         video.

      b) Push media: News headlines, weather updates, sports scores, or
         other types of non-essential dynamic information.  "Drip-feed",
         relatively low-bandwidth data characterize these applications.






Quinn, et al.                Informational                      [Page 8]

RFC 3170               IP Multicast Applications          September 2001


      c) File Distribution and Caching: Web site content, executable
         binaries, and other file-based updates sent to distributed
         end-user or replication/caching sites

      d) Announcements: Network time, multicast session schedules,
         random numbers, keys, configuration updates, (scoped) network
         locality beacons, or other types of information that are
         commonly useful.  Their bandwidth demands can vary, but
         generally they are very low bandwidth.

      e) Monitoring: Stock prices, Sensor equipment (seismic activity,
         telemetry, meteorological or oceanic readings), security
         systems, manufacturing or other types of real-time information.
         Bandwidth demands vary with sample frequency and resolution,
         and may be either constant-bit-rate or bursty (if event-
         driven).

3.2 Many-to-Many Applications

   In many-to-Many (MtoM) applications two or more of the receivers also
   act as senders.  In other words, MtoM applications are characterized
   by two-way multicast communications.

   The many-to-many capabilities of IP multicast enable the most unique
   and powerful applications.  Each host running an MtoM application may
   receive data from multiple senders while it also sends data to all of
   them.  As a result, many-to-many applications often present complex
   coordination and management challenges.

      f) Multimedia Conferencing: Audio/Video and whiteboard comprise
         the classic conference application.  Having multiple
         datastreams with different priorities characterizes this type
         of application.  Co-ordination issues--such as determining who
         gets to talk when--complicate their development and usability.
         There are common heuristics and "rules of play", but no
         standards exist for managing conference group dynamics.

      g) Synchronized Resources: Shared distributed databases of any
         type (schedules, directories, as well as traditional
         Information System databases).

      h) Concurrent Processing: Distributed parallel processing.

      i) Collaboration: Shared document editing.

      j) Distance Learning: This is a one-to-many a/v distribution
         application with "upstream" capability that allows receivers to
         question the speaker(s).



Quinn, et al.                Informational                      [Page 9]

RFC 3170               IP Multicast Applications          September 2001


      k) Chat Groups: These are like text-based conferences, but may
         also provide simulated representations ("avatars") for each
         "speaker" in simulated environments.

      l) Distributed Interactive Simulations [DIS]: Each object in a
         simulation multicasts descriptive information (e.g., telemetry)
         so all other objects can render the object, and interact as
         necessary.  The bandwidth demands for these can be tremendous,
         as the number of objects and the resolution of descriptive
         information increases.

      m) Multi-player Games: Many multi-player games are simply
         distributed interactive simulations, and may include chat group
         capabilities.  Bandwidth usage can vary widely, although
         today's first-generation multi-player games attempt to minimize
         bandwidth usage to increase the target audience (many of whom
         still use dial-up modems).

      n) Jam Sessions: Shared encoded audio (e.g., music).  The
         bandwidth demands vary based on the encoding technique, sample
         rate, sample resolution, number of channels, etc.

3.3 Many-to-One Applications

   Unlike the one-to-many and many-to-many application categories, the
   many-to-one (Mto1) category does not represent a communications
   mechanism at the IP layer.  Mto1 applications have multiple senders
   and one (or a few) receiver(s), as defined by the application layer.
   Table 1 shows that Mto1 applications can be one-way or use a two-way
   request/response type protocol, where either senders or receiver(s)
   may generate the request.  Figure 2 characterizes the I/O
   relationship possibilities in Mto1 applications:

   Mto1 applications have many scaling issues.  Too many simultaneous
   senders can potentially overwhelm receiver(s), a condition
   characterized as an "implosion problem".   Another considerable
   scaling problem is the large amount of state in the network that
   having many multicast senders generates.  This is largely transparent
   to applications and the effect may be diminished in the future with
   the use of bi-directional trees in multicast routing protocols, but
   nonetheless it should be considered by application designers.










Quinn, et al.                Informational                     [Page 10]

RFC 3170               IP Multicast Applications          September 2001


   1)  S1        2)  S1            3)  S1           4)  S1
         \             \                 \                \
       S2-R          S2-R              S2-R             S2-R
      .../          .../              .../             .../
       Sn            Sn                Sn               Sn

      Data(m)     Request(m)       Request(m)       Request(u)
      ------>     ---------->     <----------       ---------->
                  Response(u)      Response(u)      Response(m)
                 <-----------      ----------->    <----------

       Figure 2: Characterization of Mto1 I/O possibilities

   No standards yet exist for alternate and equivalent Mto1 application
   designs, but there are a number of possibilities to consider [HNRS].
   Since the main advantage of using multicast in a Mto1 application is
   that senders need not know the receiver(s) unicast address(es), one
   alternative is for each receiver to advertise its unicast address via
   multicast.  However, since this strategy still leaves the potential
   for implosion on each receiver, additional strategies may be needed
   to distribute the load.  For example, it may be possible to increase
   the number of receivers (in a "flat" receiver topology) or establish
   localized receivers (in a "hierarchical" topology) as used in "local
   recovery" (section 5.3).  Such methods have coordination issues, and
   since standard solutions have not yet been identified, Mto1
   application developers should consider their alternatives carefully.

      o) Resource Discovery: Service Location, for example, leverages IP
         Multicast to enable something like a "host anycasting service"
         capability [AnyCast]: A multicast receiver to send a query to a
         group address, to elicit responses from the closest host so
         they can satisfy the request.  The responses might also contain
         information that allows the receiver to determine the most
         appropriate (e.g., closest) service provider to use.

            In Table 1, this application is entry D4.  It is also
            illustrated in Figure 2 by possibility number 3.
            Alternately, the response could be to a multicast rather
            than unicast address, although technically that would make
            it an MtoM application type (this is how the Service
            Location Protocol [SLP] operates, when a user agent attempts
            to locate a directory agent).

      p) Data Collection: This is the converse of a one-to-many
         "monitoring" application described earlier.  In this case there
         may be any number of distributed "sensors" that send data to a
         data collection host.  The sensors might send updates in
         response to a request from the data collector, or send



Quinn, et al.                Informational                     [Page 11]

RFC 3170               IP Multicast Applications          September 2001


         continuously at regular intervals, or send spontaneously when a
         pre-defined event occurs.  Bandwidth demands can vary based on
         sample frequency and resolution.

         This is illustrated in Table 1 by entries A1 and A3, the only
         difference being that A3 has a loopback interface.  In Figure
         2, this is possibility number 1.  Since the number of receivers
         can easily be more than one, this is really an MtoM
         application.

      q) Auctions: The "auctioneer" starts the bidding by describing
         whatever it is for sale (product or service or whatever), and
         receivers send their bids privately or publicly (i.e., to a
         unicast or multicast address).

         This is possibility number 2 in Figure 2, and D5 in Table 1.
         The response could be sent to a multicast address, although
         technically that would make it an MtoM application.

      r) Polling: The "pollster" sends out a question, and the "pollees"
         respond with answers.  This is possibility number 2 in Figure
         2, and could also be characterized as an MtoM application if
         the response is to a multicast address.

      s) Jukebox: Allows near-on-demand a/v playback.  Receivers use an
         "out-of-band" protocol mechanism (via web, email, unicast or
         multicast requests, etc.) to send their playback request into a
         scheduling queue [IMJ].

         This is characterized by possibility number 4 in Figure 2, and
         entry D4 in Table 1.  The initial unicast request is the only
         difference between this type of application and a typical 1toM.
         If that initial request were sent to a multicast address, this
         would effectively be an MtoM application.

      t) Accounting: This is basically data collection but is worth
         separating since it is such an important application.  In some
         multicast applications it is imperative to know information
         about each receiver, possibly in real-time.  But such
         information can be overwhelming [MRM].  Current mechanisms,
         like RTCP (which is actually MtoM since it is multicast but
         could be made Mto1), use scaling techniques but trade-off
         information granularity.  As a group grows the total amount of
         feedback is constant but each receiver sends less.







Quinn, et al.                Informational                     [Page 12]

RFC 3170               IP Multicast Applications          September 2001


4. Common Multicast Service Requirements

   Some multicast application service requirements are common to unicast
   network applications as well.  We characterize two of them here--
   bandwidth and delay requirements.

4.1 Bandwidth Requirements

   Figure 3 shows multicast applications approximate bandwidth
   requirements.

   Unicast and multicast applications both need to design applications
   to adapt to the variability of network conditions.  But as we
   describe in section 5.3, it is the need to accommodate multiple
   heterogeneous multicast receivers--with their diversity of bandwidth
   capacity and delivery delays--that presents the unique challenge for
   multicast applications to satisfy these requirements.

          |
     1toM |     b, d          c, e               a
          |
     MtoM |       k           g, i        f, h, j, l, m, n
          |
     Mto1 |   o, q, r         p, t               s
          |
          +-----------------------------------------------
            Low Bandwidth                  High Bandwidth

           Figure 3: Bandwidth Requirements of applications

4.2 Delay Requirements

   Aside from those with time-sensitive data (e.g., stock prices, and
   real-time monitoring information), most one-to-many applications have
   a high tolerance for delay and delay variance (jitter).  Constant
   bit-rate (CBR) data--such as streaming media (audio/video)--are
   sensitive to jitter, but applications commonly counteract the effects
   by buffering data and delaying playback.

   Most many-to-one and many-to-many multicast applications are
   intolerant of delays because they are bidirectional, interactive and
   request/response dependent.  As a result, delays should be minimized,
   since they can adversely affect the application's usability.

   This need to minimize delays is most evident in (two-way) conference
   applications, where users cannot converse effectively if the audio or
   video is delayed more than 500 milliseconds.  For this and other




Quinn, et al.                Informational                     [Page 13]

RFC 3170               IP Multicast Applications          September 2001


   examples see Figure 4, which plots multicast applications on a
   (coarse) scale of sensitivity to delivery delays.

          |
     1toM |     b, c         a, d                e
          |
     MtoM |               g, i, j, k       f, h, l, m, n
          |
     Mto1 |      r        o, p, s, t             q
          |
          +-----------------------------------------------
            Delay Tolerant                Delay Intolerant

           Figure 4: Delay tolerance of application types

   For delay-intolerant multicast (or unicast) applications, quality of
   service (QoS) is the only option.  IP networks currently provide only
   "best effort" delivery, so data are subject to variable router
   queuing delays and loss due to network congestion (router queue
   overflows).  IP QoS standards do exist now [RSVP] and efforts to
   enable end-to-end QoS support in the Internet are underway [E2EQOS].

   However, QoS support is an IP network infrastructure consideration.
   Although there are multicast-specific challenges for implementing QoS
   in the network for multicast flows, they are beyond the control of
   applications, so further discussion of the QoS protocols and services
   is beyond the scope of this document.

5. Unique Multicast Service Requirements

   The three application categories described earlier are very general
   in nature.  Within each category and even among each of the
   application types, specific application instances have a variety of
   application requirements.  One-to-many application types are
   relatively simple to develop, but as we pointed out there are
   challenges involved with developing many-to-one and many-to-many
   applications.  Some of these have requirements bandwidth and delay
   requirements, similar to unicast applications.

   Multicast applications can be further differentiated from unicast
   applications and from each other by the services they require.  In
   this section we provide a survey of the various services that have
   unique requirements for multicast applications.








Quinn, et al.                Informational                     [Page 14]

RFC 3170               IP Multicast Applications          September 2001


    +--------------------------------------------------------------+
    |                  Multicast Application                       |
    +--------------------------------------+   +-------------------+
    +-------------------------------------+|   |+--------++--------+
    |          Multicast Security         ||   ||        ||        |
    +----------------------+   +----------+|   || System ||        |
    +----------++---------+|   |+---------+|   ||  Time  || Codecs |
    | Reliable || Address ||   || Session ||   ||        ||        |
    | Delivery ||   Mgt   ||   ||   Mgt   ||   ||        ||        |
    +----------++---------++---++---------++---++--------++--------+
    +----------------------------------------++--------------------+
    |     Basic IP Multicast Service         ||     IP Unicast     |
    |       (e.g., UDP and IGMPv2/v3)        ||      Service       |
    +----------------------------------------++--------------------+

            Figure 5: Multicast service requirements summary

   Here's the list of multicast application service requirements:

      Address Management - Selection and coordinated of address
      allocation.  The need is to provide assurances against "address
      collision" and to provide address ownership.

      Session Management - Perform application-layer services on top of
      multicast transport.  These services depend heavily on the
      application but include functions like session advertisement,
      billing, group member monitoring, key distribution, etc.

      Heterogeneous Receiver Support - Sending to receivers with a wide
      variety of bandwidth capacities, latency characteristics, and
      network congestion requires feedback to monitor receiver
      performance.

      Reliable Data Delivery - Ensuring that all data sent is received
      by all receivers.

      Security - Ensuring content privacy among dynamic multicast group
      memberships, and limiting senders.

      Synchronized Play-Out - Allow multiple receivers to "replay" data
      received in synchronized fashion.

   In the remainder of this section, we describe each of these
   application services in more detail, the challenges they present, and
   the status of standardized solutions.






Quinn, et al.                Informational                     [Page 15]

RFC 3170               IP Multicast Applications          September 2001


5.1 Address Management

   One of the first questions facing a multicast application developer
   is what multicast address to use.  Multicast addresses are not
   assigned to individual hosts, assignments can change dynamically, and
   addresses sometimes have semantics of their own (e.g., Admin
   Scoping).  Multicast applications require an address management
   service that provides address allocation or assignment queries.
   There are a number of ways for applications to learn about multicast
   addresses:

      Hard-Coded: Software configuration, encoded in a binary
      executable, or burned into ROM in embedded devices.  These
      applications typically reference IANA statically allocated
      multicast addresses (including relative addresses).

      Advertised: Session announcements (as described in the next
      section), or via another "out-of-band" query or discovery protocol
      mechanism.

      Algorithmically Derived: Using a programmatic algorithm to
      allocate a statistically random (unused) address.

        |
   1toM |    c, e          a, b                d
        |
   MtoM |               f, j, k, n        g, h, i, l, m
        |
   Mto1 |    r            o, p, s             q, t
        |
        +-----------------------------------------------
          Hard-Coded       Advertised      Algorithmic

      Figure 6: Multicast address usage for application types

   In almost all cases, application designers should assume that
   multicast addresses are to be dynamic.  Very little of the multicast
   address space is available for static assignment by IANA [MADDR].
   Also, given the host-specific addressing available with SSM,
   Internet-wide, static address assignment is expected to be very rare.

5.2 Session Management

   Session management is one of the most misunderstood services with
   respect to multicast.  Most application developers assume that
   multicast will provide services like security, encryption,
   reliability, session advertisement, monitoring, billing, etc.  In
   fact, multicast is simply a transport mechanism that provides end-



Quinn, et al.                Informational                     [Page 16]

RFC 3170               IP Multicast Applications          September 2001


   to-end delivery.  All of the other services are application-layer
   services that must be provided by each particular application.
   Furthermore, in most cases there are not defined standards for how
   these functions should be provided.  The particular functions are
   dependent on the particular needs of the application, and no single
   method (or standard) can be made to be sufficient for all cases.

   While there are no generic solutions which provide all session
   management functions, there are some protocols and common techniques
   that provide support for some of the functions.  Techniques for
   congestion control and heterogeneous receiver support are discussed
   in Section 5.3.  Protocols for reliability are discussed in Section
   5.4.  Security considerations are discussed in Section 5.5.

   With respect to session advertisement, there are a number of
   mechanisms for advertising sessions.  One commonly used technique is
   to advertise sessions via the WWW.  Users can join a group by
   clicking on URLs, and then having a response returned to the user
   that includes the group address and maybe information about group
   source(s).  Another mechanism is the session description protocol
   [SDP].  It provides a format for representing information about
   sessions, but it does not provide the transport for dissemination of
   these session descriptions, nor does it provide address allocation
   and management.  SDP only provides the syntax for describing session
   attributes.

   SDP session descriptions may be conveyed publicly or privately by
   means of any number of transports including web (HTTP) and MIME
   encoded email.  The session announcement protocol [SAP] is the de
   facto standard transport and many multicast-enabled applications
   currently use it.  SAP limits distribution via multicast scoping, but
   the current protocol definition has scaling issues that need to be
   addressed.  Specifically, the initialization latency for a session
   directory can be quite long, and it increases in proportion to the
   number of session announcements.  This is to an extent a multicast
   infrastructure issue, however, as this level of protocol detail
   should be transparent to applications.

   The session management service needs to:

     - Advertise scheduled sessions
     - Provide a query mechanism for retrieving
       information about session schedules








Quinn, et al.                Informational                     [Page 17]

RFC 3170               IP Multicast Applications          September 2001


5.3 Heterogeneous Receiver Support

   The Internet is a network of networks.  IP's strength is its ability
   to enable seamless interoperability between hosts on disparate
   network media, the heterogeneous network.

   When two hosts communicate via unicast--one-to-one--across an IP
   network, it is relatively easy for senders to adapt to varying
   network conditions.  The Transmission Control Protocol (TCP) provides
   reliable data transport, and is the model of "network friendly"
   adaptability.

   TCP receivers send acknowledgements back to the sender for data
   delivered.  A TCP sender detects data loss from the data sent that is
   not acknowledged.  When it detects data loss, TCP infers that there
   is network congestion or a low-bandwidth link, and adapts by
   throttling down its send rate [SlowStart].

   User Datagram Protocol (UDP) does not enable a receiver feedback loop
   the way TCP does, since UDP does not provide reliable data delivery
   service.  As a result, it also does not have a loss detection and
   adaptive congestion control mechanism as TCP does.  However, it is
   possible for a unicast UDP application to enable similar adaptive
   algorithms to achieve the same result, or even improve on it.

   A unicast UDP application that uses a feedback mechanism to detect
   data loss and adapt the send rate, can do so better than TCP.  TCP
   automatically reduces the "congestion window" when data loss is
   detected, although the updated send rate may be slower than a CBR
   audio/video stream requires.  When a UDP application detects loss, it
   can adapt the data itself to accommodate the lower send rate.  For
   example, a UDP application can:

     -  Reduce the data resolution (e.g., send lower fidelity
        audio/video by reducing sample frequency or frame rate) to
        reduce data rate.

     -  Modify the data encoding to add redundant data (e.g., forward
        error correction) offset in time to avoid fate sharing.  This
        could also be "layered", so a percentage of data loss will
        simply reduce fidelity rather than corrupt the data.

     -  Reduce the send rate of one datastream in order to favor another
        of higher priority (e.g., sacrifice video in order to ensure
        audio delivery).






Quinn, et al.                Informational                     [Page 18]

RFC 3170               IP Multicast Applications          September 2001


     -  Send data at a lower rate (i.e., with a different encoding) on a
        separate multicast address and/or port number for high-loss
        receivers.

   However, with multicast applications--one-to-many or many-to-many--
   which have multiple receivers, the feedback loop design needs
   modification.  If all receivers return data loss reports
   simultaneously, the sender is easily overwhelmed in the storm of
   replies.  This is known as the "implosion problem".

   Another problem is that heterogeneous receiver capabilities can vary
   widely due to the wide range of (static) network media bandwidth
   capabilities and dynamically due to transient traffic conditions.  If
   a sender adapts its send rate and data resolution based on the loss
   rate of its worst receiver(s), then it can only service the lowest
   common denominator.  Hence, a single "crying baby" can spoil it for
   all other receivers.

   Strategies exist for dealing with these heterogeneous receiver
   problems.  Here are two examples:

     Shared Learning - When loss is detected (i.e., a sequenced packet
        isn't received), a receiver starts a random timer.  If it
        receives a data loss report sent by another receiver as it waits
        for the timer to expire, it stops the timer and does not send a
        report.  Otherwise, it sends a report when the timer expires.
        The Real-Time Protocol and its feedback-loop counterpart Real-
        Time Control Protocol [RTP/RTCP] employ a strategy similar to
        this to keep feedback traffic to 5 percent or less than the
        overall session traffic.  This technique was originally utilized
        in IGMP.

     Local Recovery - Some receivers may be designated as local
        distribution points or "transcoders" that either re-send data
        locally (possibly via unicast) when loss is reported or they re-
        encode the data for lower bandwidth receivers before re-sending.
        No standards exist for these strategies, although "local
        recovery" is used by several reliable multicast protocols.

   Adaptive multicast application design for heterogeneous receivers is
   still an active area of research.  The fundamental requirements are
   to maximize application usability, while accommodating network
   conditions in a "network friendly" manner.  In other words,
   congestion detection and avoidance are (at least) as important in
   protocol design as the user experience.  The adaptive mechanisms must
   also be stable, so they do not adapt too quickly--changing encoding
   and rates based on too little information about what may be a
   transient condition--to avoid oscillation.



Quinn, et al.                Informational                     [Page 19]

RFC 3170               IP Multicast Applications          September 2001


   This "feedback loop" service necessary for support of heterogeneous
   receivers is not illustrated in the services summary in Figure 4,
   although it could be added alongside "Reliable Transport" and the
   others.  This service could be implemented within an application or
   accessed externally, as provided by the operating system or a third
   party.  See [HNRS] for a taxonomy of strategies for providing
   feedback for multicast, with the ultimate goal of developing a common
   multicast feedback protocol.

5.4 Reliable Data Delivery

   Many of the multicast application examples in our list--like
   audio/video distribution--have loss-tolerant data content.  In other
   words, the data content itself can remain useful even if some of it
   is lost.  For example, audio might have a short gap or lower fidelity
   but will remain intelligible despite some data loss.

   Other application examples--like caching and synchronized resources-
   -require reliable data delivery.  They deliver content that must be
   complete, unchanged, in sequence, and without duplicates.  The "Loss
   Intolerant" column in Figure 7 shows a list of applications with this
   requirement, while the others can tolerate varying levels of data
   loss.  The tolerance levels are typically determined by the nature of
   the data and the encoding in use.

        |
   1toM |     b             a, d               c, e
        |
   MtoM |             f, j, k, l, m, n       g, h, i
        |
   Mto1 |                o, p, r, s, t          q
        |
        +------------------------------------------------
          Loss Tolerant                   Loss Intolerant

      Figure 7: Reliability Requirements of Application types

   Some of the challenges involved with enabling reliable multicast
   transport are the same as those of sending to heterogeneous
   receivers, and some solutions are similar also.  For example, many
   reliable multicast transport protocols avoid the implosion problem by
   using negative acknowledgements (NAKs) from receivers to indicate
   what was lost.  They also use "shared learning" whereby receivers
   listen to others' NAKs and then listen for the resulting
   retransmission of data, rather than requesting retransmission by
   sending a NAK themselves.





Quinn, et al.                Informational                     [Page 20]

RFC 3170               IP Multicast Applications          September 2001


   Although reliable delivery cannot change the data sent--except,
   perhaps, to use a loss-less data compression algorithm--they can use
   other adaptive techniques like sending redundant data, or adjusting
   the send rate.

   Although many reliable multicast protocol implementations exist
   [Obraczka], and a few are already available in commercial products,
   none of them are standardized.  Work is ongoing in the "Reliable
   Multicast" research group of the Internet Research Task Force [IRTF]
   to provide a better definition of the problem, the multicast
   transport requirements, and protocol mechanisms.

   Scalability is the paramount concern, and it implies the general need
   for "network friendly" protocols that detect and avoid congestion as
   they provide reliable delivery.  Other considerations are protocol
   robustness, support for "late joins", group management and security
   (which we discuss next).

   The current consensus is that due to the wide variety of multicast
   application requirements--some of which are at odds--no single
   multicast transport will likely be appropriate for all applications.
   As a result, most believe that we will eventually standardize a
   number of reliable multicast protocols, rather than a single one
   [BULK, RMT].

5.5 Security

   For any IP network application--unicast or multicast--security is
   necessary because networks comprise users with different levels of
   trust.

   Network application security is challenging, even for unicast.  And
   as the need for security increases--gauged by the risks of being
   without it--the challenges increase also.  Security system complexity
   and overhead is commensurate with the protection it provides.  "No
   one can guarantee 100% security.  But we can work toward 100% risk
   acceptance...Strong cryptography can withstand targeted attacks up to
   a point--the point at which it becomes easier to get the information
   some other way...A good design starts with a threat model: what the
   system is designed to protect, from whom, and for how long."
   [Schneier]

   Multicast applications are no different than unicast applications
   with respect to their need for security, and they require the same
   basic security services: user authentication, data integrity, data
   privacy and user privacy (anonymity).  However, enabling security for





Quinn, et al.                Informational                     [Page 21]

RFC 3170               IP Multicast Applications          September 2001


   multicast applications is even more of a challenge than for unicast.
   Having multiple receivers makes a difference, as does their
   heterogeneity and the dynamic nature of multicast group memberships.

   Multicast security requirements can include any combination of the
   following services:

      Limiting Senders   - Controlling who can send to group addresses

      Limiting Receivers - Controlling who can receive

      Limiting Access    - Controlling who can "read" multicast content
      either by encrypting content or limiting receivers (which isn't
      possible yet)

      Verifying Content  - Ensuring that data originated from an
      authenticated sender and was not altered en route

      Protecting Receiver Privacy - Controlling whether sender(s) or
      other receivers know receiver identity

      Firewall Traversal - Proxying outgoing "join" requests through
      firewalls, allowing incoming or outgoing traffic through, and
      (possibly) authenticating receivers for filtering purposes and
      security [Finlayson].

   This list is not comprehensive, but includes the most commonly needed
   security services.  Different multicast applications and different
   application contexts can have very different needs with respect to
   these services, and others.  Two main issues emerge, where the
   performance of current solutions leaves much to be desired [MSec].

      Individual authentication - how is sender identity verified for
      each multicast datagram received?

      Membership revocation - how is further group access disabled for
      group members that leave the group (e.g., encryption keys in their
      possession disabled)?

   Performance is largely a factor when a user joins or leaves a group.
   For example, methods used to authenticate potential group members
   during joins or re-keying current members after a member leaves can
   involve significant processing and protocol overhead and result in
   significant delays that affect usability.







Quinn, et al.                Informational                     [Page 22]

RFC 3170               IP Multicast Applications          September 2001


   Like reliable multicast, secure multicast is also under investigation
   in the Internet Research Task Force [IRTF].  Protocol mechanisms for
   many of the most important of these services--such as limiting
   senders--have not yet been defined, let alone developed and deployed.

   As is true for reliable multicast, the current consensus is that no
   single security protocol will satisfy the wide diversity of
   sometimes-contradictory requirements among multicast applications.
   Hence, multicast security will also likely require a number of
   different protocols.

5.6 Synchronized Play-Out

   This refers to having all receivers simultaneously play-out the
   multicast data they received.  This may be necessary for fairness--
   playing-out prices for auctions, or stock-prices--or to ensure
   synchronization with other receivers, such as when playing music.

   Here is an analogy to illustrate: Imagine a multi-speaker stereo
   system that is wired throughout a home (via analog).  With the stereo
   playing on all speaker sets, you will hear continuous music as you
   walk from room-to-room.

   Now imagine a house full of multi-media and network enabled computer
   systems.  Although they will all receive the same music datastream
   simultaneously via multicast, they will provide discontinuous music
   playback as you walk room-to-room.

   To provide synchronized playback that would enable continuous music
   from room-to-room would require three things:

      1) system clocks on all systems should be synchronized
      2) datastreams must be framed with timestamps
      3) you must know the playback latency of the multimedia hardware

   The third of these is the most difficult to achieve at this time.
   Hardware and drivers don't provide any mechanism for retrieving this
   information, although different audio and video devices have a wide-
   range of performance.

6. Service APIs

   In some cases, the protocol services mentioned in this document can
   be enabled transparently by passive configuration mechanisms and
   "middleware". For example, it is conceivable that a UDP
   implementation could implicitly enable a reliable multicast protocol
   without the explicit interaction of the application.




Quinn, et al.                Informational                     [Page 23]

RFC 3170               IP Multicast Applications          September 2001


   Sometimes, however, applications need explicit access to these
   services for flexibility and control.  For example, an adaptive
   application sending to a heterogeneous group of receivers using RTP
   may need to process RTCP reports from receivers in order to adapt
   accordingly (by throttling send rate or changing data encoders, for
   example) [RTP API].  Hence, there is often a need for service APIs
   that allow an application to qualify and initiate service requests,
   and receive event notifications.  In Figure 5, the top edge of the
   box for each service effectively represents its API.

   Network APIs generally reflect the protocols they support.  Their
   functionality and argument values are a (varying) subset of protocol
   message types, header fields and values.  Although some protocol
   details and actions may not be exposed in APIs--since many protocol
   mechanics need not be exposed--others are crucial to efficient and
   flexible application operation.

   A more complete examination of the application services described in
   this document might also identify the protocol features that could be
   mapped to define a (generic) API definition for that service.  APIs
   are often controversial, however.  Not only are there many language
   differences, but it is also possible to create different APIs by
   exposing different levels of detail in trade-offs between flexibility
   and simplicity.

7. Security Considerations

   See section 5.4

8. Acknowledgements

   The authors would like to acknowledge and thank the following
   individuals for their helpful feedback: Ran Canetti, Brian Haberman,
   Eric A. Hall, Kenneth C. Miller, and Dave Thaler.

9. References

   [AnyCast]   Partridge, C., Mendez, T. and W. Milliken, "Host
               Anycasting Service", RFC 1546, November 1993.

   [BeauW]     B. Williamson, "Developing IP Multicast Networks, Volume
               I", (c) 2000 Cisco Press, Indianapolis IN, ISBN 1-57870-
               077-9.

   [BULK]      Whetten, B., Vicisano, L., Kermode, R., Handley, M.,
               Floyd, S. and M. Luby, "Reliable Multicast Transport
               Building Blocks for One-to-Many Bulk-Data Transfer", RFC
               3048, January 2001.



Quinn, et al.                Informational                     [Page 24]

RFC 3170               IP Multicast Applications          September 2001


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

   [DIS]       Pullen, J., Mytak, M. and C. Bouwens, "Limitations of
               Internet Protocol Suite for Distributed Simulation in the
               Large Multicast Environment", RFC 2502, February 1999.

   [E2EQOS]    Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L.,
               Speer, M., Braden, R. and B. Davie, "Integrated Services
               Operation over Diffserv Networks", RFC 2998, November
               2000.

   [Estrin]    D. Estrin, "Multicast: Enabler and Challenge", Caltech
               Earthlink Seminar Series, April 22, 1998.

   [Finlayson] Finlayson, R., "IP Multicast and Firewalls", RFC 2588,
               May 1999.

   [HNRS]      Hofman, Nonnenmacher, Rosenberg, Schulzrinne, "A Taxonomy
               of Feedback for Multicast", June 1999, Work in Progress.

   [IGMPv2]    Fenner, B., "Internet Group Management Protocol, Version
               2", RFC 2236, November 1997.

   [IGMPv3]    Cain, B., Deering, S., Kouvelas, I. and A. Thyagarajan,
               "Internet Group Management Protocol, Version 3", Work in
               Progress.

   [IMJ]       K. Almeroth and M. Ammar, "The Interactive Multimedia
               Jukebox (IMJ): A New Paradigm for the On-Demand Delivery
               of Audio/Video", Proceedings of the Seventh International
               World Wide Web Conference, Brisbane, AUSTRALIA, April
               1998.

   [IRTF]      Weinrib, A. and J. Postel, "The IRTF Guidelines and
               Procedures", BCP 8, RFC 2014, January 1996.

   [Kermode]   Kermode, R., "MADCAP Multicast Scope Nesting State
               Option", RFC 2907, September 2000.

   [LSMA]      Bagnall, P., Briscoe, R. and A. Poppitt, "Taxonomy of
               Communication Requirements for Large-scale Multicast
               Applications", RFC 2729, December 1999.

   [MADDR]     Albanna, Z., Almeroth, K., Meyer, D. and M. Schipper,
               "IANA Guidelines for IPv4 Multicast Address Assignments",
               BCP 51, RFC 3171, August 2001.




Quinn, et al.                Informational                     [Page 25]

RFC 3170               IP Multicast Applications          September 2001


   [MASC]      Estrin, D., Govindan, R., Handley, M., Kumar, S.,
               Radoslavov, P. and D. Thaler, "The Multicast Address-Set
               Claim (MASC) Protocol", RFC 2909, September 2000.

   [Maufer]    T. Maufer, "Deploying IP Multicast in the Enterprise",
               (c) 1998 Prentice Hall, Upper Saddle River NJ ISBN 0-13-
               897687-2.

   [Miller]    C. K. Miller, "Multicast Networking and Applications",
               (c) 1999 Addison Wesley Longman, Reading MA ISBN 0-201-
               30979-3.

   [MADCAP]    Hanna, S., Patel, B. and M. Shah, "Multicast Address
               Dynamic Client Allocation Protocol (MADCAP)", RFC 2730,
               December 1999.

   [MRM]       K. Sarac, K. Almeroth, "Supporting Multicast Deployment
               Efforts: A Survey of Tools for Multicast Monitoring",
               Journal of High Speed Networking--Special Issue on
               Management of Multimedia Networking, March 2001

   [MSec]      Multicast Security (msec) IETF Working Group charter

   [MZAP]      Handley, M., Thaler, D. and R. Kermode, "Multicast-Scope
               Zone Announcement Protocol (MZAP)", RFC 2776, February
               2000.

   [Obraczka]  K. Obraczka "Multicast Transport Mechanisms: A Survey and
               Taxonomy", IEEE Communications Magazine, Vol. 36 No. 1,
               January 1998.

   [Rizzo]     L. Rizzo, "Fast Group management in IGMP", HIPPARC 98
               workshop, June 1998, UCL London
               http://www.iet.unipi.it/~luigi/hipparc98.ps.gz

   [RM]        Mankin, A.,  Romanow, A., Bradner, S. and V. Paxson,
               "IETF Criteria for Evaluating Reliable Multicast
               Transport and Application Protocols", RFC 2357, June
               1998.

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

   [RTP API]   H. Schulzrinne, et al, "RTP Library API Specification,"
               http://www.cs.columbia.edu/IRT/software/rtplib/rtplib-
               1.0a1/rtp_api.html





Quinn, et al.                Informational                     [Page 26]

RFC 3170               IP Multicast Applications          September 2001


   [RTP/RTCP]  Schulzrinne, H., Casner, S., Frederick, R. and V.
               Jacobson, "RTP: A Transport Protocol for Real-Time
               Applications", RFC 1889, January 1996.

   [SAP]       Handley, M., Perkins, C. and E. Whelan, "Session
               Announcement Protocol", RFC 2974, October 2000.

   [SDP]       Handley, M., and V. Jacobson, "SDP: Session Description
               Protocol", RFC 2327, April 1998.

   [Schneier]  B. Schneier, "Why Cryptography Is Harder Than It Looks",
               December 1996, http://www.counterpane.com/whycrypto.html

   [SlowStart] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast
               Retransmit, and Fast Recovery Algorithms", RFC 2001,
               January 1997.

   [SLP]       Veizades, J., Guttman, E., Perkins, C. and S. Kaplan,
               "Service Location Protocol", RFC 2165, June 1997.

   [SSM]       Holbrook, H. and B. Cain, "Specific Multicast for IP",
               Work in Progress.

10. Authors' Addresses

   Bob Quinn
   Celox Networks
   2 Park Central Drive
   Southborough, MA 01772

   Phone: +1 508 305 7000
   EMail: bquinn@celoxnetworks.com


   Kevin Almeroth
   Department of Computer Science
   University of California
   Santa Barbara, CA 93106-5110

   Phone: +1 805 893 2777
   EMail: almeroth@cs.ucsb.edu










Quinn, et al.                Informational                     [Page 27]

RFC 3170               IP Multicast Applications          September 2001


11.  Full Copyright Statement

   Copyright (C) The Internet Society (2001).  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.

Acknowledgement

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



















Quinn, et al.                Informational                     [Page 28]