-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-ietf-mboned-deprecate-interdomain-asm-02.xml
829 lines (722 loc) · 35.7 KB
/
draft-ietf-mboned-deprecate-interdomain-asm-02.xml
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
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1112 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1112.xml">
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2375 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2375.xml">
<!ENTITY RFC2730 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2730.xml">
<!ENTITY RFC2776 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2776.xml">
<!ENTITY RFC2909 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2909.xml">
<!ENTITY RFC3170 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3170.xml">
<!ENTITY RFC3307 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3307.xml">
<!ENTITY RFC3376 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3376.xml">
<!ENTITY RFC3569 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3569.xml">
<!ENTITY RFC3618 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3618.xml">
<!ENTITY RFC3810 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3810.xml">
<!ENTITY RFC3913 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3913.xml">
<!ENTITY RFC3956 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3956.xml">
<!ENTITY RFC3973 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3973.xml">
<!ENTITY RFC4291 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml">
<!ENTITY RFC4541 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4541.xml">
<!ENTITY RFC4604 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4604.xml">
<!ENTITY RFC4607 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4607.xml">
<!ENTITY RFC4609 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4609.xml">
<!ENTITY RFC4610 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4610.xml">
<!ENTITY RFC4611 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4611.xml">
<!ENTITY RFC5015 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5015.xml">
<!ENTITY RFC5771 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5771.xml">
<!ENTITY RFC6763 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6763.xml">
<!ENTITY RFC7761 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7761.xml">
<!ENTITY RFC8085 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml">
<!ENTITY RFC8313 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8313.xml">
<!ENTITY I-D.ietf-6man-rfc6434-bis SYSTEM
"http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6man-rfc6434-bis.xml">
]>
<!-- Use with the following tips & tools:
http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html
http://xml.resource.org/authoring/README.html OR
http://xml.resource.org/authoring/README-dev.html
http://xml.resource.org/ OR
http://xml.resource.org/experimental.html
http://fenron.net/~fenner/ietf/xml2rfc-valid/ link appears to be broken :(
http://tools.ietf.org/tools/idnits/
http://tools.ietf.org/rfcdiff
-->
<!-- Then upload:
https://datatracker.ietf.org/idst/upload.cgi
-->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.35) -->
<!-- give errors regarding ID-nits and DTD validation -->
<?rfc strict="yes"?>
<!-- control the table of contents (ToC) -->
<!-- generate a ToC -->
<?rfc toc="yes"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<?rfc tocdepth="3"?>
<!-- control references -->
<!-- use anchors instead of numbers for refs, i.e, [RFC2119] instead of [1] -->
<?rfc symrefs="yes"?>
<!-- sort the reference entries alphabetically -->
<?rfc sortrefs="no" ?>
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<!-- do not start each main section on a new page -->
<?rfc compact="yes" ?>
<!-- "no" to keep one blank line between list items (rfced) -->
<?rfc subcompact="no" ?>
<!-- encourage use of "xml2rfc" tool -->
<?rfc rfcprocack="yes" ?>
<!-- end of list of popular I-D processing instructions -->
<rfc category="bcp" ipr="trust200902" docName="draft-ietf-mboned-deprecate-interdomain-asm-02">
<front>
<title abbrev="Deprecating Interdomain ASM">Deprecating ASM for Interdomain Multicast</title>
<author fullname="Mikael Abrahamsson" initials="M." surname="Abrahamsson">
<organization> T-Systems </organization>
<address>
<postal>
<street> </street>
<city> Stockholm </city>
<country> Sweden </country>
</postal>
<email> mikael.abrahamsson@t-systems.se </email>
</address>
</author>
<author fullname="Tim Chown" initials="T." surname="Chown">
<organization> Jisc </organization>
<address>
<postal>
<street> Lumen House, Library Avenue </street>
<city> Harwell Oxford, Didcot</city>
<code> OX11 0SG </code>
<country> United Kingdom </country>
</postal>
<email> tim.chown@jisc.ac.uk </email>
</address>
</author>
<author fullname="Lenny Giuliano" initials="L." surname="Giuliano">
<organization> Juniper Networks, Inc. </organization>
<address>
<postal>
<street> 2251 Corporate Park Drive </street>
<city> Herndon, Virginia</city>
<code> 20171 </code>
<country> United States </country>
</postal>
<email> lenny@juniper.net </email>
</address>
</author>
<author fullname="Toerless Eckert" initials="T.T.E." surname="Eckert">
<organization abbrev="Huawei">Futurewei Technologies Inc.</organization>
<address>
<postal>
<street>2330 Central Expy</street>
<city>Santa Clara</city>
<code>95050</code>
<country>USA</country>
</postal>
<email>tte+ietf@cs.fau.de</email>
</address>
</author>
<date month="October" year="2018"/>
<area> Operations </area>
<workgroup> Mboned </workgroup>
<abstract>
<t>
This document recommends deprecation of the use of
Any-Source Multicast (ASM) for interdomain multicast.
It recommends the use of Source-Specific Multicast (SSM) for
interdomain multicast applications and that hosts and routers
in these deployments fully support SSM. The recommendations
in this document do not preclude the continued use of ASM
within a single organisation or domain and are especially easy to adopt in
existing intradomain ASM/PIM-SM deployments.
</t>
</abstract>
<note title="Requirements Language and Terminology">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in "Key words for use in
RFCs to Indicate Requirement Levels" <xref target="RFC2119" />.
</t>
<t>The term IP and IP multicast are used to refer to both IPv4 and IPv6.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>
IP Multicast has been deployed in various forms, within
private networks, the wider Internet, and federated networks
such as national or regional research networks.
While a number of service models have been published, and in many cases
revised over time, there has been no strong recommendation
made by the IETF on the appropriateness of those models to certain scenarios,
even though vendors and federations have often made such recommendations.
</t>
<t>
This document addresses this gap by making a BCP-level
recommendation to deprecate the use of ASM for interdomain
multicast, leaving SSM as the recommended interdomain mode of
multicast. This recommendation thus also implicitly states that
all hosts and routers that are expected to support interdomain
multicast applications fully support SSM.
</t>
<t>
This document does not make any statement on the use of ASM
within a single domain or organisation, and therefore
does not preclude its use.
Indeed, there are application contexts for which ASM is currently still
widely considered well-suited within a single domain.
</t>
<t>
The main issue in most cases with moving to SSM is application support.
Many applications are initially deployed for intradomain use and are later
deployed interdomain. Therefore, this document recommends
applications support SSM, even when they are initially intended for
intradomain use. As explained below, SSM applications are
readily compatible with existing intradomain ASM deployments as SSM
is merely a subset of ASM.
</t>
</section>
<section title="Background">
<section title="Multicast service models">
<t>
Any-Source Multicast (ASM) and Source-Specific Multicast (SSM)
are the two multicast service models in use today. In ASM, as originally
described in <xref target="RFC1112"/>, receivers express interest
in joining a multicast group address and routers use multicast
routing protocols to deliver traffic from
the sender(s) to the receivers. If there are multiple senders
for a given group, traffic from all senders will be delivered
to the receiver. Since receivers specify only the group address,
the network, and therefore the multicast routing protocols, are
responsible for source discovery.
</t>
<t>
In SSM, by contrast, receivers specify both group and source when
expressing interest in joining a multicast stream. Source discovery
in SSM is handled by some out-of-band mechanism (ie, the application
layer), which drastically simplifies the network and how the multicast
routing protocols operate.
</t>
<t>
IANA has reserved specific ranges of IPv4 and IPv6 address
space for multicast addressing.
Guidelines for IPv4 multicast address assignments
can be found in <xref target="RFC5771"/>, while
guidelines for IPv6 multicast address assignments
can be found in <xref target="RFC2375"/> and
<xref target="RFC3307"/>.
The IPv6 multicast address format is described
in <xref target="RFC4291"/>.
</t>
</section>
<section title="ASM routing protocols">
<section title="PIM Sparse Mode (PIM-SM)">
<t>
The most commonly deployed ASM routing protocol is Protocol Independent
Multicast - Sparse Mode (PIM-SM), as
detailed in <xref target="RFC7761"/>.
PIM-SM, as the name suggests, was designed to be used in scenarios
where the subnets with receivers are sparsely distributed throughout
the network.
Because receivers do not indicate sender addresses in ASM (but only group addresses),
PIM-SM uses the concept of a Rendezvous Point (RP) as a ‘meeting point’
for sources and receivers, and all routers in a PIM-SM domain are
configured to use specific RP(s), either explicitly or through
dynamic RP discovery protocols.
</t>
<t>
To enable PIM-SM to work between multiple
domains, an interdomain, inter-RP signalling protocol known
as Multicast Source Discovery Protocol (MSDP)
<xref target="RFC3618"/> is used to allow an RP in one
domain to learn the existence of a source in another domain.
Deployment scenarios for MSDP are given in <xref target="RFC4611"/>.
MSDP floods information
about all active sources for all multicast streams to all RPs in all
the domains - even if there is no receiver for a given application in a domain.
As a result of this key scalability and security issue, along with
other deployment challenges with the protocol,
MSDP was never extended to support IPv6 and remains an Experimental protocol.
</t>
<t>To this day, there is no IETF Proposed Standard level interdomain solution for
IPv4 ASM multicast because MSDP was the "best" component for the interdomain
source discovery problem, and it is Experimental. Other protocol options
where investigated at the same time but were never implemented or deployed
and are now historic (e.g: <xref target="RFC3913"/>).
</t>
</section>
<section title="Embedded-RP">
<t>Due to the availability of more bits in an IPv6 address than in IPv4,
an IPv6-specific mechanism was designed in support of interdomain
ASM with PIM-SM leveraging those bits.
Embedded-RP <xref target="RFC3956"/> allows routers supporting the protocol
to determine the RP for the group without any
prior configuration or discovery protocols, simply by observing the unicast RP
address that is embedded (included) in the IPv6 multicast group address.
Embedded-RP allows PIM-SM operation across any IPv6 network
in which there is an end-to-end path of routers
supporting this mechanism, including interdomain deployment.
</t>
</section>
<section title="Bidir-RP">
<t>Bidir-PIM <xref target="RFC5015"/> is another protocol to support ASM.
There is no standardized option to operate Bidir-PIM interdomain. It is
deployed intradomain for applications where many sources may want to sent
traffic to the same IP multicast groups because unlike PIM-SM it does not
create per-source state. Bidir-PIM is one of the important reasons for this
document to not deprecate intradomain ASM.</t>
</section>
</section>
<section title="SSM Routing protocols">
<t>
SSM is detailed in <xref target="RFC4607"/>. It mandates the use of
PIM-SSM for routing of SSM. PIM-SSM as it merely a subset of PIM-SM (<xref target="RFC7761"/>).
</t>
<t>
PIM-SSM expects that the sender’s source address(es)
is known in advance by receivers through some out-of-band mechanism (typically
in the application layer), and thus the
receiver's designated router can send a PIM JOIN directly towards the
source without needing to use an RP.
</t>
<t>
IPv4 addresses in the 232/8 (232.0.0.0 to
232.255.255.255) range are designated as source-specific multicast
(SSM) destination addresses and are reserved for use by
source-specific applications and protocols. See <xref target="RFC4607"/>.
For IPv6, the address prefix
FF3x::/32 is reserved for source-specific multicast use.
</t>
</section>
</section>
<section title="Discussion">
<section title="Observations on ASM and SSM deployments">
<t>
In enterprise and campus scenarios, ASM in the form of PIM-SM is
likely the most commonly deployed
multicast protocol. The configuration and
management of an RP (including RP redundancy) within a single
domain is a well understood operational practice. However, if interworking
with external PIM domains is needed in IPv4 multicast deployments,
interdomain MSDP is required to
exchange information about sources between domain RPs. Deployment experience
has shown MSDP to be a complex and fragile protocol
to manage and troubleshoot (complex flooding RPF rules, state attack
protection, filtering of undesired sources, ...).
</t>
<t>
PIM-SM is a general purpose protocol that can handle all
use cases. In particular, it was designed for cases such as
videoconferencing where multiple sources may come and go
during a multicast
session. But for cases where a single, persistent source for a group
is used, and receivers can be configured to know of that source,
PIM-SM has unnecessary complexity. Therefore, SSM eliminates the most
components of PIM-SM.
</t>
<t>
As explained above, MSDP was not extended to support IPv6. Instead,
the proposed interdomain ASM solution for PIM-SM with IPv6
is Embedded-RP, which allows the RP address
for a multicast group to be embedded in the group address,
making RP discovery automatic for all routers on the path
between a receiver and a sender.
Embedded-RP can support lightweight ad-hoc deployments.
However, it relies
on a single RP for an entire group that could only be made resilient
within one domain. While this approach solves the MSDP issues, it does
not solve the problem of unauthorised sources sending traffic to ASM
multicast groups; this security issues
is one of biggest problem of interdomain multicast.
</t>
<t>
As stated in RFC 4607, SSM is particularly well-suited to
dissemination-style applications with one or more senders
whose identities are known (by some oob mechanism) before the
application starts running or applications that utilize some
signaling to indicate the source address of the
multicast stream (eg, electronic programming guide
in IPTV applications).
PIM-SSM is therefore very well-suited
to applications such as classic linear broadcast TV over IP.
</t>
<t>
SSM requires applications, host operating systems and the
designated routers connected to receiving hosts
to support IGMPv3 <xref target="RFC3376"/> and
MLDv2 <xref target="RFC3810"/>. Support for
IGMPv3 and MLDv2 has become widespread in common OSes for
several years (Windows, MacOS,
Linux/Android) and is no longer an impediment to SSM deployment.
</t>
</section>
<section title="Advantages of SSM for interdomain multicast" anchor="advantages" >
<t>This section describes the three key area of benefits that SSM
with PIM-SSM has over ASM. These benefits also apply
to intradomain deployment but are even more important in
interdomain deployments. See <xref target="RFC4607"/> for
more details.</t>
<section title="Reduced network operations complexity">
<t>
A significant benefit of SSM is the reduced complexity that comes through
eliminating the network-based source discovery required in ASM with PIM-SM.
Specifically, SSM eliminates the need for RPs,
shared trees, Shortest Path Tree (SPT) switchovers, PIM registers,
MSDP, dynamic RP discovery mechanisms (BSR/AutoRP) and data-driven
state creation. SSM simply utilizes a small
subset of PIM-SM, alongside the integration with IGMPv3 / MLDv2, where the
source address signaled from the receiver is immediately used to
create (S,G) state.
Eliminating network-based source discovery for interdomain
multicast means the vast majority of the complexity of multicast goes away.
</t>
<t>
This reduced complexity makes SSM radically simpler to manage,
troubleshoot and operate, particularly for backbone network
operators. This is the main operator motivation for the recommendation
to deprecate the use of ASM in interdomain scenarios.
</t>
<t>Note that this discussion does not apply to Bidir-PIM, and there is
(as mentioned above) no standardized interdomain solution for Bidir-PIM.
In Bidir-PIM, traffic is forwarded to an RPs instead o building state as in
PIM-SM. Even in the absence of receivers. Bidir-PIM therefore trades
state complexity with (potentially large amounts) of unnecessary traffic.</t>
</section>
<section title="No network wide IP multicast group-address management">
<t>
In ASM, IP multicast group addresses need to be assigned to applications
and instances thereof, so that two simultaneously active application instances
will not share the same group address and receive each others IP multicast traffic.
</t>
<t>
Protocols to automate ASM IP multicast group allocations to application instances
where defined in the 1990'ths, but never widely deployed: MADCAP <xref target="RFC2730"/>,
MASC <xref target="RFC2909"/> and MZAP <xref target="RFC2776"/>. Today, all
ASM IP multicast group allocation are based on per-operator, non-standardized
and mostly manual assignment practices which adds to the operational overhead of supporting ASM.
</t>
<t>
In SSM, no such IP multicast group management is necessary. Instead, the IP multicast
group address simply needs to be assigned locally on a source like a unicast transport
protocol port number: No two independent applications on the host must use same IP
multicast group number. This does not require any network operator involvement.
</t>
</section>
<section anchor="source-security" title="Intrinsic source-control security">
<t>
SSM is implicitly secure against unauthorized/undesired sources.
Receivers only receive packets from the sources they explicitly specify
in their IGMP/MLD membreship messages, as opposed to ASM where any host
can send traffic to a group address and have it transmitted to all receivers.
With PIM-SSM, traffic from sources not requested by any receiver will
be discarded by the first-hop router (FHR) of that source, minimizing source
attacks against shared network bandwidth and receivers.
</t>
<t>
This benefit is particularily important in interdomain deployments because
there are no standardized solutions for ASM control of sources and the most
common intradomain operational practices such as Access Control Lists
(ACL) on senders FHR are not feasible for interdomain deployments.
</t>
<t>
This topic is expanded upon in <xref target="RFC4609"/>.
</t>
</section>
</section>
</section>
<section anchor="recommendations" title="Recommendations">
<section title="Deprecating use of ASM for interdomain multicast">
<t>
This document recommends that the use of ASM is deprecated
for interdomain multicast, and thus implicitly, that hosts and
routers that support such interdomain applications
fully support SSM and its associated protocols.
Best current practices for deploying interdomain multicast using SSM
are documented in <xref target="RFC8313"/>.
</t>
<t>
The recommendation applies to the use of ASM between domains where
either MSDP (IPv4) or Embedded-RP (IPv6) is used.
</t>
<t>
An interdomain use of ASM multicast in the context of this document
is one where PIM-SM with RPs/MSDP/Embedded-RP
is run on routers operated by two or more separate administrative entities
(domains, organisations).
</t>
<t>
The more inclusive interpretation of this recommendation is that it also
extends to the case where PIM may only be operated in a single operator
domain, but where user hosts or non-PIM network edge devices are under
different operator control. A typical example of this case is an SP providing
IPTV (single operator domain for PIM) to subscribers operating an
IGMP proxy home gateway and IGMPv3/MLDv2 hosts (computer, tablets, set-top boxes).
</t>
</section>
<section title="Including network support for IGMPv3 / MLDv2">
<t>
This document recommends that all hosts, router platforms and
security appliances supporting multicast
support IGMPv3 <xref target="RFC3376"/> and MLDv2 <xref target="RFC3810"/>
(based on the version IP they intend to support).
The updated IPv6 Node Requirements RFC <xref target="I-D.ietf-6man-rfc6434-bis"/>
states that MLDv2 support is a MUST in all implementations.
Such support is already widespread in common host and router platforms.
</t>
<t>
Further guidance on IGMPv3 and MLDv2 is given in
<xref target="RFC4604"/>.
</t>
<t>
Multicast snooping is often used limit the flooding of multicast traffic
in a layer 2 network. With snooping, a L2 switch will monitor IGMP/MLD
messages and only forward multicast traffic out host ports that have
interested receivers connected.
Such snooping capability should therefore support IGMPv3 and MLDv2.
There is further discussion in <xref target="RFC4541"/>.
</t>
</section>
<section title="Building application support for SSM">
<t>
The recommendation to use SSM for interdomain multicast means that
applications should properly trigger the sending of IGMPv3/MLDv2 messages.
It should be noted, however, there is a wide range of applications today
that only support ASM. In many cases this is due to application developers
being unaware of the operational concerns of networks. This document serves to
provide clear direction for application developers to support SSM.
</t>
<t>
It is often thought that ASM is required for multicast applications
where there are multiple sources. However,
RFC 4607 also describes how SSM can be used instead of PIM-SM
for multi-party applications:
</t>
<t>
<list style="empty">
<t>"SSM can be used to
build multi-source applications where all participants' identities
are not known in advance, but the multi-source "rendezvous"
functionality does not occur in the network layer in this case. Just
like in an application that uses unicast as the underlying transport,
this functionality can be implemented by the application or by an
application-layer library."
</t>
</list>
</t>
<t>
Some useful considerations for multicast applications can be found
in <xref target="RFC3170"/>.
</t>
</section>
<section anchor="guidance" title="Developing application guidance: SSM, ASM, service discovery">
<t>
Applications with many-to-many communication patterns can create more
(S,G) state than feasible for networks, whether the source discovery is
done by ASM with PIM-SM or at the application level and SSM/PIM-SM.
These applications are not best supported by neithre SSM/PIM-SSM nor ASM/PIM-SM.
</t>
<t>
Instead, these applications are better served by routing protocols that do
not create (S,G) such as Bidir-PIM. As of today, Unfortunately, many applications
simply use ASM for service discovery, for example by clients sending IP multicast
packets to elicit unicast replies from server(s). Deploying any form of IP
multicast solely in support of such service discovery is in general not recommended
(complexity, control, ...) but instead dedicated service discovery via DNS <xref target="RFC6763"/>
</t>
<t>Best practices should be developed to explain when to use SSM in application,
when ASM without (S,G) state in the network is better, or when dedicated
service-discovery mechanisms should be used.
</t>
</section>
<section title="Preferring SSM applications intradomain">
<t>
If feasible, it is recommended for applications to use SSM even if they
are initially only meant to be used in intradomain environments supporting ASM.
Because PIM-SSM is a subset of PIM-SM, existing intradomain PIM-SM networks
are automatically compatible with SSM applications. Thus, SSM applications
can operate alongside existing ASM applications.
SSM's benefits of simplified address management and significantly reduced
operational complexity apply equally to intradomain use.
</t>
<t>However, for some applications it may be prohibitively difficult to
add support for source discovery, so intradomain ASM may still be appropriate.
</t>
</section>
<section title="Documenting an ASM/SSM protocol mapping mechanism">
<t>
In the case of existing ASM applications that cannot readily be ported to SSM,
it may be possible to use some form of protocol mapping, i.e., to have a
mechanism to translate a (*,G) join or leave to a (S,G) join or leave, for
a specific source, S. The general challenge in performing such mapping is
determining where the configured source address, S, comes from.
</t>
<t>
There are existing vendor-specific mechanisms deployed that achieve this function,
but none are documented in IETF documents. This may be a useful
area for the IETF to work on as an interim
transition mechanism. However, these mechanisms would introduce additional
administrative burdens, along with the need for some form of address management,
neither of which are required in SSM. Hence, this should not be considered a
a long-term solution.
</t>
</section>
<section title="Not filtering ASM addressing between domains">
<t>
A key benefit of SSM is that the receiver specifies the source-group tuple
when signaling interest in a multicast stream. Hence, the group address need
not be globally unique, so there is no need for multicast address allocation
as long the reserved SSM range is used.
</t>
<t>
Despite the deprecation of interdomain ASM, it is recommended that operators
should not filter ASM group ranges at domain boundaries, as some form of
ASM-SSM mappings may continue to be used for some time.
</t>
</section>
<section anchor="precluding" title="Not precluding Intradomain ASM">
<t>
The use of ASM within a single multicast domain such as a campus or
enterprise is still relatively common today. There are even global
enterprise networks that have successfully been using
PIM-SM for many years. The operators of such networks most often
use Anycast-RP <xref target="RFC4610"/> or MSDP (with IPv4) for RP
resilience, at the expense of the extra operational complexity.
These existing practices are unaffected by this document.
</t>
<t>In the past decade, Bidir-PIM too has seen deployments to scale
interdomain ASM deployments beyond the capabilities of PIM-SM. This too
is unaffected by this document, instead it is encouraged where
necessary due to application requirements (see <xref target="guidance"/>.</t>
<t>
This document does also not preclude continued use of ASM with multiple
PIM-SM domains inside organisations, such as with IPv4 MSDP or IPv6 Embedded-RP.
This includes organizations that are federations and have appropriate, non-standardized
mechanisms to deal with the interdomain ASM issues explained in <xref target="advantages"/>.
</t>
</section>
<section title="Evolving PIM deployments for SSM">
<t>
Existing PIM-SM deployments can usually be used to run SSM/PIM-SM applications
with no or little changes. In some widely available router implentations of PIM-SM,
PIM-SSM is simply enabled by default in the designated SSM address spaces whener
PIM-SM is configuring/enabled. In other implementations, simple configuration options
exist to enable it. This allows to easily migrate ASM applications to SSM/PIM-SSM
solely through application side development/configuration work: adding above mentioned
source-signaling via IGMPv3/MLDv2 and using SSM addresses. No network actions are
required for this transitioning: Unchanged ASM applications can continue to co-exist
without issues.
</t>
<t>When running PIM-SM, IGMPv3/MLDv2 (S,G) membership reports may also result in
the desired PIM-SSM (S,G) operations and bypass any RP procedures, but this is not
standardized but depends on implementation and may require additional configuration
in available products. In general, it is recommended to always use SSM address space
for SSM applications. For example, the interaction of IGMPv3/MLDv2 (S,G) membership
reports and Bidir-PIM is undefined and may not result in forwarding of any traffic.
</t>
<t>
Note that this migration recommendations do not include the considerations when
or how to evolve those intradomain applications best served by ASM/Bidir-PIM from PIM-SM
to Bidir-PIM. This may also be important but is outside the scope of this document.
</t>
</section>
</section>
<section title="Future interdomain ASM work">
<t>
Future work may attempt to overcome current limitations of ASM solutions,
such as interdomain deployment solutions for Bidir-PIM, or source access control
mechaisms for IPv6 PIM-SM with embedded-RP. Such work could modify or amend the
recommendations of this document (like any future IETF standards/BCP work).
</t>
<t>
Nevertheless, this document does not believe that any ASM solution, even with
such future work, can ever provide the same intrinsic security and network and address management
simplicity as SSM (see <xref target="advantages"/>). Instead, this document believes that
future work for general purpose interdomain IP multicast is better spent on the SSM items
listed in <xref target="recommendations"/>.
</t>
</section>
<section title="Security Considerations">
<t>
This document adds no new security considerations. It instead
removes security issues incurred by interdomain ASM with PIM-SM/MSDP such as
infrastructure control plane attacks and application and bandwidth/congestion
attacks from unauthorised sources sending to ASM multicast groups.
RFC 4609 describes the additional security benefits of using
SSM instead of ASM.
</t>
</section>
<section title="IANA Considerations">
<t>This document makes no request of IANA.</t>
<t>Note to RFC Editor: this section may be removed upon publication as an RFC.</t>
</section>
<section title="Acknowledgments">
<t>
The authors would like to thank members of the IETF mboned WG for discussions on the
content of this document, with specific thanks to the following people for their
contributions to the document:
Hitoshi Asaeda,
Dale Carder,
Jake Holland,
Albert Manfredi,
Mike McBride,
Per Nihlen,
Greg Shepherd,
James Stevens,
Stig Venaas,
Nils Warnke,
and
Sandy Zhang.
</t>
</section>
<section title="Changelog">
<t>[RFC-Editor: Please remove this section.]</t>
<t>02 - Toerless: Attempt to document the issues brought up on the list and discussion by James Stevens re. use of Bidir-PIM intradomain and IGMP/MLD interop issues.</t>
<t> - NOTE: Text was not vetted by co-authors, so rev'ed just as discussion basis.</t>
<t> - more subsection to highlight content. Added more detailled discussion about downsides of ASM wrt. address management and intrinsic source-control in SSM. Added recommendation to work on guidance when apps are best suited for SSM vs. ASM/Bidir vs. service discovery. Added recommendation how to evolve from PIM-SM to SSM in existing deployments. Added section on possible future interdomain ASM work (and why not to focus on it).</t>
<t>01 - Lenny: cleanup of text version, removed redundancies.</t>
<t>00 - initial IETF WG version.
See draft-acg-mboned-deprecate-interdomain-asm for work leading to this document.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC1112;
&RFC2119;
&RFC3307;
&RFC3376;
&RFC3810;
&RFC3956;
&RFC4291;
&RFC4607;
&RFC4610;
&RFC5771;
&RFC7761;
</references>
<references title="Informative References">
&RFC2375;
&RFC2730;
&RFC2776;
&RFC2909;
&RFC3170;
&RFC3569;
&RFC3618;
&RFC3913;
&RFC3973;
&RFC4541;
&RFC4604;
&RFC4609;
&RFC4611;
&RFC5015;
&RFC6763;
&RFC8085;
&RFC8313;
&I-D.ietf-6man-rfc6434-bis;
</references>
</back>
</rfc>