draft-ietf-mboned-deprecate-interdomain-asm-01.txt   draft-ietf-mboned-deprecate-interdomain-asm-02.txt 
skipping to change at page 1, line 14 skipping to change at page 1, line 14
Internet-Draft T-Systems Internet-Draft T-Systems
Intended status: Best Current Practice T. Chown Intended status: Best Current Practice T. Chown
Expires: April 25, 2019 Jisc Expires: April 25, 2019 Jisc
L. Giuliano L. Giuliano
Juniper Networks, Inc. Juniper Networks, Inc.
T. Eckert T. Eckert
Huawei Huawei
October 22, 2018 October 22, 2018
Deprecating ASM for Interdomain Multicast Deprecating ASM for Interdomain Multicast
draft-ietf-mboned-deprecate-interdomain-asm-01 draft-ietf-mboned-deprecate-interdomain-asm-02
Abstract Abstract
This document recommends deprecation of the use of Any-Source This document recommends deprecation of the use of Any-Source
Multicast (ASM) for interdomain multicast. It recommends the use of Multicast (ASM) for interdomain multicast. It recommends the use of
Source-Specific Multicast (SSM) for interdomain multicast Source-Specific Multicast (SSM) for interdomain multicast
applications and that hosts and routers in these deployments fully applications and that hosts and routers in these deployments fully
support SSM. The recommendations in this document do not preclude support SSM. The recommendations in this document do not preclude
the continued use of ASM within a single organisation or domain and the continued use of ASM within a single organisation or domain and
are especially easy to adopt in these existing intradomain ASM are especially easy to adopt in existing intradomain ASM/PIM-SM
deployments. deployments.
Requirements Language Requirements Language and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in "Key words for use in document are to be interpreted as described in "Key words for use in
RFCs to Indicate Requirement Levels" [RFC2119]. RFCs to Indicate Requirement Levels" [RFC2119].
The term IP and IP multicast are used to refer to both IPv4 and IPv6.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
skipping to change at page 2, line 22 skipping to change at page 2, line 23
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Multicast routing protocols . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. ASM routing protocols . . . . . . . . . . . . . . . . . . 4 2.1. Multicast service models . . . . . . . . . . . . . . . . 3
2.2. SSM Routing protocols . . . . . . . . . . . . . . . . . . 4 2.2. ASM routing protocols . . . . . . . . . . . . . . . . . . 4
2.2.1. PIM Sparse Mode (PIM-SM) . . . . . . . . . . . . . . 4
2.2.2. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 5
2.2.3. Bidir-RP . . . . . . . . . . . . . . . . . . . . . . 5
2.3. SSM Routing protocols . . . . . . . . . . . . . . . . . . 5
3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Observations on ASM and SSM deployments . . . . . . . . . 5 3.1. Observations on ASM and SSM deployments . . . . . . . . . 5
3.2. Advantages of SSM for interdomain multicast . . . . . . . 6 3.2. Advantages of SSM for interdomain multicast . . . . . . . 6
4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Reduced network operations complexity . . . . . . . . 7
4.1. Deprecating use of ASM for interdomain multicast . . . . 7 3.2.2. No network wide IP multicast group-address management 7
4.2. Including network support for IGMPv3 / MLDv2 . . . . . . 7 3.2.3. Intrinsic source-control security . . . . . . . . . . 8
4.3. Building application support for SSM . . . . . . . . . . 8 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Preferring SSM applications intradomain . . . . . . . . . 8 4.1. Deprecating use of ASM for interdomain multicast . . . . 8
4.5. Documenting an ASM/SSM protocol mapping mechanism . . . . 8 4.2. Including network support for IGMPv3 / MLDv2 . . . . . . 9
4.6. Not filtering ASM addressing between domains . . . . . . 9 4.3. Building application support for SSM . . . . . . . . . . 9
4.7. Not precluding Intradomain ASM . . . . . . . . . . . . . 9 4.4. Developing application guidance: SSM, ASM, service
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 discovery . . . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4.5. Preferring SSM applications intradomain . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 4.6. Documenting an ASM/SSM protocol mapping mechanism . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.7. Not filtering ASM addressing between domains . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 4.8. Not precluding Intradomain ASM . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 11 4.9. Evolving PIM deployments for SSM . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 5. Future interdomain ASM work . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
9. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
IP Multicast has been deployed in various forms, within private IP Multicast has been deployed in various forms, within private
networks, the wider Internet, and federated networks such as national networks, the wider Internet, and federated networks such as national
or regional research networks. While a number of service models have or regional research networks. While a number of service models have
been published, and in many cases revised over time, there has been been published, and in many cases revised over time, there has been
no strong recommendation made by the IETF on the appropriateness of no strong recommendation made by the IETF on the appropriateness of
those models to certain scenarios, even though vendors and those models to certain scenarios, even though vendors and
federations have often made such recommendations. federations have often made such recommendations.
skipping to change at page 3, line 27 skipping to change at page 3, line 40
currently still widely considered well-suited within a single domain. currently still widely considered well-suited within a single domain.
The main issue in most cases with moving to SSM is application The main issue in most cases with moving to SSM is application
support. Many applications are initially deployed for intradomain support. Many applications are initially deployed for intradomain
use and are later deployed interdomain. Therefore, this document use and are later deployed interdomain. Therefore, this document
recommends applications support SSM, even when they are initially recommends applications support SSM, even when they are initially
intended for intradomain use. As explained below, SSM applications intended for intradomain use. As explained below, SSM applications
are readily compatible with existing intradomain ASM deployments as are readily compatible with existing intradomain ASM deployments as
SSM is merely a subset of ASM. SSM is merely a subset of ASM.
2. Multicast routing protocols 2. Background
2.1. Multicast service models
Any-Source Multicast (ASM) and Source-Specific Multicast (SSM) are Any-Source Multicast (ASM) and Source-Specific Multicast (SSM) are
the two multicast service models in use today. In ASM, as originally the two multicast service models in use today. In ASM, as originally
described in [RFC1112], receivers express interest in joining a described in [RFC1112], receivers express interest in joining a
multicast group address and routers use multicast routing protocols multicast group address and routers use multicast routing protocols
to deliver traffic from the sender(s) to the receivers. If there are 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 multiple senders for a given group, traffic from all senders will be
delivered to the receiver. Since receivers specify only the group delivered to the receiver. Since receivers specify only the group
address, the network, and therefore the multicast routing protocols, address, the network, and therefore the multicast routing protocols,
are responsible for source discovery. In SSM, by contrast, receivers are responsible for source discovery.
specify both group and source when expressing interest in joining a
multicast stream. Source discovery in SSM is handled by some out-of- In SSM, by contrast, receivers specify both group and source when
band mechanism (ie, the application layer), which drastically expressing interest in joining a multicast stream. Source discovery
simplifies the network and how the multicast routing protocols in SSM is handled by some out-of-band mechanism (ie, the application
operate. layer), which drastically simplifies the network and how the
multicast routing protocols operate.
IANA has reserved specific ranges of IPv4 and IPv6 address space for IANA has reserved specific ranges of IPv4 and IPv6 address space for
multicast addressing. Guidelines for IPv4 multicast address multicast addressing. Guidelines for IPv4 multicast address
assignments can be found in [RFC5771], while guidelines for IPv6 assignments can be found in [RFC5771], while guidelines for IPv6
multicast address assignments can be found in [RFC2375] and multicast address assignments can be found in [RFC2375] and
[RFC3307]. The IPv6 multicast address format is described in [RFC3307]. The IPv6 multicast address format is described in
[RFC4291]. [RFC4291].
2.1. ASM routing protocols 2.2. ASM routing protocols
2.2.1. PIM Sparse Mode (PIM-SM)
The most commonly deployed ASM routing protocol is Protocol The most commonly deployed ASM routing protocol is Protocol
Independent Multicast - Sparse Mode, or PIM-SM, as detailed in Independent Multicast - Sparse Mode (PIM-SM), as detailed in
[RFC7761]. PIM-SM, as the name suggests, was designed to be used in [RFC7761]. PIM-SM, as the name suggests, was designed to be used in
scenarios where the subnets with receivers are sparsely distributed scenarios where the subnets with receivers are sparsely distributed
throughout the network. Because it does not know sender addresses in throughout the network. Because receivers do not indicate sender
advance, PIM-SM uses the concept of a Rendezvous Point (RP) as a addresses in ASM (but only group addresses), PIM-SM uses the concept
'meeting point' for sources and receivers, and all routers in a PIM- of a Rendezvous Point (RP) as a 'meeting point' for sources and
SM domain are configured to use specific RP(s), either explicitly or receivers, and all routers in a PIM-SM domain are configured to use
through dynamic RP discovery protocols. specific RP(s), either explicitly or through dynamic RP discovery
protocols.
To enable PIM-SM to work between multiple domains, an inter-RP To enable PIM-SM to work between multiple domains, an interdomain,
signalling protocol known as Multicast Source Discovery Protocol inter-RP signalling protocol known as Multicast Source Discovery
(MSDP) [RFC3618] is used to allow an RP in one domain to learn the Protocol (MSDP) [RFC3618] is used to allow an RP in one domain to
existence of a source in another domain. Deployment scenarios for learn the existence of a source in another domain. Deployment
MSDP are given in [RFC4611]. MSDP floods information about all scenarios for MSDP are given in [RFC4611]. MSDP floods information
active sources for all multicast streams to all RPs in all the about all active sources for all multicast streams to all RPs in all
domains - even if there is no receiver for a given application in a the domains - even if there is no receiver for a given application in
domain. As a result of this key scalability and security issue, a domain. As a result of this key scalability and security issue,
along with other deployment challenges with the protocol, MSDP was along with other deployment challenges with the protocol, MSDP was
never extended to support IPv6 and remains an Experimental protocol. never extended to support IPv6 and remains an Experimental protocol.
To this day, there is no IETF Proposed Standard level interdomain To this day, there is no IETF Proposed Standard level interdomain
solution for IPv4 ASM multicast because MSDP was the "best" component solution for IPv4 ASM multicast because MSDP was the "best" component
for the interdomain source discovery problem, and it is Experimental. for the interdomain source discovery problem, and it is Experimental.
Other protocol options where investigated at the same time but were Other protocol options where investigated at the same time but were
never implemented or deployed and are now historic (e.g: [RFC3913]). never implemented or deployed and are now historic (e.g: [RFC3913]).
2.2.2. Embedded-RP
Due to the availability of more bits in an IPv6 address than in IPv4, Due to the availability of more bits in an IPv6 address than in IPv4,
an IPv6-specific mechanism was able to be designed in support of an IPv6-specific mechanism was designed in support of interdomain ASM
interdomain ASM with PIM-SM. Embedded-RP [RFC3956] allows routers with PIM-SM leveraging those bits. Embedded-RP [RFC3956] allows
supporting the protocol to determine the RP for the group without any routers supporting the protocol to determine the RP for the group
prior configuration or discovery protocols, simply by observing the without any prior configuration or discovery protocols, simply by
unicast RP address that is embedded (included) in the IPv6 multicast observing the unicast RP address that is embedded (included) in the
group address. Embedded-RP allows PIM-SM operation across any IPv6 IPv6 multicast group address. Embedded-RP allows PIM-SM operation
network in which there is an end-to-end path of routers supporting across any IPv6 network in which there is an end-to-end path of
the mechanism. routers supporting this mechanism, including interdomain deployment.
2.2. SSM Routing protocols 2.2.3. Bidir-RP
SSM is detailed in [RFC4607]. Note that there is no separate Bidir-PIM [RFC5015] is another protocol to support ASM. There is no
document for PIM-SSM as it merely leverages a subset of [RFC7761]. 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.
2.3. SSM Routing protocols
SSM is detailed in [RFC4607]. It mandates the use of PIM-SSM for
routing of SSM. PIM-SSM as it merely a subset of PIM-SM ([RFC7761]).
PIM-SSM expects that the sender's source address(es) is known in PIM-SSM expects that the sender's source address(es) is known in
advance by receivers by some out-of-band mechanism (typically in the advance by receivers through some out-of-band mechanism (typically in
application layer), and thus the receiver's designated router can the application layer), and thus the receiver's designated router can
send a PIM JOIN directly towards the source without needing to use an send a PIM JOIN directly towards the source without needing to use an
RP. RP.
IPv4 addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are 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 designated as source-specific multicast (SSM) destination addresses
and are reserved for use by source-specific applications and and are reserved for use by source-specific applications and
protocols. See [RFC4607]. For IPv6, the address prefix FF3x::/32 is protocols. See [RFC4607]. For IPv6, the address prefix FF3x::/32 is
reserved for source-specific multicast use. reserved for source-specific multicast use.
3. Discussion 3. Discussion
skipping to change at page 5, line 36 skipping to change at page 6, line 17
filtering of undesired sources, ...). filtering of undesired sources, ...).
PIM-SM is a general purpose protocol that can handle all use cases. PIM-SM is a general purpose protocol that can handle all use cases.
In particular, it was designed for cases such as videoconferencing In particular, it was designed for cases such as videoconferencing
where multiple sources may come and go during a multicast session. where multiple sources may come and go during a multicast session.
But for cases where a single, persistent source for a group is used, 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 and receivers can be configured to know of that source, PIM-SM has
unnecessary complexity. Therefore, SSM eliminates the most unnecessary complexity. Therefore, SSM eliminates the most
components of PIM-SM. components of PIM-SM.
As explained above, MSDP was not extended to support to IPv6. As explained above, MSDP was not extended to support IPv6. Instead,
Instead, the proposed interdomain ASM solution for PIM-SM with IPv6 the proposed interdomain ASM solution for PIM-SM with IPv6 is
is Embedded-RP, which allows the RP address for a multicast group to Embedded-RP, which allows the RP address for a multicast group to be
be embedded in the group address, making RP discovery automatic for embedded in the group address, making RP discovery automatic for all
all routers on the path between a receiver and a sender. Embedded-RP routers on the path between a receiver and a sender. Embedded-RP can
can support lightweight ad-hoc deployments. However, it relies on a support lightweight ad-hoc deployments. However, it relies on a
single RP for an entire group that could only be made resilient single RP for an entire group that could only be made resilient
within one domain. While this approach solves the MSDP issues, it within one domain. While this approach solves the MSDP issues, it
does not solve the problem of unauthorised sources sending traffic to does not solve the problem of unauthorised sources sending traffic to
ASM multicast groups; this security issues is one of biggest problem ASM multicast groups; this security issues is one of biggest problem
of interdomain multicast. of interdomain multicast.
As stated in RFC 4607, SSM is particularly well-suited to As stated in RFC 4607, SSM is particularly well-suited to
dissemination-style applications with one or more senders whose dissemination-style applications with one or more senders whose
identities are known (by some oob mechanism) before the application identities are known (by some oob mechanism) before the application
starts running or applications that utilize some signaling to starts running or applications that utilize some signaling to
skipping to change at page 6, line 17 skipping to change at page 6, line 46
IP. IP.
SSM requires applications, host operating systems and the designated SSM requires applications, host operating systems and the designated
routers connected to receiving hosts to support IGMPv3 [RFC3376] and routers connected to receiving hosts to support IGMPv3 [RFC3376] and
MLDv2 [RFC3810]. Support for IGMPv3 and MLDv2 has become widespread MLDv2 [RFC3810]. Support for IGMPv3 and MLDv2 has become widespread
in common OSes for several years (Windows, MacOS, Linux/Android) and in common OSes for several years (Windows, MacOS, Linux/Android) and
is no longer an impediment to SSM deployment. is no longer an impediment to SSM deployment.
3.2. Advantages of SSM for interdomain multicast 3.2. Advantages of SSM for interdomain multicast
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 [RFC4607] for more details.
3.2.1. Reduced network operations complexity
A significant benefit of SSM is the reduced complexity that comes A significant benefit of SSM is the reduced complexity that comes
through eliminating the network-based source discovery required in through eliminating the network-based source discovery required in
ASM. Specifically, SSM eliminates the need for RPs, shared trees, ASM with PIM-SM. Specifically, SSM eliminates the need for RPs,
Shortest Path Tree (SPT) switchovers, PIM registers, MSDP, dynamic RP shared trees, Shortest Path Tree (SPT) switchovers, PIM registers,
discovery mechanisms (BSR/AutoRP) and data-driven state creation. MSDP, dynamic RP discovery mechanisms (BSR/AutoRP) and data-driven
SSM simply utilizes a small subset of PIM-SM, alongside the state creation. SSM simply utilizes a small subset of PIM-SM,
integration with IGMPv3 / MLDv2, where the source address signaled alongside the integration with IGMPv3 / MLDv2, where the source
from the receiver is immediately used to create (S,G) state. address signaled from the receiver is immediately used to create
Eliminating network-based source discovery for interdomain multicast (S,G) state. Eliminating network-based source discovery for
means the vast majority of the complexity of multicast goes away. interdomain multicast means the vast majority of the complexity of
multicast goes away.
This reduced complexity makes SSM radically simpler to manage, This reduced complexity makes SSM radically simpler to manage,
troubleshoot and operate, particularly for backbone network troubleshoot and operate, particularly for backbone network
operators. This is the main motivation for the recommendation to operators. This is the main operator motivation for the
deprecate the use of ASM in interdomain scenarios. Note that SSM recommendation to deprecate the use of ASM in interdomain scenarios.
operation is standardised in PIM-SM (RFC7761); there is no separate
specification for PIM-SSM.
RFC 4607 details many benefits of SSM, including: 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.
"Elimination of cross-delivery of traffic when two sources 3.2.2. No network wide IP multicast group-address management
simultaneously use the same source-specific destination address;
Avoidance of the need for inter-host coordination when choosing In ASM, IP multicast group addresses need to be assigned to
source-specific addresses, as a consequence of the above; 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.
Avoidance of many of the router protocols and algorithms that are Protocols to automate ASM IP multicast group allocations to
needed to provide the ASM service model." application instances where defined in the 1990'ths, but never widely
deployed: MADCAP [RFC2730], MASC [RFC2909] and MZAP [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.
Further discussion can also be found in [RFC3569]. 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.
SSM is considered more secure in that it inherently supports access 3.2.3. Intrinsic source-control security
control. That is, receivers only get packets from the sources they
explicitly specify, as opposed to ASM where any host can send traffic SSM is implicitly secure against unauthorized/undesired sources.
to a group address and have it transmitted to all receivers. This Receivers only receive packets from the sources they explicitly
topic is expanded upon in [RFC4609]. 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.
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.
This topic is expanded upon in [RFC4609].
4. Recommendations 4. Recommendations
4.1. Deprecating use of ASM for interdomain multicast 4.1. Deprecating use of ASM for interdomain multicast
This document recommends that the use of ASM is deprecated for This document recommends that the use of ASM is deprecated for
interdomain multicast, and thus implicitly, that hosts and routers interdomain multicast, and thus implicitly, that hosts and routers
that support such interdomain applications fully support SSM and its that support such interdomain applications fully support SSM and its
associated protocols. Best current practices for deploying associated protocols. Best current practices for deploying
interdomain multicast using SSM are documented in [RFC8313]. interdomain multicast using SSM are documented in [RFC8313].
skipping to change at page 8, line 29 skipping to change at page 9, line 47
"SSM can be used to build multi-source applications where all "SSM can be used to build multi-source applications where all
participants' identities are not known in advance, but the multi- participants' identities are not known in advance, but the multi-
source "rendezvous" functionality does not occur in the network source "rendezvous" functionality does not occur in the network
layer in this case. Just like in an application that uses unicast layer in this case. Just like in an application that uses unicast
as the underlying transport, this functionality can be implemented as the underlying transport, this functionality can be implemented
by the application or by an application-layer library." by the application or by an application-layer library."
Some useful considerations for multicast applications can be found in Some useful considerations for multicast applications can be found in
[RFC3170]. [RFC3170].
4.4. Preferring SSM applications intradomain 4.4. Developing application guidance: SSM, ASM, service discovery
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.
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 [RFC6763]
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.
4.5. Preferring SSM applications intradomain
If feasible, it is recommended for applications to use SSM even if If feasible, it is recommended for applications to use SSM even if
they are initially only meant to be used in intradomain environments they are initially only meant to be used in intradomain environments
supporting ASM. Because PIM-SSM is a subset of PIM-SM, existing supporting ASM. Because PIM-SSM is a subset of PIM-SM, existing
intradomain PIM-SM networks are automatically compatible with SSM intradomain PIM-SM networks are automatically compatible with SSM
applications. Thus, SSM applications can operate alongside existing applications. Thus, SSM applications can operate alongside existing
ASM applications. SSM's benefits of simplified address management ASM applications. SSM's benefits of simplified address management
and significantly reduced operational complexity apply equally to and significantly reduced operational complexity apply equally to
intradomain use. intradomain use.
However, for some applications it may be prohibitively difficult to However, for some applications it may be prohibitively difficult to
add support for source discovery, so intradomain ASM may still be add support for source discovery, so intradomain ASM may still be
appropriate. appropriate.
4.5. Documenting an ASM/SSM protocol mapping mechanism 4.6. Documenting an ASM/SSM protocol mapping mechanism
In the case of existing ASM applications that cannot readily be In the case of existing ASM applications that cannot readily be
ported to SSM, it may be possible to use some form of protocol 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 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 to a (S,G) join or leave, for a specific source, S. The general
challenge in performing such mapping is determining where the challenge in performing such mapping is determining where the
configured source address, S, comes from. configured source address, S, comes from.
There are existing vendor-specific mechanisms deployed that achieve There are existing vendor-specific mechanisms deployed that achieve
this function, but none are documented in IETF documents. This may 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 be a useful area for the IETF to work on as an interim transition
mechanism. However, these mechanisms would introduce additional mechanism. However, these mechanisms would introduce additional
administrative burdens, along with the need for some form of address administrative burdens, along with the need for some form of address
management, neither of which are required in SSM. Hence, this should management, neither of which are required in SSM. Hence, this should
not be considered a a long-term solution. not be considered a a long-term solution.
4.6. Not filtering ASM addressing between domains 4.7. Not filtering ASM addressing between domains
A key benefit of SSM is that the receiver specifies the source-group A key benefit of SSM is that the receiver specifies the source-group
tuple when signaling interest in a multicast stream. Hence, the tuple when signaling interest in a multicast stream. Hence, the
group address need not be globally unique, so there is no need for group address need not be globally unique, so there is no need for
multicast address allocation as long the reserved SSM range is used. multicast address allocation as long the reserved SSM range is used.
Despite the deprecation of interdomain ASM, it is recommended that Despite the deprecation of interdomain ASM, it is recommended that
operators should not filter ASM group ranges at domain boundaries, as 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. some form of ASM-SSM mappings may continue to be used for some time.
4.7. Not precluding Intradomain ASM 4.8. Not precluding Intradomain ASM
The use of ASM within a single multicast domain such as a campus or 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 is still relatively common today. There are even global
enterprise networks that have successfully been using PIM-SM for many enterprise networks that have successfully been using PIM-SM for many
years. The operators of such networks most often use Anycast-RP years. The operators of such networks most often use Anycast-RP
[RFC4610] or MSDP for RP resilience, at the expense of the extra [RFC4610] or MSDP (with IPv4) for RP resilience, at the expense of
operational complexity. These existing practices are unaffected by the extra operational complexity. These existing practices are
this document. unaffected by this document.
This document does not preclude continued use of ASM in the In the past decade, Bidir-PIM too has seen deployments to scale
intradomain scenario. If an organisation chooses to operate multiple interdomain ASM deployments beyond the capabilities of PIM-SM. This
multicast domains within its own administrative borders, it may then too is unaffected by this document, instead it is encouraged where
use MSDP or Embedded-RP internally within its own network. necessary due to application requirements (see Section 4.4.
5. Security Considerations 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 Section 3.2.
4.9. Evolving PIM deployments for SSM
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.
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.
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.
5. Future interdomain ASM work
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).
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
Section 3.2). Instead, this document believes that future work for
general purpose interdomain IP multicast is better spent on the SSM
items listed in Section 4.
6. Security Considerations
This document adds no new security considerations. It instead This document adds no new security considerations. It instead
removes security issues incurred by interdomain ASM with PIM-SM/MSDP removes security issues incurred by interdomain ASM with PIM-SM/MSDP
such as infrastructure control plane attacks and application and such as infrastructure control plane attacks and application and
bandwidth/congestion attacks from unauthorised sources sending to ASM bandwidth/congestion attacks from unauthorised sources sending to ASM
multicast groups. RFC 4609 describes the additional security multicast groups. RFC 4609 describes the additional security
benefits of using SSM instead of ASM. benefits of using SSM instead of ASM.
6. IANA Considerations 7. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed upon publication as Note to RFC Editor: this section may be removed upon publication as
an RFC. an RFC.
7. Acknowledgments 8. Acknowledgments
The authors would like to thank members of the IETF mboned WG for The authors would like to thank members of the IETF mboned WG for
discussions on the content of this document, with specific thanks to discussions on the content of this document, with specific thanks to
the following people for their contributions to the document: Hitoshi the following people for their contributions to the document: Hitoshi
Asaeda, Dale Carder, Jake Holland, Albert Manfredi, Mike McBride, Per Asaeda, Dale Carder, Jake Holland, Albert Manfredi, Mike McBride, Per
Nihlen, Greg Shepherd, James Stevens, Stig Venaas, Nils Warnke, and Nihlen, Greg Shepherd, James Stevens, Stig Venaas, Nils Warnke, and
Sandy Zhang. Sandy Zhang.
8. References 9. Changelog
8.1. Normative References [RFC-Editor: Please remove this section.]
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.
- NOTE: Text was not vetted by co-authors, so rev'ed just as
discussion basis.
- 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).
01 - Lenny: cleanup of text version, removed redundancies.
00 - initial IETF WG version. See draft-acg-mboned-deprecate-
interdomain-asm for work leading to this document.
10. References
10.1. Normative References
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, DOI 10.17487/RFC1112, August 1989, RFC 1112, DOI 10.17487/RFC1112, August 1989,
<https://www.rfc-editor.org/info/rfc1112>. <https://www.rfc-editor.org/info/rfc1112>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 11, line 25 skipping to change at page 14, line 44
IPv4 Multicast Address Assignments", BCP 51, RFC 5771, IPv4 Multicast Address Assignments", BCP 51, RFC 5771,
DOI 10.17487/RFC5771, March 2010, DOI 10.17487/RFC5771, March 2010,
<https://www.rfc-editor.org/info/rfc5771>. <https://www.rfc-editor.org/info/rfc5771>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <https://www.rfc-editor.org/info/rfc7761>. 2016, <https://www.rfc-editor.org/info/rfc7761>.
8.2. Informative References 10.2. Informative References
[RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address [RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address
Assignments", RFC 2375, DOI 10.17487/RFC2375, July 1998, Assignments", RFC 2375, DOI 10.17487/RFC2375, July 1998,
<https://www.rfc-editor.org/info/rfc2375>. <https://www.rfc-editor.org/info/rfc2375>.
[RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address
Dynamic Client Allocation Protocol (MADCAP)", RFC 2730,
DOI 10.17487/RFC2730, December 1999,
<https://www.rfc-editor.org/info/rfc2730>.
[RFC2776] Handley, M., Thaler, D., and R. Kermode, "Multicast-Scope
Zone Announcement Protocol (MZAP)", RFC 2776,
DOI 10.17487/RFC2776, February 2000,
<https://www.rfc-editor.org/info/rfc2776>.
[RFC2909] Radoslavov, P., Estrin, D., Govindan, R., Handley, M.,
Kumar, S., and D. Thaler, "The Multicast Address-Set Claim
(MASC) Protocol", RFC 2909, DOI 10.17487/RFC2909,
September 2000, <https://www.rfc-editor.org/info/rfc2909>.
[RFC3170] Quinn, B. and K. Almeroth, "IP Multicast Applications: [RFC3170] Quinn, B. and K. Almeroth, "IP Multicast Applications:
Challenges and Solutions", RFC 3170, DOI 10.17487/RFC3170, Challenges and Solutions", RFC 3170, DOI 10.17487/RFC3170,
September 2001, <https://www.rfc-editor.org/info/rfc3170>. September 2001, <https://www.rfc-editor.org/info/rfc3170>.
[RFC3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific [RFC3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific
Multicast (SSM)", RFC 3569, DOI 10.17487/RFC3569, July Multicast (SSM)", RFC 3569, DOI 10.17487/RFC3569, July
2003, <https://www.rfc-editor.org/info/rfc3569>. 2003, <https://www.rfc-editor.org/info/rfc3569>.
[RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source
Discovery Protocol (MSDP)", RFC 3618, Discovery Protocol (MSDP)", RFC 3618,
skipping to change at page 12, line 28 skipping to change at page 16, line 16
Independent Multicast - Sparse Mode (PIM-SM) Multicast Independent Multicast - Sparse Mode (PIM-SM) Multicast
Routing Security Issues and Enhancements", RFC 4609, Routing Security Issues and Enhancements", RFC 4609,
DOI 10.17487/RFC4609, October 2006, DOI 10.17487/RFC4609, October 2006,
<https://www.rfc-editor.org/info/rfc4609>. <https://www.rfc-editor.org/info/rfc4609>.
[RFC4611] McBride, M., Meylor, J., and D. Meyer, "Multicast Source [RFC4611] McBride, M., Meylor, J., and D. Meyer, "Multicast Source
Discovery Protocol (MSDP) Deployment Scenarios", BCP 121, Discovery Protocol (MSDP) Deployment Scenarios", BCP 121,
RFC 4611, DOI 10.17487/RFC4611, August 2006, RFC 4611, DOI 10.17487/RFC4611, August 2006,
<https://www.rfc-editor.org/info/rfc4611>. <https://www.rfc-editor.org/info/rfc4611>.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007,
<https://www.rfc-editor.org/info/rfc5015>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>. March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8313] Tarapore, P., Ed., Sayko, R., Shepherd, G., Eckert, T., [RFC8313] Tarapore, P., Ed., Sayko, R., Shepherd, G., Eckert, T.,
Ed., and R. Krishnan, "Use of Multicast across Inter- Ed., and R. Krishnan, "Use of Multicast across Inter-
domain Peering Points", BCP 213, RFC 8313, domain Peering Points", BCP 213, RFC 8313,
DOI 10.17487/RFC8313, January 2018, DOI 10.17487/RFC8313, January 2018,
<https://www.rfc-editor.org/info/rfc8313>. <https://www.rfc-editor.org/info/rfc8313>.
 End of changes. 41 change blocks. 
105 lines changed or deleted 287 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/