draft-acg-mboned-deprecate-interdomain-asm-00.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC1112 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1112.xml">
  <!ENTITY RFC2375 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2375.xml">
  <!ENTITY RFC3170 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3170.xml">
  <!ENTITY RFC3307 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3307.xml">
  <!ENTITY RFC3376 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3376.xml">
  <!ENTITY RFC3569 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3569.xml">
  <!ENTITY RFC3618 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3618.xml">
  <!ENTITY RFC3810 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3810.xml">
  <!ENTITY RFC3956 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3956.xml">
  <!ENTITY RFC3973 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3973.xml">
  <!ENTITY RFC4291 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml">
  <!ENTITY RFC4541 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4541.xml">
  <!ENTITY RFC4604 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4604.xml">
  <!ENTITY RFC4607 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4607.xml">
  <!ENTITY RFC4609 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4609.xml">
  <!ENTITY RFC4610 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4610.xml">
  <!ENTITY RFC4611 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4611.xml">
  <!ENTITY RFC5771 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5771.xml">
  <!ENTITY RFC7761 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7761.xml">
  <!ENTITY RFC8085 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml">
  <!ENTITY RFC8313 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8313.xml">
  <!ENTITY I-D.ietf-6man-rfc6434-bis SYSTEM
    "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6man-rfc6434-bis.xml">
]>

<!-- Use with the following tips & tools:
      http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html
      http://xml.resource.org/authoring/README.html OR
      http://xml.resource.org/authoring/README-dev.html
      http://xml.resource.org/ OR
      http://xml.resource.org/experimental.html
      http://fenron.net/~fenner/ietf/xml2rfc-valid/  link appears to be broken :(
      http://tools.ietf.org/tools/idnits/
      http://tools.ietf.org/rfcdiff
  -->

<!-- Then upload:
  https://datatracker.ietf.org/idst/upload.cgi
  -->

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
     please see http://xml.resource.org/authoring/README.html -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.35) -->

<!-- give errors regarding ID-nits and DTD validation -->
<?rfc strict="yes"?>

<!-- control the table of contents (ToC) -->
<!-- generate a ToC -->
<?rfc toc="yes"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<?rfc tocdepth="3"?>

<!-- control references -->
<!-- use anchors instead of numbers for refs, i.e, [RFC2119] instead of [1] -->
<?rfc symrefs="yes"?>
<!-- sort the reference entries alphabetically -->
<?rfc sortrefs="no" ?>

<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<!-- do not start each main section on a new page -->
<?rfc compact="yes" ?>
<!-- "no" to keep one blank line between list items (rfced) -->
<?rfc subcompact="no" ?>

<!-- encourage use of "xml2rfc" tool -->
<?rfc rfcprocack="yes" ?>
<!-- end of list of popular I-D processing instructions -->

