[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

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-02

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  . . . . . . . . . . . . . . . . . . .   5
   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 . . . . . . . . . . . . . . . . .   7
     5.1.  Source Specific Multicast (PIM-SSM) . . . . . . . . . . .   7
   6.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  ASM Deployment  . . . . . . . . . . . . . . . . . . . . .   7
     6.2.  SSM Deployment  . . . . . . . . . . . . . . . . . . . . .   8
   7.  Recommendations on ASM and SSM deployment . . . . . . . . . .   8
     7.1.  Rationale - advantages of SSM . . . . . . . . . . . . . .   8
     7.2.  On deprecating interdomain ASM  . . . . . . . . . . . . .   9
     7.3.  Intradomain ASM . . . . . . . . . . . . . . . . . . . . .   9
     7.4.  IGMPv3/MLDv2 support  . . . . . . . . . . . . . . . . . .  10
     7.5.  Multicast addressing considerations . . . . . . . . . . .  10
     7.6.  Application considerations  . . . . . . . . . . . . . . .  10
     7.7.  ASM/SSM transition - protocol mapping . . . . . . . . . .  11
   8.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  11
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  12
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     12.2.  Informative References . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

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 group 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 multicast group addresses (for either IPv4 or
   IPv6) is used for multicast group communication, as described in
   Section 3.1.

   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 on which
   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).  As per Section 9 of RFC5771, domains with a
   32-bit ASN MAY apply for space in AD-HOC Block III, or instead
   consider using IPv6 multicast addresses.

   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].







Abrahamsson, et al.        Expires May 3, 2018                  [Page 4]


Internet-Draft         Deprecating Interdomain ASM          October 2017


3.3.  Multicast snooping

   In some cases, it is desirable to limit the propagation of multicast
   messages in a layer 2 network, typically through a layer 2 switch
   device.  In such cases multicast snooping can be used, by which the
   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



Abrahamsson, et al.        Expires May 3, 2018                  [Page 5]


Internet-Draft         Deprecating Interdomain ASM          October 2017


   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.

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.




Abrahamsson, et al.        Expires May 3, 2018                  [Page 6]


Internet-Draft         Deprecating Interdomain ASM          October 2017


5.  SSM service model protocols

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 within 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.



Abrahamsson, et al.        Expires May 3, 2018                  [Page 7]


Internet-Draft         Deprecating Interdomain ASM          October 2017


   However, it does rely on a single RP for an entire group.  Embedded-
   RP was run successfully between European and US academic networks
   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.  Recommendations on ASM and SSM deployment

   This document recommends that the use of interdomain ASM is
   deprecated, i.e., only SSM is to be used for interdomain multicast.
   Further, it also strongly recommends the use of SSM for all multicast
   scenarios, be they run inter or intradomain.

7.1.  Rationale - advantages of SSM

   A significant benefit of SSM is its reduced complexity through
   eliminating the network-based source discovery required in ASM.  This
   means there are no RPs, shared trees, SPT switchover, PIM registers,
   MSDP or data-driven state creation elements to support.  SSM 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 benefits of SSM, for example:





Abrahamsson, et al.        Expires May 3, 2018                  [Page 8]


Internet-Draft         Deprecating Interdomain ASM          October 2017


      "Elimination of cross-delivery of traffic when two sources
      simultaneously use the same source-specific destination address;

      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 within
   its own network.

   MSDP is an Experimental level standard; this document does not
   propose making it Historic, given there may be such residual intra-
   organisation use cases.

   By implication, it is thus strongly recommended that SSM be the
   multicast protocol of choice for interdomain multicast.  Best current
   practices for deploying 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, with an RP for the site, is relatively common
   today.  The site may also choose to use Anycast-RP or MSDP for RP
   resilience, at the expense of the extra complexity in managing that
   configuration.  Regardless, this document does not preclude continued
   use of ASM in the intradomain 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 instead wherever possible.



Abrahamsson, et al.        Expires May 3, 2018                  [Page 9]


Internet-Draft         Deprecating Interdomain ASM          October 2017


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 [I-D.ietf-6man-rfc6434-bis] states that MLDv2
   support is a MUST in all implementations.  Such support is already
   widespread in common host and router platforms.

7.5.  Multicast 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 SSM 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 in Section 7.7, 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.

   The strong recommendation in this document for use of SSM means that
   applications should instead use SSM, should operate correctly in an
   SSM environment, and thus trigger IGMPv3/MLDv2 messages to signal use
   of SSM.

   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."

   Thus, 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.



Abrahamsson, et al.        Expires May 3, 2018                 [Page 10]


Internet-Draft         Deprecating Interdomain ASM          October 2017


   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 exception 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.

   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 specific 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 work 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.








Abrahamsson, et al.        Expires May 3, 2018                 [Page 11]


Internet-Draft         Deprecating Interdomain ASM          October 2017


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.

11.  Acknowledgments

   The authors would like to thank the following people for their
   contributions to the document: Hitoshi Asaeda, Dale Carder, 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>.




Abrahamsson, et al.        Expires May 3, 2018                 [Page 12]


Internet-Draft         Deprecating Interdomain ASM          October 2017


   [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>.

   [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>.





Abrahamsson, et al.        Expires May 3, 2018                 [Page 13]


Internet-Draft         Deprecating Interdomain ASM          October 2017


   [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>.

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.






Abrahamsson, et al.        Expires May 3, 2018                 [Page 14]


Internet-Draft         Deprecating Interdomain ASM          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


   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]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/