Deprecating ASM for Interdomain Multicast
draft-acg-mboned-multicast-models-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Mikael Abrahamsson , Tim Chown , Lenny Giuliano | ||
| Last updated | 2017-10-30 | ||
| Replaced by | draft-acg-mboned-deprecate-interdomain-asm | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-acg-mboned-multicast-models-01
Mboned M. Abrahamsson
Internet-Draft T-Systems
Intended status: Best Current Practice T. Chown
Expires: May 3, 2018 Jisc
L. Giuliano
Juniper Networks, Inc.
October 30, 2017
Deprecating ASM for Interdomain Multicast
draft-acg-mboned-multicast-models-01
Abstract
This document provides a high-level overview of more commonly used
multicast service models, principally the Any-Source Multicast (ASM)
and Source-Specific Multicast (SSM) models, and discusses the
applicability of the models to certain scenarios. As a result, this
document recommends that ASM is not used for interdomain scenarios,
and the use of SSM is strongly recommended for all multicast
scenarios.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 3, 2018.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Abrahamsson, et al. Expires May 3, 2018 [Page 1]
Internet-Draft Deprecating Interdomain ASM October 2017
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Multicast service models . . . . . . . . . . . . . . . . . . 3
3. Multicast building blocks . . . . . . . . . . . . . . . . . . 4
3.1. Multicast addressing . . . . . . . . . . . . . . . . . . 4
3.2. Host signalling . . . . . . . . . . . . . . . . . . . . . 4
3.3. Multicast snooping . . . . . . . . . . . . . . . . . . . 4
4. ASM service model protocols . . . . . . . . . . . . . . . . . 5
4.1. Protocol Independent Multicast, Dense Mode (PIM-DM) . . . 5
4.2. Protocol Independent Multicast, Sparse Mode (PIM-SM) . . 5
4.2.1. Interdomain PIM-SM, and MSDP . . . . . . . . . . . . 6
4.3. Bidirectional PIM (PIM-BIDIR) . . . . . . . . . . . . . . 6
4.4. IPv6 PIM-SM with Embedded RP . . . . . . . . . . . . . . 6
5. SSM service model protocols . . . . . . . . . . . . . . . . . 6
5.1. Source Specific Multicast (PIM-SSM) . . . . . . . . . . . 7
6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. ASM Deployment . . . . . . . . . . . . . . . . . . . . . 7
6.2. SSM Deployment . . . . . . . . . . . . . . . . . . . . . 8
7. Recomendation to deprecate ASM for interdomain use . . . . . 8
7.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 8
7.2. On deprecating interdomain ASM . . . . . . . . . . . . . 9
7.3. Intradomain ASM . . . . . . . . . . . . . . . . . . . . . 9
7.4. IGMPv3/MLDv2 support . . . . . . . . . . . . . . . . . . 9
7.5. Addressing considerations . . . . . . . . . . . . . . . . 10
7.6. Application considerations . . . . . . . . . . . . . . . 10
7.7. ASM/SSM transition - protocol mapping . . . . . . . . . . 11
8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
12.1. Normative References . . . . . . . . . . . . . . . . . . 12
12.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
IP Multicast has been deployed in various forms, both within private
networks and on the wider Internet. While a number of service models
have been published individually, and in many cases revised over
time, there has been no strong recommendation made on the
Abrahamsson, et al. Expires May 3, 2018 [Page 2]
Internet-Draft Deprecating Interdomain ASM October 2017
appropriateness of the models to certain scenarios. This document
aims to fill that gap, and includes a BCP-level recommendation to
both deprecate the use of interdomain ASM and to promote the use of
SSM for all multicast scenarios.
2. Multicast service models
The general IP multicast service model [RFC1112] is that senders send
to a multicast IP address, receivers express an interest in traffic
sent to a given multicast address, and that routers figure out how to
deliver traffic from the senders to the receivers.
The benefit of IP multicast is that it enables delivery of content
such that any multicast packet sent from a source to a given
multicast group address appears once and only once on any path
between a sender and an interested receiver that has joined that
multicast group. The principal advantage, in terms of bandwidth
conservation will lie with the sender, i.e., at the head end.
A reserved range of IP addresses (for either IPv4 or IPv6) is used
for multicast group communication.
Two high-level flavours of this service model have evolved over time.
In Any-Source Multicast (ASM), any number of sources may transmit
multicast packets, and those sources may come and go over the course
of a multicast session without being known a priori. In ASM,
receivers express interest only in a given multicast group address.
In contrast, with Source-Specific Multicast (SSM) the specific
source(s) that may send traffic to the group are known in advance.
In SSM, receivers express interest both in a given multicast address
and specific associated source address(es).
Senders transmit multicast packets without knowing where receivers
are, or how many there are. Receivers are able to signal to on-link
routers their desire to receive multicast content sent to a given
multicast group, and in the case of SSM from a specific sender IP
address. They may discover the group (and sender IP) information in
a number of different ways. They are also able to signal their
desire to no longer receive multicast traffic for a given group (and
sender IP).
Multicast routing protocols are used to establish the multicast
forwarding paths (tree) between a sender and a set of receivers.
Each router would typically maintain multicast forwarding state for a
given group (and potentially sender IP), such that it knows onwhich
interfaces to forward (and where necessary replicate) multicast
packets.
Abrahamsson, et al. Expires May 3, 2018 [Page 3]
Internet-Draft Deprecating Interdomain ASM October 2017
Multicast packet forwarding is generally not considered a reliable
service. It is typically unidirectional, but a bidirectional
multicast delivery mechanism also exists.
3. Multicast building blocks
In this section we describe general multicast building blocks that
are applicable to both ASM and SSM deployment.
3.1. Multicast addressing
IANA has reserved specific ranges of IPv4 and IPv6 address space for
multicast addressing.
Guidelines for IPv4 multicast address assignments can be found in
[RFC5771]. IPv4 has no explicit multicast address format; a specific
portion of the overall IPv4 address space is reserved for multicast
use (224.0.0.0/4).
Guidelines for IPv6 multicast address assignments can be found in
[RFC2375] and [RFC3307]. The IPv6 multicast address format is
described in [RFC4291]. An IPv6 multicast group address will lie
within ff00::/8.
3.2. Host signalling
A host wishing to signal interest in receiving (or no longer
receiving) multicast to a given multicast group (and potentially from
a specific sender IP) may do so by sending a packet using one of the
protocols described below on an appropriate interface.
For IPv4, a host may use Internet Group Management Protocol Version 2
(IGMPv2) [RFC2236] to signal interest in a given group. IGMPv3
[RFC3376] has the added capability of specifying interest in
receiving multicast packets from specific sources.
For IPv6, a host may use Multicast Listener Discovery Protocol (MLD)
[RFC2710] to signal interest in a given group. MLDv2 [RFC3810] has
the added capability of specifying interest in receiving multicast
packets from specific sources.
Further guidance on IGMPv3 and MLDv2 is given in [RFC4604].
3.3. Multicast snooping
In some cases, it is desirable to limit the propogation of multicast
messages in a layer 2 network, typically through a layer 2 switch
device. In such cases multicast snopping can be used, by which the
Abrahamsson, et al. Expires May 3, 2018 [Page 4]
Internet-Draft Deprecating Interdomain ASM October 2017
switch device observes the IGMP/MLD traffic passing through it, and
then attempts to make intelligent decisions on which physical ports
to forward multicast. Typically, ports that have not expressed an
interest in receiving multicast for a given group would not have
traffic for that group forwarded through them. There is further
discussion in [RFC4541].
4. ASM service model protocols
4.1. Protocol Independent Multicast, Dense Mode (PIM-DM)
PIM-DM is detailed in [RFC3973]. It operates by flooding multicast
messages to all routers within the network in which it is configured.
This ensures multicast data packets reach all interested receivers
behind edge routers. Prune messages are used by routers to tell
upstream routers to (temporarily) stop forwarding multicast for
groups for which they have no known receivers.
PIM-DM remains an Experimental protocol since its publication in
2005.
4.2. Protocol Independent Multicast, Sparse Mode (PIM-SM)
The most recent revision of PIM-SM is detailed in [RFC7761]. PIM-SM
is, as the name suggests, was designed to be used in scenarios where
the subnets with receivers are sparsely distributed throughout the
network. PIM-SM supports any number of senders for a given multicast
group, which do not need to be known in advance, and which may come
and go through the session. PIM-SM does not use a flooding phase,
making it more scalable and efficient than PIM-DM, but this means
PIM-SM needs a mechanism to construct the multicast forwarding tree
(and associated forwarding tables in the routers) without flooding
the whole network.
To achieve this, PIM-SM introduces the concept of a Rendezvous Point
(RP) for a PIM domain. All routers in a PIM-SM domain are then
configured to use specific RP(s). Such configuration may be
performed by a variety of methods, including Anycast-RP [RFC4610].
A sending host's Designated Router encapsulates multicast packets to
the RP, and a receiving host's Designated Router can forward PIM JOIN
messages to the RP, in so doing forming what is known as the
Rendezvous Point Tree (RPT). Optimisation of the tree may then
happen once the receiving host's router is aware of the sender's IP,
and a source-specific JOIN message may be sent towards it, in so
doing forming the Shortest Path Tree (SPT). Unnecessary RPT paths
are removed after the SPT is established.
Abrahamsson, et al. Expires May 3, 2018 [Page 5]
Internet-Draft Deprecating Interdomain ASM October 2017
4.2.1. Interdomain PIM-SM, and MSDP
PIM-SM can in principle operate over any network in which the
cooperating routers are configured with RPs. But in general, PIM-SM
for a given domain will use an RP configured for that domain. There
is thus a challenge in enabling PIM-SM to work between multiple
domains, i.e. to allow an RP in one domain to learn the existence of
a source in another domain, such that a receiver's router in one
domain can know to forward a PIM JOIN towards a source's Designated
Router in another domain. The solution to this problem is to use an
inter-RP signalling protocol known as Multicast Source Discovery
Protocol (MSDP). [RFC3618].
Deployment scenarios for MSDP are given in [RFC4611]. MSDP remains
an Experimental protocol since its publication in 2003. MSDP was not
replicated for IPv6.
4.3. Bidirectional PIM (PIM-BIDIR)
PIM-BIDIR is detailed in [RFC5015]. In contrast to PIM-SM, it can
establish bi-directional multicast forwarding trees between multicast
sources and receivers.
4.4. IPv6 PIM-SM with Embedded RP
Within a single PIM domain, PIM-SM for IPv6 works largely the same as
it does for IPv4. However, the size of the IPv6 address (128 bits)
allows a different mechanism for multicast routers to determine the
RP for a given multicast group address. Embedded-RP [RFC3956]
specifies a method to embed the unicast RP IP address in an IPv6
multicast group address, allowing routers supporting the protocol to
determine the RP for the group without any prior configuration,
simply by observing the RP address that is embedded (included) in the
group address.
Embedded-RP allows PIM-SM operation across any IPv6 network in which
there is an end-to-end path of routers supporting the protocol. By
embedding the RP address in this way, multicast for a given group can
operate interdomain without the need for an explicit source discovery
protocol (i.e. without MSDP for IPv6). It would generally be
desirable that the RP would be located close to the sender(s) in the
group.
5. SSM service model protocols
Abrahamsson, et al. Expires May 3, 2018 [Page 6]
Internet-Draft Deprecating Interdomain ASM October 2017
5.1. Source Specific Multicast (PIM-SSM)
PIM-SSM is detailed in [RFC4607]. In contrast to PIM-SM, PIM-SSM
benefits from assuming that source(s) are known about in advance,
i.e. the source IP address is known (by some out of band mechanism),
and thus the receiver's router can send a PIM JOIN directly towards
the sender, without needing to use an RP.
IPv4 addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are
designated as source-specific multicast (SSM) destination addresses
and are reserved for use by source-specific applications and
protocols. For IPv6, the address prefix FF3x::/32 is reserved for
source-specific multicast use.
6. Discussion
In this section we discuss the applicability of the ASM and SSM
models described above, and their associated protocols, to a range of
deployment scenarios.
6.1. ASM Deployment
PIM-DM remains an Experimental protocol, that appears to be rarely
used in campus or enterprise environments.
In enterprise and campus scenarios, PIM-SM is in relatively common
use. The configuration and management of an RP ithin a single domain
is not onerous. However, if interworking with external PIM domains
in IPv4 multicast deployments is needed, MSDP is required to exchange
information between domain RPs about sources. MSDP remains an
Experimental protocol, and can be a complex and fragile protocol to
administer and troubleshoot. MSDP is also specific to IPv4; it was
not carried forward to IPv6, in no small part due to the complexity
of operation and troubleshooting.
PIM-SM is a general purpose protocol that can handle all use cases.
In particular, it was designed for cases where one or more sources
may came and go during a multicast session. For cases where a
single, persistent source is used, and receivers can be configured to
know of that source, PIM-SM has unnecessary complexity.
As stated above, MSDP was not taken forward to IPv6. Instead, IPv6
has Embedded-RP, which allows the RP address for a multicast group to
be embedded in the group address, making RP discovery automatic, if
all routers on the path between a receiver and a sender support the
protocol. Embedded-RP can support lightweight ad-hoc deployments.
However, it does rely on a single RP for an entire group. Embedded-
RP was run successfully between European and US academic networks
Abrahamsson, et al. Expires May 3, 2018 [Page 7]
Internet-Draft Deprecating Interdomain ASM October 2017
during the 6NET project in 2004/05. Its usage generally remains
constrained to academic networks.
BIDIR-PIM is designed, as the name suggests, for bidirectional use
cases.
6.2. SSM Deployment
As stated in RFC4607, SSM is particularly well-suited to
dissemination-style applications with one or more senders whose
identities are known (by some mechanism) before the application
starts running. PIM-SSM is therefore very well-suited to
applications such as classic linear broadcast TV over IP.
SSM requires hosts using it and (edge) routers with SSM receivers
support the new(er) IGMPv3 and MLDv2 protocols. While delayed
delivery of support in some OSes has meant that adoption of SSM has
also been slower than might have been expected, or hoped, support for
SSM is now widespread in common OSes.
7. Recomendation to deprecate ASM for interdomain use
This document recommends that the use of interdomain ASM is
deprecated. It also recommends the use of SSM for all multicast
scenarios.
7.1. Rationale
A significant benefit of SSM is its reduced complexity through
eliminating network-based source discovery. This means no RPs,
shared trees, SPT switchover, PIM registers, MSDP or data-driven
state creation. It is really just a small subset of PIM-SM, plus
IGMPv3.
This reduced complexity makes SSM radically simpler to manage,
troubleshoot and operate, particularly for network backbone
operators; this is the main motivation for the recommendation to
deprecate the use of ASM in interdomain scenarios. Interdomain ASM
is widely viewed as complicated and fragile. By eliminating network-
based source discovery for interdomain multicast, the vast majority
of the complexity issues go away.
RFC 4607 includes details some benefits of SSM, for example:
"Elimination of cross-delivery of traffic when two sources
simultaneously use the same source-specific destination address;
Abrahamsson, et al. Expires May 3, 2018 [Page 8]
Internet-Draft Deprecating Interdomain ASM October 2017
Avoidance of the need for inter-host coordination when choosing
source-specific addresses, as a consequence of the above;
Avoidance of many of the router protocols and algorithms that are
needed to provide the ASM service model."
Further discussion can also be found in [RFC3569].
SSM is considered more secure in that it supports access control,
i.e. you only get packets from the sources you explicitly ask for, as
opposed to ASM where anyone can decide to send traffic to a PIM-SM
group address. This topic is expanded upon in [RFC4609].
7.2. On deprecating interdomain ASM
The recommendation to deprecate the use of interdomain ASM applies to
the use of ASM between domains, where either MSDP (IPv4) or Embedded-
RP (IPv6) is required for sharing knowledge of remote sources.
If an organisation, or AS, wishes to use multiple multicast domains
within its own network border, that is a choice for that organisation
to make, and it may then use MSDP or Embedded-RP internally.
MSDP is an Experimental level standard; this document does not
propose making it Historic, given there may be such residual intra-
site use cases.
By implication, it is thus strongly recommended that SSM be the
multicast protocol of choice for interdomain multicast. Best current
practices for interdomain multicast using SSM are documented in
[I-D.ietf-mboned-interdomain-peering-bcp].
7.3. Intradomain ASM
The use of ASM within a single multicast domain, such as an
enterprise or campus, is relatively common today, typically with
anycast-RP or MSDP for RP resilience. This document does not
preclude continued use of ASM in this scenario.
However, it is strongly recommended that sites using ASM internally
conduct an audit of the multicast applications used, and begin
planning a migration to using SSM wherever possible.
7.4. IGMPv3/MLDv2 support
This document recommends that all host and router platforms
supporting multicast also support IGMPv3 and MLDv2. The updated IPv6
Node Requirements RFC states that MLDv2 support is a MUST in all
Abrahamsson, et al. Expires May 3, 2018 [Page 9]
Internet-Draft Deprecating Interdomain ASM October 2017
implementations [I-D.ietf-6man-rfc6434-bis]. Such support is now
widespread in all common platforms.
7.5. Addressing considerations
A key benefit of SSM is that the multicast application does not need
to be allocated a specific multicast group by the network, rather as
SSM is inherently source-specific, it can use any group address, G,
in the reserved range of IPv4 or IPv6 addresses for its own source
address, S.
In principle, if interdomain ASM is deprecated, backbone operators
could begin filtering the ranges of group addresses used by ASM. In
practice, this is not recommended given there will be a transition
period from ASM to SSM (as discussed further below) where some form
of ASM-SSM mappings may be used, and filtering may preclude such
operations.
7.6. Application considerations
There will be a wide range of applications today that only support
ASM, whether as software packages, or code embedded in devices such
as set top boxes.
It is often thought that ASM is required for multicast applications
where there are multiple sources. However, RFC4607 also describes
how SSM can be used instead of PIM-SM for multi-party applications:
"SSM can be used to build multi-source applications where all
participants' identities are not known in advance, but the multi-
source "rendezvous" functionality does not occur in the network
layer in this case. Just like in an application that uses unicast
as the underlying transport, this functionality can be implemented
by the application or by an application-layer library."
This, in theory, it should be possible to port ASM-only applications
to be able to run using SSM, if an appropriate out-of-band mechanism
can be chosen to convey the participant source addresses.
Given all common OSes support SSM, it is then down to the programming
language and APIs used as to whether the necessary SSM APIs are
available. SSM support is generally quite ubiquitous, with the
current excpetion of websockets used in web-browser based
applications.
It is desirable that applications also support appropriate congestion
control, as described in [RFC8085], with appropriate codecs, to
achieve the necessary rate adaption.
Abrahamsson, et al. Expires May 3, 2018 [Page 10]
Internet-Draft Deprecating Interdomain ASM October 2017
It is recommended that application developers choosing to use
multicast, develop and engineer their applications to use SSM rather
than ASM.
Some useful considerations for multicast applications can still be
found in the relatively old [RFC3170].
7.7. ASM/SSM transition - protocol mapping
In the case of existing ASM applications that cannot readily be
ported to SSM, it may be possible to use some form of protocol
mapping, i.e., to have a mechanism to translate a (*,G) join or leave
to a (S,G) join or leave, for a specifci source, S. The general
challenge in performing such mapping is determining where the
configured source address, S, comes from.
There are some existing vendor-specific mechanisms to achieve this
function, but none are documented in IETF standards. This may be an
area for the IETF to ork on, but it should be noted that any such
effort would only be an interim transition mechanism, and such
mappings do not remove the requirement for applications to be
allocated ASM group addresses for the communications.
It is generally considered better to work towards using SSM, and thus
pushing the source discovery problem from the network to the
application.
8. Conclusions
This document recommends that the use of interdomain ASM is
deprecated. It also recommends the use of SSM for all multicast
scenarios. Specific implications and considerations for the
recommendation are discussed.
9. Security Considerations
This document adds no new security considerations. RFC4609 describes
the additional security benefits of using SSM instead of ASM.
10. IANA Considerations
This document currently makes no request of IANA.
Note to RFC Editor: this section may be removed upon publication as
an RFC.
Abrahamsson, et al. Expires May 3, 2018 [Page 11]
Internet-Draft Deprecating Interdomain ASM October 2017
11. Acknowledgments
The authors would like to thank the following people for their
contributions to the document: Hitoshi Asaeda, Toerless Eckert, Jake
Holland, Mike McBride, Per Nihlen, Greg Shepherd, Stig Venaas, Nils
Warnke, and Sandy Zhang.
12. References
12.1. Normative References
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, DOI 10.17487/RFC1112, August 1989,
<https://www.rfc-editor.org/info/rfc1112>.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, DOI 10.17487/RFC2236, November 1997,
<https://www.rfc-editor.org/info/rfc2236>.
[RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address
Assignments", RFC 2375, DOI 10.17487/RFC2375, July 1998,
<https://www.rfc-editor.org/info/rfc2375>.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710,
DOI 10.17487/RFC2710, October 1999,
<https://www.rfc-editor.org/info/rfc2710>.
[RFC3170] Quinn, B. and K. Almeroth, "IP Multicast Applications:
Challenges and Solutions", RFC 3170, DOI 10.17487/RFC3170,
September 2001, <https://www.rfc-editor.org/info/rfc3170>.
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, DOI 10.17487/RFC3307, August 2002,
<https://www.rfc-editor.org/info/rfc3307>.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
<https://www.rfc-editor.org/info/rfc3376>.
[RFC3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific
Multicast (SSM)", RFC 3569, DOI 10.17487/RFC3569, July
2003, <https://www.rfc-editor.org/info/rfc3569>.
Abrahamsson, et al. Expires May 3, 2018 [Page 12]
Internet-Draft Deprecating Interdomain ASM October 2017
[RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source
Discovery Protocol (MSDP)", RFC 3618,
DOI 10.17487/RFC3618, October 2003,
<https://www.rfc-editor.org/info/rfc3618>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004,
<https://www.rfc-editor.org/info/rfc3810>.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address",
RFC 3956, DOI 10.17487/RFC3956, November 2004,
<https://www.rfc-editor.org/info/rfc3956>.
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol
Independent Multicast - Dense Mode (PIM-DM): Protocol
Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973,
January 2005, <https://www.rfc-editor.org/info/rfc3973>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
<https://www.rfc-editor.org/info/rfc4607>.
[RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol
Independent Multicast (PIM)", RFC 4610,
DOI 10.17487/RFC4610, August 2006,
<https://www.rfc-editor.org/info/rfc4610>.
[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>.
[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for
IPv4 Multicast Address Assignments", BCP 51, RFC 5771,
DOI 10.17487/RFC5771, March 2010,
<https://www.rfc-editor.org/info/rfc5771>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <https://www.rfc-editor.org/info/rfc7761>.
Abrahamsson, et al. Expires May 3, 2018 [Page 13]
Internet-Draft Deprecating Interdomain ASM October 2017
12.2. Informative References
[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006,
<https://www.rfc-editor.org/info/rfc4541>.
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for Source-
Specific Multicast", RFC 4604, DOI 10.17487/RFC4604,
August 2006, <https://www.rfc-editor.org/info/rfc4604>.
[RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol
Independent Multicast - Sparse Mode (PIM-SM) Multicast
Routing Security Issues and Enhancements", RFC 4609,
DOI 10.17487/RFC4609, October 2006,
<https://www.rfc-editor.org/info/rfc4609>.
[RFC4611] McBride, M., Meylor, J., and D. Meyer, "Multicast Source
Discovery Protocol (MSDP) Deployment Scenarios", BCP 121,
RFC 4611, DOI 10.17487/RFC4611, August 2006,
<https://www.rfc-editor.org/info/rfc4611>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[I-D.ietf-mboned-interdomain-peering-bcp]
Tarapore, P., Sayko, R., Shepherd, G., Eckert, T., and R.
Krishnan, "Use of Multicast Across Inter-Domain Peering
Points", draft-ietf-mboned-interdomain-peering-bcp-13
(work in progress), October 2017.
[I-D.ietf-6man-rfc6434-bis]
Chown, T., Loughney, J., and T. Winters, "IPv6 Node
Requirements", draft-ietf-6man-rfc6434-bis-02 (work in
progress), October 2017.
Authors' Addresses
Mikael Abrahamsson
T-Systems
Stockholm
Sweden
Email: mikael.abrahamsson@t-systems.se
Abrahamsson, et al. Expires May 3, 2018 [Page 14]
Internet-Draft Deprecating Interdomain ASM October 2017
Tim Chown
Jisc
Lumen House, Library Avenue
Harwell Oxford, Didcot OX11 0SG
United Kingdom
Email: tim.chown@jisc.ac.uk
Lenny Giuliano
Juniper Networks, Inc.
2251 Corporate Park Drive
Hemdon, Virginia 20171
United States
Email: lenny@juniper.net
Abrahamsson, et al. Expires May 3, 2018 [Page 15]