draft-ietf-mboned-deprecate-interdomain-asm-00.txt   draft-ietf-mboned-deprecate-interdomain-asm-01.txt 
Mboned M. Abrahamsson Mboned M. Abrahamsson
Internet-Draft T-Systems Internet-Draft T-Systems
Intended status: Best Current Practice T. Chown Intended status: Best Current Practice T. Chown
Expires: February 10, 2019 Jisc Expires: April 25, 2019 Jisc
L. Giuliano L. Giuliano
Juniper Networks, Inc. Juniper Networks, Inc.
T. Eckert T. Eckert
Huawei Huawei
August 9, 2018 October 22, 2018
Deprecating ASM for Interdomain Multicast Deprecating ASM for Interdomain Multicast
draft-ietf-mboned-deprecate-interdomain-asm-00 draft-ietf-mboned-deprecate-interdomain-asm-01
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 that are expected to handle applications and that hosts and routers in these deployments fully
such applications fully support SSM. The recommendations in this support SSM. The recommendations in this document do not preclude
document do not preclude the continued use of ASM within a single the continued use of ASM within a single organisation or domain and
organisation or domain, and are especially easy to adopt when already are especially easy to adopt in these existing intradomain ASM
using the preferred ASM protocol options there (PIM-SM). deployments.
Requirements Language Requirements Language
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].
Status of This Memo Status of This Memo
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 10, 2019. This Internet-Draft will expire on April 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Multicast routing protocols . . . . . . . . . . . . . . . . . 3 2. Multicast routing protocols . . . . . . . . . . . . . . . . . 3
2.1. ASM routing protocols . . . . . . . . . . . . . . . . . . 4 2.1. ASM routing protocols . . . . . . . . . . . . . . . . . . 4
2.2. SSM Routing protocols . . . . . . . . . . . . . . . . . . 5 2.2. SSM Routing protocols . . . . . . . . . . . . . . . . . . 4
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 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Deprecating use of ASM for interdomain multicast . . . . 7 4.1. Deprecating use of ASM for interdomain multicast . . . . 7
4.2. Including network support for IGMPv3 / MLDv2 . . . . . . 8 4.2. Including network support for IGMPv3 / MLDv2 . . . . . . 7
4.3. Building application support for SSM . . . . . . . . . . 8 4.3. Building application support for SSM . . . . . . . . . . 8
4.4. Preferring SSM applications intradomain . . . . . . . . . 9 4.4. Preferring SSM applications intradomain . . . . . . . . . 8
4.5. Documenting common practices for SSM support in 4.5. Documenting an ASM/SSM protocol mapping mechanism . . . . 8
applications. . . . . . . . . . . . . . . . . . . . . . . 9 4.6. Not filtering ASM addressing between domains . . . . . . 9
4.6. Documenting an ASM/SSM protocol mapping mechanism . . . . 10 4.7. Not precluding Intradomain ASM . . . . . . . . . . . . . 9
4.7. Not filtering ASM addressing between domains . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
4.8. Not precluding Intradomain ASM . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Congestion Control Considerations . . . . . . . . . . . . . . 11 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
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.
This document addresses this gap by making a BCP-level recommendation This document addresses this gap by making a BCP-level recommendation
to deprecate the use of ASM for interdomain multicast, leaving SSM as to deprecate the use of ASM for interdomain multicast, leaving SSM as
the remaining interdomain mode of multicast. This recommendation the recommended interdomain mode of multicast. This recommendation
thus also implicitly states that all hosts and routers that are thus also implicitly states that all hosts and routers that are
expected to support interdomain multicast applications fully support expected to support interdomain multicast applications fully support
SSM. SSM.
This document does not make any statement on the use of ASM within a This document does not make any statement on the use of ASM within a
single domain or organisation, and therefore does not preclude its single domain or organisation, and therefore does not preclude its
use. Indeed, there are application contexts for which ASM is use. Indeed, there are application contexts for which ASM is
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 will first get used intradomain but only support. Many applications are initially deployed for intradomain
later interdomain. Therefore, this document recommends making use and are later deployed interdomain. Therefore, this document
applications support SSM, even when they are initially meant to be recommends applications support SSM, even when they are initially
just used intradomain. As explained below, SSM applications are intended for intradomain use. As explained below, SSM applications
readily compatible with existing intradomain ASM deployments that are readily compatible with existing intradomain ASM deployments as
follow the current IETF standard protocol recommendations. SSM is merely a subset of ASM.
2. Multicast routing protocols 2. Multicast routing protocols
The general IP multicast service model [RFC1112] is that sender(s) Any-Source Multicast (ASM) and Source-Specific Multicast (SSM) are
send to a multicast group address, receivers express an interest in the two multicast service models in use today. In ASM, as originally
traffic sent to a given multicast group address, and that routers use described in [RFC1112], receivers express interest in joining a
multicast routing protocols to determine how to deliver traffic from multicast group address and routers use multicast routing protocols
the sender(s) to the receivers. 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
Two high-level flavours of this service model have evolved over time. delivered to the receiver. Since receivers specify only the group
In Any-Source Multicast (ASM), any number of sources may transmit address, the network, and therefore the multicast routing protocols,
multicast packets, and those sources may come and go over the course are responsible for source discovery. In SSM, by contrast, receivers
of a multicast session without being known a priori. In ASM, specify both group and source when expressing interest in joining a
receivers express interest only in a given multicast group address, multicast stream. Source discovery in SSM is handled by some out-of-
and the multicast routing protocol facilitates source discovery at band mechanism (ie, the application layer), which drastically
the network layer. ASM is simply the name given to the 1989 RFC1112 simplifies the network and how the multicast routing protocols
IP Multicast model when in around 2000 the idea for the alternative operate.
SSM model was taking shape: In Source-Specific Multicast (SSM) the
specific source(s) that may send traffic to the group are known in
advance by the receivers, or may be determined during a session,
typically through an out-of-band protocol sitting above the network
layer. Thus in SSM, receivers express interest in both a multicast
group address and specific associated source address(es).
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.1. ASM routing protocols
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, or 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 it does not know sender addresses in
advance, PIM-SM uses the concept of a Rendezvous Point (RP) to 'marry advance, PIM-SM uses the concept of a Rendezvous Point (RP) as a
up' senders and receivers, and all routers in a PIM-SM domain are 'meeting point' for sources and receivers, and all routers in a PIM-
configured to use specific RP(s), either explicitly or through SM domain are configured to use specific RP(s), either explicitly or
dynamic RP discovery protocols. through dynamic RP discovery protocols.
To enable PIM-SM to work between multiple domains, i.e., to allow an To enable PIM-SM to work between multiple domains, an inter-RP
RP in one domain to learn the existence of a source in another signalling protocol known as Multicast Source Discovery Protocol
domain, an inter-RP signalling protocol known as Multicast Source (MSDP) [RFC3618] is used to allow an RP in one domain to learn the
Discovery Protocol (MSDP) [RFC3618] is used. Deployment scenarios existence of a source in another domain. Deployment scenarios for
for MSDP are given in [RFC4611]. MSDP has remained an Experimental MSDP are given in [RFC4611]. MSDP floods information about all
protocol since its publication in 2003. One core reason for this is active sources for all multicast streams to all RPs in all the
the need to flood information about all active sources for all active domains - even if there is no receiver for a given application in a
applications to the RPs in all the domains in an MSDP peering mesh - domain. As a result of this key scalability and security issue,
even if there is no receiver for a given application in a domain. along with other deployment challenges with the protocol, MSDP was
This is the key scalability and security issue with MSDP and also the never extended to support IPv6 and remains an Experimental protocol.
reason why it was not extended to support IPv6.
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 discovery problem, and it stayed Experimental. for the interdomain source discovery problem, and it is Experimental.
Other protocol options where investigated at the same time but did Other protocol options where investigated at the same time but were
achieve at most achieve IETF informational status and are now never implemented or deployed and are now historic (e.g: [RFC3913]).
historic (e.g: [RFC3913]).
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 able to be designed in support of
interdomain ASM with PIM-SM. Embedded-RP [RFC3956] allows routers interdomain ASM with PIM-SM. Embedded-RP [RFC3956] allows routers
supporting the protocol to determine the RP for the group without any supporting the protocol to determine the RP for the group without any
prior configuration or discovery protocols, simply by observing the prior configuration or discovery protocols, simply by observing the
unicast RP address that is embedded (included) in the IPv6 multicast unicast RP address that is embedded (included) in the IPv6 multicast
group address. Embedded-RP allows PIM-SM operation across any IPv6 group address. Embedded-RP allows PIM-SM operation across any IPv6
network (intradomain but especially interdomain) in which there is an network in which there is an end-to-end path of routers supporting
end-to-end path of routers supporting the mechanism. the mechanism.
2.2. SSM Routing protocols 2.2. SSM Routing protocols
SSM is detailed in [RFC4607]. It is in effect a subset of PIM-SM SSM is detailed in [RFC4607]. Note that there is no separate
where no RP is used. Note that there is no separate document for document for PIM-SSM as it merely leverages a subset of [RFC7761].
PIM-SSM, it just leverages a subset of [RFC7761].
PIM-SSM expects that sender source address(es) are known in advance PIM-SSM expects that the sender's source address(es) is known in
by receivers; i.e., a given source's IP address is known (by some out advance by receivers by some out-of-band mechanism (typically in the
of band mechanism), and thus the receiver's router can send a PIM application layer), and thus the receiver's designated router can
JOIN directly towards the sender, without needing to use an RP. send a PIM JOIN directly towards the source without needing to use an
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
3.1. Observations on ASM and SSM deployments 3.1. Observations on ASM and SSM deployments
In enterprise and campus scenarios, ASM in the form of PIM-SM is In enterprise and campus scenarios, ASM in the form of PIM-SM is
likely the most commonly deployed multicast protocol and has likely the most commonly deployed multicast protocol. The
generally replaced PIM-DM [RFC3973], which is an IETF Experimental configuration and management of an RP (including RP redundancy)
category RFC, while PIM-SM is full Internet Standard. The within a single domain is a well understood operational practice.
configuration and management of an RP (even with RP redundancy)
within a single domain is well understood operational practice.
However, if interworking with external PIM domains is needed in IPv4 However, if interworking with external PIM domains is needed in IPv4
multicast deployments, interdomain MSDP is required to exchange multicast deployments, interdomain MSDP is required to exchange
information about sources between domain RPs. The problems with this information about sources between domain RPs. Deployment experience
use of MSDP are as explained above. They are the problems that make has shown MSDP to be a complex and fragile protocol to manage and
MSDP an Experimental protocol, and that make it (in these troubleshoot (complex flooding RPF rules, state attack protection,
deployments) a complex and fragile protocol to administer and filtering of undesired sources, ...).
troubleshoot (flooding RPF rules, state attack protection, undesired
source filtering, ...).
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. In these applications it is typically only unnecessary complexity. Therefore, SSM eliminates the most
necessary to extend the configuration or signaling for the IP components of PIM-SM.
multicast group to be used with the additional information on the IP
multicast source to be used. There are also various techniques to
use a single logical "anycast" source address supported by two or
more redundant senders to give additional reliability for SSM, and to
offer simpler deployment by using that address as a "static"/"well-
known" address.
As explained above, MSDP was not taken forward to IPv6. Instead, the As explained above, MSDP was not extended to support to IPv6.
proposed interdomain ASM solution for PIM-SM with IPv6 is Embedded- Instead, the proposed interdomain ASM solution for PIM-SM with IPv6
RP, which allows the RP address for a multicast group to be embedded is Embedded-RP, which allows the RP address for a multicast group to
in the group address, making RP discovery automatic, if all routers be embedded in the group address, making RP discovery automatic for
on the path between a receiver and a sender support the protocol. all routers on the path between a receiver and a sender. Embedded-RP
Embedded-RP can support lightweight ad-hoc deployments. However, it can support lightweight ad-hoc deployments. However, it relies on a
relies on a single RP for an entire group that could only be made single RP for an entire group that could only be made resilient
resilient within one domain. While this approach solves the MSDP within one domain. While this approach solves the MSDP issues, it
issues, it does not solve the problem of unauthorised sources sending does not solve the problem of unauthorised sources sending traffic to
traffic to ASM multicast groups; this security issues is one of ASM multicast groups; this security issues is one of biggest problem
biggest problem of interdomain multicast. Embedded-RP was run of interdomain multicast.
successfully between European and US academic networks during the
6NET project in 2004/05. Its usage generally remains constrained to
academic networks.
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 mechanism) before the application identities are known (by some oob mechanism) before the application
starts running - or applications that have some existing signaling starts running or applications that utilize some signaling to
indicating multicast groups, where the additional source address can indicate the source address of the multicast stream (eg, electronic
easily be added - for example electronic programming guide signalling programming guide in IPTV applications). PIM-SSM is therefore very
in IPTV applications. PIM-SSM is therefore very well-suited to well-suited to applications such as classic linear broadcast TV over
applications such as classic linear broadcast TV over IP. IP.
SSM requires applications, host operating systems and their subnet SSM requires applications, host operating systems and the designated
routers using it to support the new(er) IGMPv3 [RFC3376] and MLDv2 routers connected to receiving hosts to support IGMPv3 [RFC3376] and
[RFC3810] protocols. While delayed delivery of support in some OSes MLDv2 [RFC3810]. Support for IGMPv3 and MLDv2 has become widespread
has meant that adoption of SSM has been slower than might have been in common OSes for several years (Windows, MacOS, Linux/Android) and
expected, or hoped, and was a historical reason to use ASM rather is no longer an impediment to SSM deployment.
than SSM, support for IGMPv3 and MLDv2 has become widespread in
common OSes for several years (Windows, MacOS, Linux/Android).
3.2. Advantages of SSM for interdomain multicast 3.2. Advantages of SSM for interdomain multicast
A significant benefit of SSM is its reduced complexity through A significant benefit of SSM is the reduced complexity that comes
eliminating the network-based source discovery required in ASM. This through eliminating the network-based source discovery required in
means there are no RPs, shared trees, Shortest Path Tree (SPT) ASM. Specifically, SSM eliminates the need for RPs, shared trees,
switchovers, PIM registers, MSDP, or data-driven state creation Shortest Path Tree (SPT) switchovers, PIM registers, MSDP, dynamic RP
elements to support, or any requirement to run dynamic RP discovery discovery mechanisms (BSR/AutoRP) and data-driven state creation.
and redundancy signaling protocols such as BSR. SSM is really just a SSM simply utilizes a small subset of PIM-SM, alongside the
small subset of PIM-SM, alongside the integration with IGMPv3 / MLDv2 integration with IGMPv3 / MLDv2, where the source address signaled
where the source address signaled from the receiver is immediately from the receiver is immediately used to create (S,G) state.
used to create (S,G) state. Eliminating network-based source Eliminating network-based source discovery for interdomain multicast
discovery for interdomain multicast means the vast majority of the means the vast majority of the complexity of multicast goes away.
complexity issues go away.
This reduced complexity makes SSM radically simpler to manage, This reduced complexity makes SSM radically simpler to manage,
troubleshoot and operate, particularly for network backbone troubleshoot and operate, particularly for backbone network
operators, and this is the main operator motivation for the operators. This is the main motivation for the recommendation to
recommendation to deprecate the use of ASM in interdomain scenarios. deprecate the use of ASM in interdomain scenarios. Note that SSM
Note that SSM operation is all standardised in PIM-SM (RFC7761). operation is standardised in PIM-SM (RFC7761); there is no separate
There is no separate specification for PIM-SSM. specification for PIM-SSM.
RFC 4607 details many benefits of SSM, including: RFC 4607 details many benefits of SSM, including:
"Elimination of cross-delivery of traffic when two sources "Elimination of cross-delivery of traffic when two sources
simultaneously use the same source-specific destination address; simultaneously use the same source-specific destination address;
Avoidance of the need for inter-host coordination when choosing Avoidance of the need for inter-host coordination when choosing
source-specific addresses, as a consequence of the above; source-specific addresses, as a consequence of the above;
Avoidance of many of the router protocols and algorithms that are Avoidance of many of the router protocols and algorithms that are
needed to provide the ASM service model." needed to provide the ASM service model."
Further discussion can also be found in [RFC3569]. Further discussion can also be found in [RFC3569].
SSM is considered more secure in that it supports access control, SSM is considered more secure in that it inherently supports access
i.e. you only get packets from the sources you explicitly ask for, as control. That is, receivers only get packets from the sources they
opposed to ASM where anyone can decide to send traffic to a PIM-SM explicitly specify, as opposed to ASM where any host can send traffic
group address. This topic is expanded upon in [RFC4609]. to a group address and have it transmitted to all receivers. 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 are expected to support such interdomain applications fully that support such interdomain applications fully support SSM and its
support SSM and its associated protocols. Best current practices for associated protocols. Best current practices for deploying
deploying interdomain multicast using SSM are documented in interdomain multicast using SSM are documented in [RFC8313].
[RFC8313].
The recommendation applies to the use of ASM between domains where The recommendation applies to the use of ASM between domains where
either MSDP (IPv4) or Embedded-RP (IPv6) is used for sharing either MSDP (IPv4) or Embedded-RP (IPv6) is used.
knowledge of remote sources (MSDP) or RPs (Embedded-RP).
This document also recommends against the interdomain use of PIM-SM
with a (potentially redundant) RP, where multicast tunnels are used
between domains.
An interdomain use of ASM multicast in the context of this document An interdomain use of ASM multicast in the context of this document
is primarily one where PIM-SM for ASM, e.g., with RPs/MSDP/Embedded- is one where PIM-SM with RPs/MSDP/Embedded-RP is run on routers
RP, is run on routers operated by two or more separate operational operated by two or more separate administrative entities (domains,
entities (domains, organisations). organisations).
The more inclusive interpretation of this recommendation is that it The more inclusive interpretation of this recommendation is that it
also extends to the case where PIM may only be operated in a single 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 operator domain, but where user hosts or non-PIM network edge devices
are under different operator control. A typical example of this case are under different operator control. A typical example of this case
is an SP providing IPTV (single operator domain for PIM) to is an SP providing IPTV (single operator domain for PIM) to
subscribers operating an IGMP proxy home gateway and IGMPv3/MLDv2 subscribers operating an IGMP proxy home gateway and IGMPv3/MLDv2
hosts (computer, tablets, set-top boxes). hosts (computer, tablets, set-top boxes).
While MSDP is an Experimental category IETF standard, this document
does not propose making MSDP Historic, given its use may be desirable
for intradomain multicast use cases (e.g., RP redundancy
intradomain). This may change in future documents should a successor
to MSDP for intradomain RP redundancy ([RFC4610]) be defined to add
better support for some currently missing operational requirements.
4.2. Including network support for IGMPv3 / MLDv2 4.2. Including network support for IGMPv3 / MLDv2
This document recommends that all host and router platforms This document recommends that all hosts, router platforms and
supporting multicast, and any security appliances that may handle security appliances supporting multicast support IGMPv3 [RFC3376] and
multicast traffic, support IGMPv3 [RFC3376] and MLDv2 [RFC3810] MLDv2 [RFC3810] (based on the version IP they intend to support).
(based on the version IP they intend to support). The updated IPv6 The updated IPv6 Node Requirements RFC [I-D.ietf-6man-rfc6434-bis]
Node Requirements RFC [I-D.ietf-6man-rfc6434-bis] states that MLDv2 states that MLDv2 support is a MUST in all implementations. Such
support is a MUST in all implementations. Such support is already support is already widespread in common host and router platforms.
widespread in common host and router platforms.
Further guidance on IGMPv3 and MLDv2 is given in [RFC4604]. Further guidance on IGMPv3 and MLDv2 is given in [RFC4604].
It is sometimes desirable to limit the propagation of multicast Multicast snooping is often used limit the flooding of multicast
messages in a layer 2 network, typically through a layer 2 switch traffic in a layer 2 network. With snooping, a L2 switch will
device. In such cases multicast snooping can be used, by which the monitor IGMP/MLD messages and only forward multicast traffic out host
switch device observes the IGMP/MLD traffic passing through it, and ports that have interested receivers connected. Such snooping
then attempts to make intelligent decisions about on which physical capability should therefore support IGMPv3 and MLDv2. There is
ports it should forward multicast. Typically, ports that have not further discussion in [RFC4541].
expressed an interest in receiving multicast for a given group would
not have traffic for that group forwarded through them. Such
snooping capability should therefore support IGMPv3 and MLDv2. There
is further discussion in [RFC4541].
4.3. Building application support for SSM 4.3. Building application support for SSM
There is a wide range of applications today that only support ASM
(mostly for historic reasons), whether as software packages, or code
embedded in devices such as set-top boxes.
The recommendation to use SSM for interdomain multicast means that The recommendation to use SSM for interdomain multicast means that
applications should use SSM, and operate correctly in an SSM applications should properly trigger the sending of IGMPv3/MLDv2
environment, triggering IGMPv3/MLDv2 messages to signal use of SSM. 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.
It is often thought that ASM is required for multicast applications It is often thought that ASM is required for multicast applications
where there are multiple sources. However, RFC 4607 also describes where there are multiple sources. However, RFC 4607 also describes
how SSM can be used instead of PIM-SM for multi-party applications: how SSM can be used instead of PIM-SM for multi-party applications:
"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."
Given all common OSes support SSM, it is then down to the programming Some useful considerations for multicast applications can be found in
language and APIs used as to whether the necessary SSM APIs are [RFC3170].
available. SSM support became first ubiquitous for C/C++/Python, and
key exceptions today include websockets used in web-browser based
applications (see e.g.: https://github.com/nodejs/node/pull/15735/
files introducing SSM support there in 2017).
Some useful considerations for multicast applications can still be
found in the relatively old [RFC3170].
4.4. Preferring SSM applications intradomain 4.4. Preferring SSM applications intradomain
If feasible, it is recommended to make applications 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, it should be supporting ASM. Because PIM-SSM is a subset of PIM-SM, existing
possible to readily make existing intradomain PIM-SM networks intradomain PIM-SM networks are automatically compatible with SSM
compatible with SSM application receivers, therefore allowing applications. Thus, SSM applications can operate alongside existing
continued use of an existing ASM PIM-SM deployment in a network with ASM applications. SSM's benefits of simplified address management
no or very little changes. SSM's benefits of simplified address and significantly reduced operational complexity apply equally to
management and significantly reduced operational complexity apply intradomain use.
equally to 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 signaling of source IP addresses into the add support for source discovery, so intradomain ASM may still be
application. appropriate.
4.5. Documenting common practices for SSM support in applications.
Currently, there is no good document summarising best current
practices to convert ASM applications into SSM applications, or how
to most easily support SSM in greenfield application designs. This
would be useful guidance for the IETF to work on.
4.6. Documenting an ASM/SSM protocol mapping mechanism 4.5. 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 this function, but none are documented in IETF documents. This may
appears to be a useful area for the IETF to work on, but it should be be a useful area for the IETF to work on as an interim transition
noted that any such effort would only be an interim transition mechanism. However, these mechanisms would introduce additional
mechanism, and such mappings do not remove the requirement for administrative burdens, along with the need for some form of address
applications to be allocated ASM group addresses for the management, neither of which are required in SSM. Hence, this should
communications. not be considered a a long-term solution.
The reason why these mechanisms should not be considered a long-term
solution is because they introduce network operator management work,
and need some form of address management, both of which are not
required in SSM.
4.7. Not filtering ASM addressing between domains 4.6. Not filtering ASM addressing between domains
A key benefit of SSM is that a multicast application does not need to A key benefit of SSM is that the receiver specifies the source-group
be allocated a specific multicast group by the network, rather as SSM tuple when signaling interest in a multicast stream. Hence, the
is inherently source-specific, it can use any group address, G, in group address need not be globally unique, so there is no need for
the reserved range of IPv4 or IPv6 SSM addresses for its own source multicast address allocation as long the reserved SSM range is used.
address, S.
In principle, if interdomain ASM is deprecated, backbone operators Despite the deprecation of interdomain ASM, it is recommended that
could begin filtering the ranges of group addresses used by ASM. In operators should not filter ASM group ranges at domain boundaries, as
practice, this is not recommended given there will be a transition some form of ASM-SSM mappings may continue to be used for some time.
period from ASM to SSM, where some form of ASM-SSM mappings may be
used, and filtering may preclude such operations.
4.8. Not precluding Intradomain ASM 4.7. 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, with an RP for the site, is still relatively common enterprise is still relatively common today. There are even global
today. There are even global enterprise networks that have enterprise networks that have successfully been using PIM-SM for many
successfully been using PIM-SM for many years. The operators of such years. The operators of such networks most often use Anycast-RP
networks most often use Anycast-RP [RFC4610] or MSDP for RP [RFC4610] or MSDP for RP resilience, at the expense of the extra
resilience, at the expense of the extra complexity in managing that operational complexity. These existing practices are unaffected by
configuration. These existing practices are unaffected by this this document.
document.
This document does not preclude continued use of ASM in the This document does not preclude continued use of ASM in the
intradomain scenario. If an organisation, or AS, wishes to use intradomain scenario. If an organisation chooses to operate multiple
multiple multicast domains within its own network border, that is a multicast domains within its own administrative borders, it may then
choice for that organisation to make, and it may then use MSDP or use MSDP or Embedded-RP internally within its own network.
Embedded-RP internally within its own network.
5. Congestion Control Considerations
Traffic over non-controlled networks, which most interdomain paths
are, must support congestion control. This is achievable with rate
adaptation, layered codecs, circuit breakers and/or other appropriate
mechanisms. See [RFC8085].
6. Security Considerations 5. 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
infrastructure control plane attacks and application and bandwidth/ such as infrastructure control plane attacks and application and
congestion attacks from unauthorised sources sending to ASM multicast bandwidth/congestion attacks from unauthorised sources sending to ASM
groups. RFC 4609 describes the additional security benefits of using multicast groups. RFC 4609 describes the additional security
SSM instead of ASM. benefits of using SSM instead of ASM.
7. IANA Considerations 6. 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.
8. Acknowledgments 7. 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.
9. References 8. References
9.1. Normative References 8.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 13, line 5 skipping to change at page 11, line 25
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>.
9.2. Informative References 8.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>.
[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
skipping to change at page 14, line 45 skipping to change at page 13, line 15
Jisc Jisc
Lumen House, Library Avenue Lumen House, Library Avenue
Harwell Oxford, Didcot OX11 0SG Harwell Oxford, Didcot OX11 0SG
United Kingdom United Kingdom
Email: tim.chown@jisc.ac.uk Email: tim.chown@jisc.ac.uk
Lenny Giuliano Lenny Giuliano
Juniper Networks, Inc. Juniper Networks, Inc.
2251 Corporate Park Drive 2251 Corporate Park Drive
Hemdon, Virginia 20171 Herndon, Virginia 20171
United States United States
Email: lenny@juniper.net Email: lenny@juniper.net
Toerless Eckert Toerless Eckert
Futurewei Technologies Inc. Futurewei Technologies Inc.
2330 Central Expy 2330 Central Expy
Santa Clara 95050 Santa Clara 95050
USA USA
Email: tte+ietf@cs.fau.de Email: tte+ietf@cs.fau.de
 End of changes. 55 change blocks. 
271 lines changed or deleted 196 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/