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
|
Network Working Group P. Savola
Request for Comments: 5110 CSC/FUNET
Category: Informational January 2008
Overview of the Internet Multicast Routing Architecture
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.
Abstract
This document describes multicast routing architectures that are
currently deployed on the Internet. This document briefly describes
those protocols and references their specifications.
This memo also reclassifies several older RFCs to Historic. These
RFCs describe multicast routing protocols that were never widely
deployed or have fallen into disuse.
Table of Contents
1. Introduction ....................................................3
1.1. Multicast-Related Abbreviations ............................4
2. Multicast Routing ...............................................4
2.1. Setting up Multicast Forwarding State ......................5
2.1.1. PIM-SM ..............................................5
2.1.2. PIM-DM ..............................................5
2.1.3. Bidirectional PIM ...................................6
2.1.4. DVMRP ...............................................6
2.1.5. MOSPF ...............................................7
2.1.6. BGMP ................................................7
2.1.7. CBT .................................................7
2.1.8. Interactions and Summary ............................7
2.2. Distributing Topology Information ..........................8
2.2.1. Multiprotocol BGP ...................................8
2.2.2. OSPF/IS-IS Multi-Topology Extensions ................9
2.2.3. Issue: Overlapping Unicast/Multicast Topology .......9
2.2.4. Summary ............................................10
2.3. Learning (Active) Sources .................................10
2.3.1. SSM ................................................11
2.3.2. MSDP ...............................................11
2.3.3. Embedded-RP ........................................11
2.3.4. Summary ............................................12
Savola Informational [Page 1]
^L
RFC 5110 Multicast Routing Overview January 2008
2.4. Configuring and Distributing PIM RP Information ...........12
2.4.1. Manual RP Configuration ............................12
2.4.2. Embedded-RP ........................................13
2.4.3. BSR and Auto-RP ....................................13
2.4.4. Summary ............................................14
2.5. Mechanisms for Enhanced Redundancy ........................14
2.5.1. Anycast RP .........................................14
2.5.2. Stateless RP Failover ..............................14
2.5.3. Bidirectional PIM ..................................15
2.5.4. Summary ............................................15
2.6. Interactions with Hosts ...................................15
2.6.1. Hosts Sending Multicast ............................15
2.6.2. Hosts Receiving Multicast ..........................15
2.6.3. Summary ............................................16
2.7. Restricting Multicast Flooding in the Link Layer ..........16
2.7.1. Router-to-Router Flooding Reduction ................16
2.7.2. Host/Router Flooding Reduction .....................17
2.7.3. Summary ............................................18
3. Acknowledgements ...............................................18
4. IANA Considerations ............................................18
5. Security Considerations ........................................19
6. References .....................................................19
6.1. Normative References ......................................19
6.2. Informative References ....................................20
Appendix A. Multicast Payload Transport Extensions.................24
A.1. Reliable Multicast.........................................24
A.2. Multicast Group Security...................................24
Savola Informational [Page 2]
^L
RFC 5110 Multicast Routing Overview January 2008
1. Introduction
This document provides a brief overview of multicast routing
architectures that are currently deployed on the Internet and how
those protocols fit together. It also describes those multicast
routing protocols that were never widely deployed or have fallen into
disuse. A companion document [ADDRARCH] describes multicast
addressing architectures.
Specifically, this memo deals with:
o setting up multicast forwarding state (Section 2.1),
o distributing multicast topology information (Section 2.2),
o learning active sources (Section 2.3),
o configuring and distributing the rendezvous point (RP) information
(Section 2.4),
o mechanisms for enhanced redundancy (Section 2.5),
o interacting with hosts (Section 2.6), and
o restricting the multicast flooding in the link layer
(Section 2.7).
Section 2 starts by describing a simplistic example how these classes
of mechanisms fit together. Some multicast data transport issues are
also introduced in Appendix A.
This memo reclassifies to Historic [RFC2026] the following RFCs:
o Border Gateway Multicast Protocol (BGMP) [RFC3913],
o Core Based Trees (CBT) [RFC2189] [RFC2201],
o Multicast OSPF (MOSPF) [RFC1584].
For the most part, these protocols have fallen into disuse. There
may be legacy deployments of some of these protocols, which are not
affected by this reclassification. See Section 2.1 for more on each
protocol.
Further historical perspective may be found in, for example,
[RFC1458], [IMRP-ISSUES], and [IM-GAPS].
Savola Informational [Page 3]
^L
RFC 5110 Multicast Routing Overview January 2008
1.1. Multicast-Related Abbreviations
ASM Any Source Multicast
BGMP Border Gateway Multicast Protocol
BSR Bootstrap Router
CBT Core Based Trees
CGMP Cisco Group Management Protocol
DR Designated Router
DVMRP Distance Vector Multicast Routing Protocol
GARP (IEEE 802.1D-2004) Generic Attribute Registration
Protocol
GMRP GARP Multicast Registration Protocol
IGMP Internet Group Management Protocol
MBGP Multiprotocol BGP (*not* "Multicast BGP")
MLD Multicast Listener Discovery
MRP (IEEE 802.1ak) Multiple Registration Protocol
MMRP (IEEE 802.1ak) Multicast Multiple Registration
Protocol
MOSPF Multicast OSPF
MSDP Multicast Source Discovery Protocol
PGM Pragmatic General Multicast
PIM Protocol Independent Multicast
PIM-DM PIM - Dense Mode
PIM-SM PIM - Sparse Mode
PIM-SSM PIM - Source-Specific Multicast
RGMP (Cisco's) Router Group Management Protocol
RP Rendezvous Point
RPF Reverse Path Forwarding
SAFI Subsequent Address Family Identifier
SDP Session Description Protocol
SSM Source-Specific Multicast
2. Multicast Routing
In order to give a simplified summary how each of these class of
mechanisms fits together, consider the following multicast receiver
scenario.
Certain protocols and configurations need to be in place before
multicast routing can work. Specifically, when ASM is employed, a
router will need to know its RP address(es) (Section 2.4,
Section 2.5). With IPv4, RPs need to be connected to other RPs using
MSDP so information about sources connected to other RPs can be
distributed (Section 2.3). Further, routers need to know if or how
multicast topology differs from unicast topology, and routing
protocol extensions can provide that information (Section 2.2).
Savola Informational [Page 4]
^L
RFC 5110 Multicast Routing Overview January 2008
When a host wants to receive a transmission, it first needs to find
out the multicast group address (and with SSM, source address) using
various means (e.g., SDP description file [RFC4566] or manually).
Then it will signal its interest to its first-hop router using IGMP
(IPv4) or MLD (IPv6) (Section 2.6). The router initiates setting up
hop-by-hop multicast forwarding state (Section 2.1) to the source (in
SSM) or first through the RP (in ASM). Routers use an RP to find out
all the sources for a group (Section 2.3). When multicast
transmission arrives at the receiver's LAN, it is flooded to every
Ethernet switch port unless flooding reduction such as IGMP snooping
is employed (Section 2.7).
2.1. Setting up Multicast Forwarding State
The most important part of multicast routing is setting up the
multicast forwarding state. State maintenance requires periodic
messaging because forwarding state has a timeout. This section
describes the protocols commonly used for this purpose.
2.1.1. PIM-SM
By far, the most common multicast routing protocol is PIM-SM
[RFC4601]. The PIM-SM protocol includes both Any Source Multicast
(ASM) and Source-Specific Multicast (SSM) functionality. PIM-SSM is
a subset of PIM-SM that does not use the RPs but instead requires
that receivers know the (source,group) pair and signal that
explicitly. Most current routing platforms support PIM-SM.
PIM routers elect a designated router on each LAN and the DR is
responsible for PIM messaging and source registration on behalf of
the hosts. The DR encapsulates multicast packets sourced from the
LAN in a unicast tunnel to the RP. PIM-SM builds a unidirectional,
group-specific distribution tree consisting of the interested
receivers of a group. Initially, the multicast distribution tree is
rooted at the RP but later the DRs have the option of optimizing the
delivery by building (source,group)-specific trees.
A more lengthy introduction to PIM-SM can be found in Section 3 of
[RFC4601].
2.1.2. PIM-DM
Whereas PIM-SM has been designed to avoid unnecessary flooding of
multicast data, PIM-DM [RFC3973] assumed that almost every subnet at
a site had at least one receiver for a group. PIM-DM floods
multicast transmissions throughout the network ("flood and prune")
unless the leaf parts of the network periodically indicate that they
are not interested in that particular group.
Savola Informational [Page 5]
^L
RFC 5110 Multicast Routing Overview January 2008
PIM-DM may be an acceptable fit in small and/or simple networks,
where setting up an RP would be unnecessary, and possibly in cases
where a large percentage of users are expected to want to receive the
transmission so that the amount of state the network has to keep is
minimal.
PIM-DM was used as a first step in transitioning away from DVMRP. It
also became apparent that most networks would not have receivers for
most groups, and to avoid the bandwidth and state overhead, the
flooding paradigm was gradually abandoned. Transitioning from PIM-DM
to PIM-SM was easy as PIM-SM was designed to use compatible packet
formats and dense-mode operation could also be satisfied by a sparse
protocol. PIM-DM is no longer in widespread use.
Many implementations also support so-called "sparse-dense"
configuration, where Sparse mode is used by default, but Dense is
used for configured multicast group ranges (such as Auto-RP in
Section 2.4.3) only. Lately, many networks have transitioned away
from sparse-dense to only sparse mode.
2.1.3. Bidirectional PIM
Bidirectional PIM [RFC5015] is a multicast forwarding protocol that
establishes a common shared-path for all sources with a single root.
It can be used as an alternative to PIM-SM inside a single domain.
It doesn't have data-driven events or data-encapsulation. As it
doesn't keep source-specific state, it may be an appealing approach
especially in sites with a large number of sources.
As of this writing, there is no inter-domain solution to configure a
group range to use bidirectional PIM.
2.1.4. DVMRP
Distance Vector Multicast Routing Protocol (DVMRP) [RFC1075]
[DVMRPv3] [DVMRPv3-AS] was the first protocol designed for
multicasting. To get around initial deployment hurdles, it also
included tunneling capabilities, which were part of its multicast
topology functions.
Currently, DVMRP is used only very rarely in operator networks,
having been replaced with PIM-SM. The most typical deployment of
DVMRP is at a leaf network, to run from a legacy firewall only
supporting DVMRP to the internal network. However, Generic Routing
Encapsulation (GRE) tunneling [RFC2784] seems to have overtaken DVMRP
in this functionality, and there is relatively little use for DVMRP
except in legacy deployments.
Savola Informational [Page 6]
^L
RFC 5110 Multicast Routing Overview January 2008
2.1.5. MOSPF
MOSPF [RFC1584] was implemented by several vendors and has seen some
deployment in intra-domain networks. However, since it is based on
intra-domain Open Shortest Path First (OSPF) it does not scale to the
inter-domain case, operators have found it is easier to deploy a
single protocol for use in both intra-domain and inter-domain
networks and so it is no longer being actively deployed.
2.1.6. BGMP
BGMP [RFC3913] did not get sufficient support within the service
provider community to get adopted and moved forward in the IETF
standards process. There were no reported production implementations
and no production deployments.
2.1.7. CBT
CBT [RFC2201][RFC2189] was an academic project that provided the
basis for PIM sparse mode shared trees. Once the shared tree
functionality was incorporated into PIM implementations, there was no
longer a need for a production CBT implementation. Therefore, CBT
never saw production deployment.
2.1.8. Interactions and Summary
It is worth noting that it is possible to run different protocols
with different multicast group ranges. For example, treat some
groups as dense or bidirectional in an otherwise PIM-SM network; this
typically requires manual configuration of the groups or a mechanism
like BSR (Section 2.4.3). It is also possible to interact between
different protocols; for example, use DVMRP in the leaf network, but
PIM-SM upstream. The basics for interactions among different
protocols have been outlined in [RFC2715].
The following figure gives a concise summary of the deployment status
of different protocols as of this writing.
Savola Informational [Page 7]
^L
RFC 5110 Multicast Routing Overview January 2008
+--------------+--------------+----------------+
| Inter-domain | Intra-domain | Status |
+------------+--------------+--------------+----------------+
| PIM-SM | Yes | Yes | Active |
| PIM-DM | Not anymore | Not anymore | Little use |
| BIDIR-PIM | No | Yes | Some uptake |
| DVMRP | Not anymore | Stub only | Going out |
| MOSPF | No | Not anymore | Inactive |
| CBT | No | No | Never deployed |
| BGMP | No | No | Never deployed |
+------------+--------------+--------------+----------------+
From this table, it is clear that PIM-Sparse Mode is the only
multicast routing protocol that is deployed inter-domain and,
therefore, is most frequently used within multicast domains as well.
2.2. Distributing Topology Information
PIM has become the de-facto multicast forwarding protocol, but as its
name implies, it is independent of the underlying unicast routing
protocol. When unicast and multicast topologies are the same
("congruent"), i.e., use the same routing tables (routing information
base, RIB), it has been considered sufficient just to distribute one
set of reachability information to be used in conjunction with a
protocol that sets up multicast forwarding state (e.g., PIM-SM).
However, when PIM which by default built multicast topology based on
the unicast topology gained popularity, it became apparent that it
would be necessary to be able to distribute also non-congruent
multicast reachability information in the regular unicast protocols.
This was previously not an issue, because DVMRP built its own
reachability information.
The topology information is needed to perform efficient distribution
of multicast transmissions and to prevent transmission loops by
applying it to the Reverse Path Forwarding (RPF) check.
This subsection introduces these protocols.
2.2.1. Multiprotocol BGP
Multiprotocol Extensions for BGP-4 [RFC4760] (often referred to as
"MBGP"; however, it is worth noting that "MBGP" does *not* stand for
"Multicast BGP") specifies a mechanism by which BGP can be used to
distribute different reachability information for unicast (SAFI=1)
and multicast traffic (SAFI=2). Multiprotocol BGP has been widely
Savola Informational [Page 8]
^L
RFC 5110 Multicast Routing Overview January 2008
deployed for years, and is also needed to route IPv6. Note that
SAFI=3 was originally specified for "both unicast and multicast" but
has since then been deprecated.
These extensions are in widespread use wherever BGP is used to
distribute unicast topology information. Multicast-enabled networks
that use BGP should use Multiprotocol BGP to distribute multicast
reachability information explicitly even if the topologies are
congruent to make an explicit statement about multicast reachability.
A number of significant multicast transit providers even require
this, by doing the RPF lookups solely based on explicitly advertised
multicast address family.
2.2.2. OSPF/IS-IS Multi-Topology Extensions
Similar to BGP, some Interior Gateway Protocols (IGPs) also provide
the capability for signalling differing topologies, for example IS-IS
multi-topology extensions [M-ISIS]. These can be used for a
multicast topology that differs from unicast. Similar but not so
widely implemented work exists for OSPF [RFC4915].
It is worth noting that inter-domain incongruence and intra-domain
incongruence are orthogonal, so one doesn't require the other.
Specifically, inter-domain incongruence is quite common, while intra-
domain incongruence isn't, so you see much more deployment of MBGP
than MT-ISIS/OSPF. Commonly deployed networks have managed well
without protocols handling intra-domain incongruence. However, the
availability of multi-topology mechanisms may in part replace the
typically used workarounds such as tunnels.
2.2.3. Issue: Overlapping Unicast/Multicast Topology
An interesting case occurs when some routers do not distribute
multicast topology information explicitly while others do. In
particular, this happens when some multicast sites in the Internet
are using plain BGP while some use MBGP.
Different implementations deal with this in different ways.
Sometimes, multicast RPF mechanisms first look up the multicast
routing table, or M-RIB ("topology database") with a longest prefix
match algorithm, and if they find any entry (including a default
route), that is used; if no match is found, the unicast routing table
is used instead.
An alternative approach is to use longest prefix match on the union
of multicast and unicast routing tables; an implementation technique
here is to copy the whole unicast routing table over to the multicast
routing table. The important point to remember here, though, is to
Savola Informational [Page 9]
^L
RFC 5110 Multicast Routing Overview January 2008
not override the multicast-only routes; if the longest prefix match
would find both a (copied) unicast route and a multicast-only route,
the latter should be treated as preferable.
Another implemented approach is to just look up the information in
the unicast routing table, and provide the user capabilities to
change that as appropriate, using for example copying functions
discussed above.
2.2.4. Summary
A congruent topology can be deployed using unicast routing protocols
that provide no support for a separate multicast topology. In intra-
domain that approach is often adequate. However, it is recommended
that if inter-domain routing uses BGP, multicast-enabled sites should
use MP-BGP SAFI=2 for multicast and SAFI=1 for unicast even if the
topology was congruent to explicitly signal "yes, we use multicast".
The following table summarizes the approaches that can be used to
distribute multicast topology information.
+----------------+--------------+
| Inter-domain | Intra-domain |
+--------------------- +----------------+--------------+
| MP-BGP SAFI=2 | Yes | Yes |
| MP-BGP SAFI=3 | Doesn't work | Doesn't work |
| IS-IS multi-topology | Not applicable | Yes |
| OSPF multi-topology | Not applicable | Few implem. |
+----------------------+----------------+--------------+
"Not applicable" refers to the fact that IGP protocols can't be used
in inter-domain routing. "Doesn't work" means that while MP-BGP
SAFI=3 was defined and could apply, that part of the specification
has not been implemented and can't be used in practice. "Yes" lists
the mechanisms which are generally applicable and known to work.
"Few implem." means that the approach could work but is not commonly
available.
2.3. Learning (Active) Sources
To build a multicast distribution tree, the routing protocol needs to
find out where the sources for the group are. In case of SSM, the
user specifies the source IP address or it is otherwise learned out
of band.
In ASM, the RPs know about all the active sources in a local PIM
domain. As a result, when PIM-SM or BIDIR-PIM is used in intra-
domain the sources are learned as a feature of the protocol itself.
Savola Informational [Page 10]
^L
RFC 5110 Multicast Routing Overview January 2008
Having a single PIM-SM domain for the whole Internet is an
insufficient model for many reasons, including scalability,
administrative boundaries, and different technical tradeoffs.
Therefore, it is required to be able to split up the multicast
routing infrastructures to smaller domains, and there must be a way
to share information about active sources using some mechanism if the
ASM model is to be supported.
This section discusses the options of learning active sources that
apply in an inter-domain environment.
2.3.1. SSM
Source-specific Multicast [RFC4607] (sometimes also referred to as
"single-source Multicast") does not count on learning active sources
in the network. Recipients need to know the source IP addresses
using an out of band mechanism which are used to subscribe to the
(source, group) channel. The multicast routing uses the source
address to set up the state and no further source discovery is
needed.
As of this writing, there are attempts to analyze and/or define out-
of-band source discovery functions which would help SSM in particular
[DYNSSM-REQ].
2.3.2. MSDP
Multicast Source Discovery Protocol [RFC3618] was invented as a stop-
gap mechanism, when it became apparent that multiple PIM-SM domains
(and RPs) were needed in the network, and information about the
active sources needed to be propagated between the PIM-SM domains
using some other protocol.
MSDP is also used to share the state about sources between multiple
RPs in a single domain for, e.g., redundancy purposes [RFC3446]. The
same can be achieved using PIM extensions [RFC4610]. See Section 2.5
for more information.
There is no intent to define MSDP for IPv6, but instead use only SSM
and Embedded-RP [MCAST-ISSUES].
2.3.3. Embedded-RP
Embedded-RP [RFC3956] is an IPv6-only technique to map the address of
the RP to the multicast group address. Using this method, it is
possible to avoid the use of MSDP while still allowing multiple
multicast domains (in the traditional sense).
Savola Informational [Page 11]
^L
RFC 5110 Multicast Routing Overview January 2008
The model works by defining a single RP address for a particular
group for all of the Internet, so there is no need to share state
about that with any other RPs. If necessary, RP redundancy can still
be achieved with Anycast-RP using PIM [RFC4610].
2.3.4. Summary
The following table summarizes the source discovery approaches and
their status.
+------+------+------------------------------+
| IPv4 | IPv6 | Status |
+----------------------+------+------+------------------------------+
| Bidir single domain | Yes | Yes | OK but for intra-domain only |
| PIM-SM single domain | Yes | Yes | OK |
| PIM-SM with MSDP | Yes | No | De-facto v4 inter-domain ASM |
| PIM-SM w/ Embedded-RP| No | Yes | Best inter-domain ASM option |
| SSM | Yes | Yes | No major uptake yet |
+----------------------+------+------+------------------------------+
2.4. Configuring and Distributing PIM RP Information
PIM-SM and BIDIR-PIM configuration mechanisms exist, which are used
to configure the RP addresses and the groups that are to use those
RPs in the routers. This section outlines the approaches.
2.4.1. Manual RP Configuration
It is often easiest just to manually configure the RP information on
the routers when PIM-SM is used.
Originally, static RP mapping was considered suboptimal since it
required explicit configuration changes every time the RP address
changed. However, with the advent of anycast RP addressing, the RP
address is unlikely to ever change. Therefore, the administrative
burden is generally limited to initial configuration. Since there is
usually a fair amount of multicast configuration required on all
routers anyway (e.g., PIM on all interfaces), adding the RP address
statically isn't really an issue. Further, static anycast RP mapping
provides the benefits of RP load sharing and redundancy (see
Section 2.5) without the complexity found in dynamic mechanisms like
Auto-RP and Bootstrap Router (BSR).
With such design, an anycast RP uses an address that is configured on
a loopback interface of the routers currently acting as RPs, and
state is distributed using PIM [RFC4610] or MSDP [RFC3446].
Savola Informational [Page 12]
^L
RFC 5110 Multicast Routing Overview January 2008
Using this technique, each router might only need to be configured
with one, portable RP address.
2.4.2. Embedded-RP
Embedded-RP provides the information about the RP's address in the
group addresses that are delegated to those who use the RP, so unless
no other ASM than Embedded-RP is used, the network administrator only
needs to configure the RP routers.
While Embedded-RP in many cases is sufficient for IPv6, other methods
of RP configuration are needed if one needs to provide ASM service
for other than Embedded-RP group addresses. In particular, service
discovery type of applications may need hard-coded addresses that are
not dependent on local RP addresses.
As the RP's address is exposed to the users and applications, it is
very important to ensure it does not change often, e.g., by using
manual configuration of an anycast address.
2.4.3. BSR and Auto-RP
BSR [RFC5059] is a mechanism for configuring the RP address for
groups. It may no longer be in as wide use with IPv4 as it was
earlier, and for IPv6, Embedded-RP will in many cases be sufficient.
Cisco's Auto-RP is an older, proprietary method for distributing
group to RP mappings, similar to BSR. Auto-RP has little use today.
Both Auto-RP and BSR require some form of control at the routers to
ensure that only valid routers are able to advertise themselves as
RPs. Further, flooding of BSR and Auto-RP messages must be prevented
at PIM borders. Additionally, routers require monitoring that they
are actually using the RP(s) the administrators think they should be
using, for example, if a router (maybe in customer's control) is
advertising itself inappropriately. All in all, while BSR and
Auto-RP provide easy configuration, they also provide very
significant configuration and management complexity.
It is worth noting that both Auto-RP and BSR were deployed before the
use of a manually configured anycast-RP address became relatively
commonplace, and there is actually relatively little need for them
today unless there is a need to configure different properties (e.g.,
sparse, dense, bidirectional) in a dynamic fashion.
Savola Informational [Page 13]
^L
RFC 5110 Multicast Routing Overview January 2008
2.4.4. Summary
The following table summarizes the RP discovery mechanisms and their
status. With the exception of Embedded-RP, each mechanism operates
within a PIM domain.
+------+------+-----------------------+
| IPv4 | IPv6 | Deployment |
+--------------------+------+------+-----------------------+
| Static RP | Yes | Yes | Especially in ISPs |
| Auto-RP | Yes | No | Legacy deployment |
| BSR | Yes | Yes | Some, anycast simpler |
| Embedded-RP | No | Yes | Growing |
+--------------------+------+------+-----------------------+
2.5. Mechanisms for Enhanced Redundancy
Having only one RP in a PIM-SM domain would be a single point of
failure for the whole multicast domain. As a result, a number of
mechanisms have been developed to either eliminate the RP
functionality or to enhance RPs' redundancy, resilience against
failures, and to recover from failures quickly. This section
summarizes these techniques explicitly.
2.5.1. Anycast RP
As mentioned in Section 2.3.2, MSDP is also used to share the state
about sources between multiple RPs in a single domain, e.g., for
redundancy purposes [RFC3446]. The purpose of MSDP in this context
is to share the same state information on multiple RPs for the same
groups to enhance the robustness of the service.
Recent PIM extensions [RFC4610] also provide this functionality. In
contrast to MSDP, this approach works for both IPv4 and IPv6.
2.5.2. Stateless RP Failover
While Anycast RP shares state between RPs so that RP failure causes
only small disturbance, stateless approaches are also possible with a
more limited resiliency. A traditional mechanism has been to use
Auto-RP or BSR (see Section 2.4.3) to select another RP when the
active one failed. However, the same functionality could be achieved
using a shared-unicast RP address ("anycast RP without state
sharing") without the complexity of a dynamic mechanism. Further,
Anycast RP offers a significantly more extensive failure mitigation
strategy, so today there is actually very little need to use
stateless failover mechanisms, especially dynamic ones, for
redundancy purposes.
Savola Informational [Page 14]
^L
RFC 5110 Multicast Routing Overview January 2008
2.5.3. Bidirectional PIM
Because bidirectional PIM (see Section 2.1.3) does not switch to
shortest path tree (SPT), the final multicast tree may be established
faster. On the other hand, PIM-SM or SSM may converge more quickly
especially in scenarios (e.g., unicast routing change) where
bidirectional needs to re-do the Designated Forwarder election.
2.5.4. Summary
The following table summarizes the techniques for enhanced
redundancy.
+------+------+-----------------------+
| IPv4 | IPv6 | Deployment |
+--------------------+------+------+-----------------------+
| Anycast RP w/ MSDP | Yes | No | De-facto approach |
| Anycast RP w/ PIM | Yes | Yes | Newer approach |
| Stateless RP fail. | Yes | Yes | Causes disturbance |
| BIDIR-PIM | Yes | Yes | Deployed at some sites|
+--------------------+------+------------------------------+
2.6. Interactions with Hosts
Previous sections have dealt with the components required by routers
to be able to do multicast routing. Obviously, the real users of
multicast are the hosts: either sending or receiving multicast. This
section describes the required interactions with hosts.
2.6.1. Hosts Sending Multicast
After choosing a multicast group through a variety of means, hosts
just send the packets to the link-layer multicast address, and the
designated router will receive all the multicast packets and start
forwarding them as appropriate. A host does not need to be a member
of the group in order to send to it [RFC1112].
In intra-domain or Embedded-RP scenarios, ASM senders may move to a
new IP address without significant impact on the delivery of their
transmission. SSM senders cannot change the IP address unless
receivers join the new channel or the sender uses an IP mobility
technique that is transparent to the receivers.
2.6.2. Hosts Receiving Multicast
Hosts signal their interest in receiving a multicast group or channel
by the use of IGMP [RFC3376] and MLD [RFC3810]. IGMPv2 and MLDv1 are
still commonplace, but are also often used in new deployments. Some
Savola Informational [Page 15]
^L
RFC 5110 Multicast Routing Overview January 2008
vendors also support SSM mapping techniques for receivers which use
an older IGMP/MLD version where the router maps the join request to
an SSM channel based on various, usually complex means of
configuration.
2.6.3. Summary
The following table summarizes the techniques host interaction.
+-------+------+----------------------------+
| IPv4 | IPv6 | Notes |
+--------------------+-------+------+----------------------------+
| Host sending | Yes | Yes | No support needed |
| Host receiving ASM | IGMP | MLD | Any IGMP/MLD version |
| Host receiving SSM | IGMPv3| MLDv2| Any version w/ SSM-mapping |
+--------------------+-------+------+----------------------------+
2.7. Restricting Multicast Flooding in the Link Layer
Multicast transmission in the link layer, for example Ethernet,
typically includes some form of flooding the packets through a LAN.
This causes unnecessary bandwidth usage and discarding unwanted
frames on those nodes which did not want to receive the multicast
transmission.
Therefore a number of techniques have been developed, to be used in
Ethernet switches between routers, or between routers and hosts, to
limit the flooding.
Some mechanisms operate with IP addresses, others with MAC addresses.
If filtering is done based on MAC addresses, hosts may receive
unnecessary multicast traffic (filtered out in the hosts' IP layer)
if more than one IP multicast group addresses maps into the same MAC
address, or if IGMPv3/MLDv2 source filters are used. Filtering based
on IP destination addresses, or destination and sources addresses,
will help avoid these but requires parsing of the Ethernet frame
payload.
These options are discussed in this section.
2.7.1. Router-to-Router Flooding Reduction
A proprietary solution, Cisco's RGMP [RFC3488] has been developed to
reduce the amount of flooding between routers in a switched networks.
This is typically only considered a problem in some Ethernet-based
Internet Exchange points or VPNs.
Savola Informational [Page 16]
^L
RFC 5110 Multicast Routing Overview January 2008
There have been proposals to observe and possibly react ("snoop") PIM
messages [PIM-SNOOP].
2.7.2. Host/Router Flooding Reduction
There are a number of techniques to help reduce flooding both from a
router to hosts, and from a host to the routers (and other hosts).
Cisco's proprietary CGMP [CGMP] provides a solution where the routers
notify the switches, but also allows the switches to snoop IGMP
packets to enable faster notification of hosts no longer wishing to
receive a group. Implementations of CGMP do not support fast leave
behaviour with IGMPv3. Due to IGMP report suppression in IGMPv1 and
IGMPv2, multicast is still flooded to ports which were once members
of a group as long as there is at least one receiver on the link.
Flooding restrictions are done based on multicast MAC addresses.
Implementations of CGMP do not support IPv6.
IEEE 802.1D-2004 specification describes Generic Attribute
Registration Protocol (GARP), and GARP Multicast Registration
Protocol (GMRP) [GMRP] is a link-layer multicast group application of
GARP that notifies switches about MAC multicast group memberships.
If GMRP is used in conjunction with IP multicast, then the GMRP
registration function would become associated with an IGMP "join".
However, this GMRP-IGMP association is beyond the scope of GMRP.
GMRP requires support at the host stack and it has not been widely
implemented. Further, IEEE 802.1 considers GARP and GMRP obsolete
being replaced by Multiple Registration Protocol (MRP) and Multicast
Multiple Registration Protocol (MMRP) that are being specified in
IEEE 802.1ak [802.1ak]. MMRP is expected to be mainly used between
bridges. Some further information about GARP/GMRP is also available
in Appendix B of [RFC3488].
IGMP snooping [RFC4541] appears to be the most widely implemented
technique. IGMP snooping requires that the switches implement a
significant amount of IP-level packet inspection; this appears to be
something that is difficult to get right, and often the upgrades are
also a challenge. Snooping support is commonplace for IGMPv1 and
IGMPv2, but fewer switches support IGMPv3 or MLD (any version)
snooping. In the worst case, enabling IGMP snooping on a switch that
does not support IGMPv3 snooping breaks multicast capabilities of
nodes using IGMPv3.
Snooping switches also need to identify the ports where routers
reside and therefore where to flood the packets. This can be
accomplished using Multicast Router Discovery protocol [RFC4286],
looking at certain IGMP queries [RFC4541], looking at PIM Hello and
possibly other messages, or by manual configuration. An issue with
Savola Informational [Page 17]
^L
RFC 5110 Multicast Routing Overview January 2008
PIM snooping at LANs is that PIM messages can't be turned off or
encrypted, leading to security issues [PIM-THREATS].
IGMP proxying [RFC4605] is sometimes used either as a replacement of
a multicast routing protocol on a small router, or to aggregate IGMP/
MLD reports when used with IGMP snooping.
2.7.3. Summary
The following table summarizes the techniques for multicast flooding
reduction inside a single link for router-to-router and last-hop
LANs.
+--------+-----+----------------------------+
| R-to-R | LAN | Notes |
+-----------------------+--------+-----+----------------------------+
| Cisco's RGMP | Yes | No | Replaced by PIM snooping |
| PIM snooping | Yes | No | Security issues in LANs |
| IGMP/MLD snooping | No | Yes | Common, IGMPv3 or MLD rare |
| Multicast Router Disc | No | Yes | Few if any implem. yet |
| IEEE GMRP and MMRP | No | No | No host/router deployment |
| Cisco's CGMP | No | Yes | Replaced by other snooping |
+-----------------------+--------+-----+----------------------------+
3. Acknowledgements
Tutoring a couple multicast-related papers, the latest by Kaarle
Ritvanen [RITVANEN] convinced the author that up-to-date multicast
routing and address assignment/allocation documentation is necessary.
Leonard Giuliano, James Lingard, Jean-Jacques Pansiot, Dave Meyer,
Stig Venaas, Tom Pusateri, Marshall Eubanks, Dino Farinacci, Bharat
Joshi, Albert Manfredi, Jean-Jacques Pansiot, Spencer Dawkins, Sharon
Chisholm, John Zwiebel, Dan Romascanu, Thomas Morin, Ron Bonica,
Prashant Jhingran, and Tim Polk provided good comments, helping in
improving this document.
4. IANA Considerations
IANA has updated the following registries by adding a reference to
this document:
o OSPFv2 Options Registry: MC-bit
o OSPFv2 Link State (LS) Type: Group-membership-LSA
o OSPFv2 Router Properties Registry: W-bit
Savola Informational [Page 18]
^L
RFC 5110 Multicast Routing Overview January 2008
o OSPFv3 Options Registry: MC-bit
o OSPFv3 LSA Function Code Registry: Group-membership-LSA
o OSPFv3 Prefix Options Registry: MC-bit
5. Security Considerations
This memo only describes different approaches to multicast routing,
and this has no security considerations; the security analysis of the
mentioned protocols is out of scope of this memo.
However, there has been analysis of the security of multicast routing
infrastructures [RFC4609], IGMP/MLD [MLD-SEC], and PIM last-hop
issues [PIM-THREATS].
6. References
6.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and
A. Thyagarajan, "Internet Group Management Protocol,
Version 3", RFC 3376, October 2002.
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery
Protocol (MSDP)", RFC 3618, October 2003.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address",
RFC 3956, November 2004.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I.
Kouvelas, "Protocol Independent Multicast - Sparse
Mode (PIM-SM): Protocol Specification (Revised)",
RFC 4601, August 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast
for IP", RFC 4607, August 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
January 2007.
Savola Informational [Page 19]
^L
RFC 5110 Multicast Routing Overview January 2008
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and
P. Pillay-Esnault, "Multi-Topology (MT) Routing in
OSPF", RFC 4915, June 2007.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L.
Vicisano, "Bidirectional Protocol Independent
Multicast (BIDIR-PIM)", RFC 5015, October 2007.
6.2. Informative References
[802.1ak] "IEEE 802.1ak - Multiple Registration Protocol",
<http://www.ieee802.org/1/pages/802.1ak.html>.
[ADDRARCH] Savola, P., "Overview of the Internet Multicast
Addressing Architecture", Work in Progress,
October 2006.
[CGMP] "Cisco Group Management Protocol",
<http://www.javvin.com/protocolCGMP.html>.
[DVMRPv3] Pusateri, T., "Distance Vector Multicast Routing
Protocol", Work in Progress, December 2003.
[DVMRPv3-AS] Pusateri, T., "Distance Vector Multicast Routing
Protocol Applicability Statement", Work in Progress,
May 2004.
[DYNSSM-REQ] Lehtonen, R., Venaas, S., and M. Hoerdt,
"Requirements for discovery of dynamic SSM sources",
Work in Progress, February 2005.
[GMRP] "GARP Multicast Registration Protocol",
<http://www.javvin.com/protocolGMRP.html>.
[IM-GAPS] Meyer, D. and B. Nickless, "Internet Multicast Gap
Analysis from the MBONED Working Group for the IESG
[Expired]", Work in Progress, July 2002.
[IMRP-ISSUES] Meyer, D., "Some Issues for an Inter-domain Multicast
Routing Protocol", Work in Progress, November 1997.
[M-ISIS] Przygienda, T., "M-ISIS: Multi Topology (MT) Routing
in IS-IS", Work in Progress, November 2007.
[MCAST-ISSUES] Savola, P., "IPv6 Multicast Deployment Issues", Work
in Progress, February 2005.
Savola Informational [Page 20]
^L
RFC 5110 Multicast Routing Overview January 2008
[MLD-SEC] Daley, G. and G. Kurup, "Trust Models and Security in
Multicast Listener Discovery", Work in Progress,
July 2004.
[PIM-SNOOP] Hemige, V., "PIM Snooping over VPLS", Work
in Progress, March 2007.
[PIM-THREATS] Savola, P. and J. Lingard, "Host Threats to Protocol
Independent Multicast (PIM)", Work in Progress,
October 2007.
[RFC1075] Waitzman, D., Partridge, C., and S. Deering,
"Distance Vector Multicast Routing Protocol",
RFC 1075, November 1988.
[RFC1112] Deering, S., "Host extensions for IP multicasting",
STD 5, RFC 1112, August 1989.
[RFC1458] Braudes, B. and S. Zabele, "Requirements for
Multicast Protocols", RFC 1458, May 1993.
[RFC1584] Moy, J., "Multicast Extensions to OSPF", RFC 1584,
March 1994.
[RFC2189] Ballardie, T., "Core Based Trees (CBT version 2)
Multicast Routing -- Protocol Specification --",
RFC 2189, September 1997.
[RFC2201] Ballardie, T., "Core Based Trees (CBT) Multicast
Routing Architecture", RFC 2201, September 1997.
[RFC2715] Thaler, D., "Interoperability Rules for Multicast
Routing Protocols", RFC 2715, October 1999.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)",
RFC 2784, March 2000.
[RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci,
D., Lin, S., Leshchiner, D., Luby, M., Montgomery,
T., Rizzo, L., Tweedly, A., Bhaskar, N., Edmonstone,
R., Sumanasekera, R., and L. Vicisano, "PGM Reliable
Transport Protocol Specification", RFC 3208,
December 2001.
Savola Informational [Page 21]
^L
RFC 5110 Multicast Routing Overview January 2008
[RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci,
"Anycast Rendevous Point (RP) mechanism using
Protocol Independent Multicast (PIM) and Multicast
Source Discovery Protocol (MSDP)", RFC 3446,
January 2003.
[RFC3488] Wu, I. and T. Eckert, "Cisco Systems Router-port
Group Management Protocol (RGMP)", RFC 3488,
February 2003.
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group
Security Architecture", RFC 3740, March 2004.
[RFC3913] Thaler, D., "Border Gateway Multicast Protocol
(BGMP): Protocol Specification", RFC 3913,
September 2004.
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol
Independent Multicast - Dense Mode (PIM-DM): Protocol
Specification (Revised)", RFC 3973, January 2005.
[RFC4286] Haberman, B. and J. Martin, "Multicast Router
Discovery", RFC 4286, December 2005.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management
Protocol (IGMP) and Multicast Listener Discovery
(MLD) Snooping Switches", RFC 4541, May 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP:
Session Description Protocol", RFC 4566, July 2006.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) /
Multicast Listener Discovery (MLD)-Based Multicast
Forwarding ("IGMP/MLD Proxying")", RFC 4605,
August 2006.
[RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol
Independent Multicast - Sparse Mode (PIM-SM)
Multicast Routing Security Issues and Enhancements",
RFC 4609, October 2006.
[RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol
Independent Multicast (PIM)", RFC 4610, August 2006.
Savola Informational [Page 22]
^L
RFC 5110 Multicast Routing Overview January 2008
[RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas,
"Bootstrap Router (BSR) Mechanism for Protocol
Independent Multicast (PIM)", RFC 5059, January 2008.
[RITVANEN] Ritvanen, K., "Multicast Routing and Addressing", HUT
Report, Seminar on Internetworking, May 2004,
<http://www.tml.hut.fi/Studies/T-110.551/2004/
papers/>.
Savola Informational [Page 23]
^L
RFC 5110 Multicast Routing Overview January 2008
Appendix A. Multicast Payload Transport Extensions
A couple of mechanisms have been specified to improve the
characteristics of the data that can be transported over multicast.
We describe those mechanisms that have impact on the multicast
routing infrastructure, e.g., require or specify router assistance or
involvement in some form. Purely end-to-end or host-based protocols
are out of scope.
A.1. Reliable Multicast
There has been some work on reliable multicast delivery so that
applications with reliability requirements could use multicast
instead of simple unreliable UDP.
Most of the mechanisms are host-based and as such out of scope of
this document, but one relevant from multicast routing perspective is
Pragmatic Generic Multicast (PGM) [RFC3208]. It does not require
support from the routers, bur PGM-aware routers may act in router
assistance role in the initial delivery and potential retransmission
of missing data.
A.2. Multicast Group Security
Multicast Security Working Group has been working on methods how the
integrity, confidentiality, and authentication of data sent to
multicast groups can be ensured using cryptographic techniques
[RFC3740].
Author's Address
Pekka Savola
CSC - Scientific Computing Ltd.
Espoo
Finland
EMail: psavola@funet.fi
Savola Informational [Page 24]
^L
RFC 5110 Multicast Routing Overview January 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Savola Informational [Page 25]
^L
|