<rfc category="bcp" ipr="trust200902" docName="draft-acg-mboned-deprecate-interdomain-asm-00">
  <front>
    <title abbrev="Deprecating Interdomain ASM">Deprecating ASM for Interdomain Multicast</title>

    <author fullname="Mikael Abrahamsson" initials="M." surname="Abrahamsson">
      <organization> T-Systems </organization>
      <address>
        <postal>
          <street> </street>
          <city> Stockholm </city>
          <country> Sweden </country>
        </postal>
        <email> mikael.abrahamsson@t-systems.se </email>
      </address>
    </author>

    <author fullname="Tim Chown" initials="T." surname="Chown">
      <organization> Jisc </organization>
      <address>
        <postal>
          <street> Lumen House, Library Avenue </street>
          <city> Harwell Oxford, Didcot</city>
          <code> OX11 0SG </code>
          <country> United Kingdom </country>
        </postal>
        <email> tim.chown@jisc.ac.uk </email>
      </address>
    </author>

    <author fullname="Lenny Giuliano" initials="L." surname="Giuliano">
      <organization> Juniper Networks, Inc. </organization>
      <address>
        <postal>
          <street> 2251 Corporate Park Drive </street>
          <city> Hemdon, Virginia</city>
          <code> 20171 </code>
          <country> United States </country>
        </postal>
        <email> lenny@juniper.net </email>
      </address>
    </author>

    <date month="March" year="2018"/>
    <area> Operations </area>
    <workgroup> Mboned </workgroup>

    <abstract>
      <t>
	This document recommends the deprecation of the use of
	Any-Source Multicast (ASM) for interdomain multicast. 
	It therefore implicitly recommends
	the use of Source-Specific Multicast (SSM) for interdomain 
	multicast applications, and that hosts and routers
	that are expected to handle such applications
	fully support SSM. The recommendations in this document do
	not preclude the continued use of ASM within a single 
	organisation or domain.
      </t>
    </abstract>

  </front>
  <middle>

    <section title="Introduction">
      <t>
	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, and in many cases
	revised over time, there has been no strong recommendation
	made on the appropriateness of those models to certain scenarios.
	This document addresses this gap by making a BCP-level
	recommendation to deprecate the use of ASM for interdomain 
	multicast, and thus implictly also that all hosts and
	routers that are expected to support such multicast applications
	fully support SSM.
      </t>
	<t>
	This document does not make any statement on the use of ASM
	within in a single domain or organisation, and therefore
	does not preclude its use. Indeed, there may
	be a number of application contexts for which ASM is currently
	still considered well-suited within a single domain.
	</t>
    </section>

    <section title="Multicast routing protocols">
	<t>
	The general IP multicast service model 
	<xref target="RFC1112"/> is that
	sender(s) send to a multicast group address, receivers express 
	an interest in traffic sent to a given multicast group address,
	and that routers use multicast routing protocols to 
	determine how to deliver traffic from the sender(s) to the receivers. 
	</t>
      	<t>
	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, and the multicast routing protocol facilitates 
	source discovery at the network layer.
	In contrast, with Source-Specific Multicast (SSM) the specific source(s)
	that may send traffic to the group are known in advance, 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). 
	</t>
      	<t>
	IANA has reserved specific ranges of IPv4 and IPv6 address
	space for multicast addressing.
	Guidelines for IPv4 multicast address assignments
	can be found in <xref target="RFC5771"/>, while
	guidelines for IPv6 multicast address assignments
	can be found in <xref target="RFC2375"/> and
	<xref target="RFC3307"/>.
	The IPv6 multicast address format is described
	in <xref target="RFC4291"/>. 
	</t>

	<section title="ASM routing protocols">

      	<t>
      	The most commonly deployed ASM routing protocol is Protocol Independent
	Multicast - Sparse Mode, or PIM-SM, as 
	detailed in <xref target="RFC7761"/>.
	PIM-SM, as the name suggests, was designed to be used in scenarios
	where the subnets with receivers are sparsely distributed throughout 
	the network. 
	Because it does not know sender addresses in advance,
	PIM-SM uses the concept of a Rendezvous Point (RP) to 'marry up' 
	senders and receivers, where all routers in a PIM-SM domain are 
	configured to use specific RP(s). 
	</t>
	<t>
	To enable 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, an inter-RP signalling protocol known
	as Multicast Source Discovery Protocol (MSDP)
	<xref target="RFC3618"/> is used.
	Deployment scenarios for MSDP are given in <xref target="RFC4611"/>.
	MSDP has remained an Experimental protocol since its publication in 	
	2003, and was not replicated or carried forward for IPv6.
	</t>
      	<t>
	In the absence of MSDP, a new mechanism,
	Embedded-RP <xref target="RFC3956"/>, was defined for IPv6 PIM-SM, 
	which allows 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 IPv6 multicast group address.
	Embedded-RP allows PIM-SM operation across any IPv6 network in
	which there is an end-to-end path of routers supporting the
	protocol. 
	</t>

	</section>

      	<section title="SSM Routing protocols">
      	<t>
      	PIM-SSM is detailed in <xref target="RFC4607"/>. In contrast
	to PIM-SM, PIM-SSM benefits from sender source address(es)
	being known about in advance, i.e. a given source's 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.
      	</t>
	<t>
	IPv4 addresses in the 232/8 (232.0.0.0 to
   	232.255.255.255) range are designated as source-specific multicast
   	(SSM) destination addresses and are reserved for use by 
	source-specific applications and protocols.  
	For IPv6, the address prefix 
	FF3x::/32 is reserved for source-specific multicast use.
	</t>
      	</section>

    </section>

    <section title="Discussion">

      <section title="Observations on ASM and SSM deployments">

	<t>
	In enterprise and campus scenarios, ASM in the form of PIM-SM is 
	in relatively common use, and has generally replaced PIM-DM 
	<xref target="RFC3973"/>.  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. 
	</t>

	<t>
	PIM-SM is a general purpose protocol that can handle all
	use cases. In particular, it was designed for cases such as
	videoconferencing where multiple sources may come and go 
	during a multicast
	session. But for cases where a single, persistent source is
	used, and receivers can be configured to know of that source,
	PIM-SM has unnecessary complexity.
	</t>

	<t>
	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 relies
	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.
	</t>

	<t>
	As stated in RFC 4607, SSM is particularly well-suited to 
	dissemination-style applications with one or more senders 
	whose identities are known (by some mechanism) before the 
	application starts running. PIM-SSM is therefore very well-suited
	to applications such as classic linear broadcast TV over IP.
	</t>

	<t>
	SSM requires hosts and their subnet routers using it 
	support the new(er) IGMPv3 <xref target="RFC3376"/> and 
	MLDv2 <xref target="RFC3810"/> 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, and was a historical reason to use
	ASM rather than SSM, support for IGMPv3 and MLDv2 is now 
	widespread in common OSes.
	</t>

      </section>

      <section title="Advantages of SSM for interdomain multicast">

	<t>
	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, Shortest Path Tree (SPT) switchovers, PIM registers, 
	MSDP or data-driven 
	state creation elements to support. SSM is really just a small 
	subset of PIM-SM, plus IGMPv3 / MLDv2.  
	</t>

	<t>
	This reduced complexity makes SSM radically simpler to manage, 
	troubleshoot and operate, particularly for network backbone
	operators, and 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.
	</t>

	<t>
	RFC 4607 details many benefits of SSM, including:

	<list style="empty">
	<t>"Elimination of cross-delivery of traffic when two sources
      	simultaneously use the same source-specific destination address;</t>
	
      	<t>Avoidance of the need for inter-host coordination when choosing
      	source-specific addresses, as a consequence of the above;</t>
	
      	<t>Avoidance of many of the router protocols and algorithms that are
      	needed to provide the ASM service model."</t>
	</list>
	</t>

	<t>
	Further discussion can also be found in <xref target="RFC3569"/>.
	</t>

	<t>
	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
	<xref target="RFC4609"/>.
	</t>

      </section>



    </section>

    <section title="Recommendations">

      <section title="Deprecating use of ASM for interdomain multicast">
	<t>
	This document recommends that the use of ASM is deprecated
	for interdomain multicast, and thus implictly that hosts and
	routers that are expected to support such interdomain applications
	fully support SSM.
	Best current practices for deploying interdomain multicast using SSM
	are documented in <xref target="RFC8313"/>
	</t>
	<t>
	The recommendation applies to the use of ASM between domains where 
	either MSDP (IPv4) or Embedded-RP (IPv6) is required for sharing
	knowledge of remote sources.  It also recommends against the 
	multi-domain use of an ASM group with a single RP in one domain, 
	where multicast tunnels are used between domains.
	</t>
	<t>While MSDP is an Experimental level standard, this document does
	not propose making MSDP Historic, given its use may be desirable
	for intradomain multicast use cases.
	</t>
      </section>

      <section title="Including network support for IGMPv3 / MLDv2">
	<t>
	This document recommends that all host and router platforms supporting
	multicast, and any security appliances that may handle multicat traffic, 
	support IGMPv3 <xref target="RFC3376"/> and MLDv2 <xref target="RFC3810"/>.
	The updated IPv6 Node Requirements RFC <xref target="I-D.ietf-6man-rfc6434-bis"/>
	states that MLDv2 support is a MUST in all implementations.
	Such support is already widespread in common host and router platforms.
	</t>
	<t>
	Further guidance on IGMPv3 and MLDv2 is given in
	<xref target="RFC4604"/>.
	</t>
     	<t>
        It is sometimes 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. Such snooping
	capability should support IGMPv3 and MLDv2.
        There is further discussion in <xref target="RFC4541"/>.
        </t>
      </section>

      <section title="Building application support for SSM">
	<t>
	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.
	</t>
	<t>
	The implicit recommendation to use SSM for interdomain multicast means that 
	applications should use SSM, and operate correctly in an SSM 
	environment, triggering IGMPv3/MLDv2 messages to signal use of SSM.
	</t>
	<t>
	It is often thought that ASM is required for multicast applications
	where there are multiple sources. However,
	RFC 4607 also describes how SSM can be used instead of PIM-SM
	for multi-party applications:
	</t>
	<t>
	<list style="empty">
	<t>"SSM can be used to
   	build multi-source applications where all participants' identities
   	are not known in advance, but the multi-source "rendezvous"
   	functionality does not occur in the network layer in this case.  Just
   	like in an application that uses unicast as the underlying transport,
   	this functionality can be implemented by the application or by an
   	application-layer library."
	</t>
	</list>
	</t>
	<t>
	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.
	</t>
	<t>
	It is desirable that applications also support appropriate congestion
	control, as described in <xref target="RFC8085"/>, with appropriate
	codecs, to achieve the necessary rate adaption.
	</t>
	<t>
	Some useful considerations for multicast applications can still be found
	in the relatively old <xref target="RFC3170"/>.
      	</t>
      </section>
	
      <section title="Standardising an ASM/SSM protocol mapping mechanism">
	<t>
	In the case of existing ASM applications that cannot readily be ported to SSM,
	it may be possible to use some form of protocol mapping, i.e., to have a 
	mechanism to translate a (*,G) join or leave to a (S,G) join or leave, for 
	a specific source, S.  The general challenge in performing such mapping is 
	determining where the configured source address, S, comes from.
	</t>
	<t>
	There are some existing vendor-specific mechanisms to achieve this function,
	but none are documented in IETF standards.  This appears ti be a useful 
	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.
	</t>
      </section>

      <section title="Not filtering ASM addressing between domains">
	<t>
	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.
	</t>
      	<t>
	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, where some form of ASM-SSM mappings 
	may be used, and filtering may preclude such operations.
	</t>
      </section>

      <section title="Not precluding Intradomain ASM">
      	<t>
	The use of ASM within a single multicast domain, such as an
	enterprise or campus, with an RP for the site, is still relatively 
	common today. The operators of such a site may choose to use 	
	Anycast-RP <xref target="RFC4610"/> or MSDP for internal RP 
	resilience, at the expense of the extra complexity in managing that
	configuration.  
	</t>
	<t>
	This document does not preclude continued use of ASM in
	the intradomain scenario.
	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.
	</t>
      </section>

    </section>


    <section title="Security Considerations">
      <t>
	This document adds no new security considerations.
	RFC 4609 describes the additional security benefits of using
	SSM instead of ASM.
      </t>

    </section>

    <section title="IANA Considerations">
      <t>This document makes no request of IANA.</t>
      <t>Note to RFC Editor: this section may be removed upon publication as an RFC.</t>
    </section>

    <section title="Acknowledgments">
      <t>
	The authors would like to thank members of the IETF mboned WG for discussions on the
	content of this document, with specific thanks to the following people for their 
	contributions to the document:
	Hitoshi Asaeda,
	Dale Carder,
	Toerless Eckert,
	Jake Holland,
	Albert Manfredi,
	Mike McBride,
	Per Nihlen,
	Greg Shepherd,
	James Stevens,
	Stig Venaas,
	Nils Warnke,
	and
	Sandy Zhang.
      </t>
    </section>
  </middle>
  <back>

    <references title="Normative References">
	&RFC1112;
	&RFC2375;
	&RFC3170;
	&RFC3307;
      	&RFC3376;
      	&RFC3569;
	&RFC3618;
	&RFC3810;
	&RFC3956;
	&RFC3973;
	&RFC4291;
	&RFC4607;
	&RFC4610;
	&RFC5771;
      	&RFC7761;
    </references>

    <references title="Informative References">
	&RFC4541;
	&RFC4604;
	&RFC4609;
	&RFC4611;
	&RFC8085;
	&RFC8313;
      &I-D.ietf-6man-rfc6434-bis;

    </references>
  </back>
</rfc>