<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.17 (Ruby 3.0.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-giuliano-treedn-00" category="info" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.14.2 -->
  <front>
    <title abbrev="TreeDN">TreeDN- Tree-based CDNs for Live Streaming to Mass Audiences</title>
    <seriesInfo name="Internet-Draft" value="draft-giuliano-treedn-00"/>
    <author initials="L." surname="Giuliano" fullname="Lenny Giuliano">
      <organization>Juniper Networks</organization>
      <address>
        <postal>
          <street>2251 Corporate Park Drive</street>
          <city>Herndon</city>
          <code>20171</code>
          <country>USA</country>
        </postal>
        <email>lenny@juniper.net</email>
      </address>
    </author>
    <date year="2022" month="September" day="07"/>
    <area>Ops</area>
    <workgroup>mboned</workgroup>
    <keyword>multicast, SSM, AMT, LISP, CDN, PIM-SSM</keyword>
    <abstract>
      <t>As Internet audience sizes for high-interest live events reach unprecedented levels and bitrates climb to support 4K/8K/AR, live streaming can place a unique type of stress upon network resources.  TreeDN is a tree-based CDN architecture designed to address the distinctive scaling challenges of live streaming to mass audiences.  TreeDN enables operators to offer Replication-as-a-Service (RaaS) at a fraction the cost of traditional, unicast-based CDNs- in some cases, at no additional cost to the infrastructure.  In addition to efficiently utilizing network resources to deliver existing multi-destination traffic, this architecture also enables new types of content and use cases that previously weren't possible or economically viable using traditional CDN approaches.  Finally, TreeDN is a decentralized architecture and a democratizing technology for content distribution.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <t>Live streaming to mass audiences can impose unique demands on network resources.  For example, live sporting events broadcast over the Internet to end users has much lower tolerance for long playout buffers than typical on-demand video streaming.  Viewers of live sporting events have long been conditioned by broadcast television to expect to see the content in real time, with only very short buffers for broadcast delays to prevent profanity and other objectionable content from making on the air (the "seven-second delay").  With in-game betting, even this 5-10 second delay can be too long. By comparison, when watching on-demand movies, an extra one- or two-minute playout buffer tends to be perfectly acceptable for viewers.  If playout buffers for live sports are that long, viewers run the risk of being alerted to the game winning score from text messages from friends or cheers from the bar across the street, minutes before they view it themselves.</t>
      <t>Another unique characteristic of live streaming is join rate.  While on-demand video streaming can consume massive amounts of network resources, the viewing rates tend to be smooth and predictable.  Service Providers observe gradual levels of traffic increases over the evening hours corresponding to prime-time viewing habits.  By comparison, viewing rates of live video streams can more closely resemble step functions with much less predictability as mass audiences of viewers tune in to watch the game at the same time.</t>
      <t>Previous efforts at more efficient network replication of multi-destination traffic have experienced mixed success in terms of adoption.  IP multicast is widely deployed on financial networks, video distribution networks, L3VPN networks and certain enterprises.  But most of these deployments are restricted to "walled-garden" networks.  Multicast over the global Internet has failed to gain traction, as only a very small portion of the Internet is multicast-enabled at this time.</t>
      <t>TreeDN is the result of the evolution of network-based replication mechanisms based on lessons learned from what has and has not worked well in the past.  TreeDN addresses the fundamental issues of what has hindered multicast from adoption on the global Internet and enables service providers the opportunity to deliver new Replication-as-a-Service (RaaS) offerings to content providers, while more efficiently utilizing network resources, and thus, improving the experience of end users.  Further, by more efficiently supporting multi-destination traffic, TreeDN is an architecture that can enable new types of content, such as Augmented Reality (AR) live streaming to mass audiences, that previously weren't possible or economically viable on the Internet due to the inefficiencies of unicast.</t>
      <section anchor="requirements-language">
        <name>Requirements Language</name>
        <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
      </section>
    </section>
    <section anchor="applicability">
      <name>Applicability</name>
      <t>While the primary use case mentioned throughout this document is live streaming of multimedia content (audio, video, AR, real-time telemetry data), the TreeDN architecture is ideal for any content that needs to be replicated and delivered to multiple destinations.  For example, large software file updates (eg, OS upgrades) that need to be delivered to many end users in a very short window of time can cause significant strain on network resources.  Using TreeDN, this use case be handled much more efficiently by the network.</t>
    </section>
    <section anchor="problem-statement">
      <name>Problem Statement</name>
      <t>The following issues have been the primary challenges for deployment of IP multicast over the global Internet:</t>
      <ul spacing="normal">
        <li>The "All or Nothing" Problem: IP multicast requires every layer 3 hop between source and receivers to be multicast-enabled.  To achieve ubiquitous availability on the global Internet, this essentially means nearly every interface on every router and firewall on the Internet must support a multicast routing protocol like PIM-SM <xref target="RFC7761"/> or mLDP <xref target="RFC6388"/>.  This requirement creates a bar to deployment that is practically impossible to overcome.</li>
        <li>The "It's Too Complex" Problem: operators have long complained that multicast routing protocols like PIM-SM are simply too complex, making it costly to design, configure, manage and troubleshoot IP multicast in the network.</li>
        <li>The "Chicken and Egg" Problem: there's not much multicast content because there's not much of a multicast-enabled audience, but there's not much of a multicast-enabled audience because there's not much multicast content.</li>
      </ul>
      <t>TreeDN is the evolution of network-based replication based on lessons learned over decades and is designed to address the problems listed above.</t>
    </section>
    <section anchor="treedn-architecture">
      <name>TreeDN Architecture</name>
      <t>TreeDN leverages advances in the availability and understanding of overlay and underlay networking.  With network overlays, a service can be achieved and delivered to end users while recognizing and tolerating the practical realities of what is possible over a network as diverse as the global Internet.  That is, the replication service is available to users and applications regardless of what protocols may exist in the underlying networks.</t>
      <section anchor="treedn-overlays">
        <name>TreeDN Overlays</name>
        <t>One overlay technology that TreeDN leverages is Automatic Multicast Tunneling (AMT) <xref target="RFC7450"/>.  With AMT, users on unicast-only networks can dynamically build tunnels to routers on the multicast-enabled part of the network and join multicast streams.  This allows any end host on the Internet to receive multicast content regardless of whether their local provider supports multicast, which addresses the "All or Nothing" Problem.  Links and devices that do not support multicast are simply tunneled over- they no longer present a barrier to the overall replication service for end users.  Those networks that do deploy and support multicast, as well as the content providers that serve up multicast content, are able to enjoy the benefits of efficient replication and delivery.  Further, these benefits can serve as incentives for operators who do not yet support multicast to enable it on their networks.  Once the cost of carrying duplicated unicast tunnels is perceived by those operators to exceed the cost of deploying multicast, they are more likely to enable multicast on their networks.  In this way, TreeDN effectively supports incremental deployment in a way that was not previously possible with traditional (non-overlay) multicast networking.  Finally, AMT also addresses the "Chicken and Egg" Problem, as all end hosts on the global Internet that have access to an AMT Relay are potential audience members.</t>
        <t>In addition to AMT, other overlay technologies like Locator/ID Separation Protocol (LISP) <xref target="RFC6830"/> can be utilized to deliver content from multicast-enabled networks to end hosts that are separated by portions of the network (at the last/middle/first mile) that do not support multicast.</t>
      </section>
      <section anchor="treedn-underlay">
        <name>TreeDN Underlay</name>
        <t>Networks that support multicast provide the "underlay" component of TreeDN.  The primary requirement of the underlay is to support Source-Specific Multicast (SSM) <xref target="RFC4607"/>.  PIM-SSM, which is merely a subset of PIM-SM, is the multicast routing protocol typically used in SSM.  However, any multicast routing protocol capable of supporting SSM can be used as a TreeDN underlay, such as mLDP, GTM <xref target="RFC7716"/> and BGP-based Multicast <xref target="I-D.ietf-bess-bgp-multicast"/>.  Likewise, any data plane technology that supports SSM, including BIER <xref target="RFC8279"/>, can be used.</t>
        <t>The key benefit of SSM as the underlay component of TreeDN is that it radically simplifies the control plane needed to support replication in the network.  This benefit addresses the "It's Too Complex" Problem.  Most of the complexity of multicast is eliminated in SSM, which reduces the cost of deploying and operating a multicast network.  Further rationale for this SSM-only approach can be found in ASM Deprecation <xref target="RFC8815"/>.</t>
      </section>
    </section>
    <section anchor="replication-as-a-service-raas">
      <name>Replication-as-a-Service (RaaS)</name>
      <t>Content providers have traditionally used CDNs to distribute content that needs to be delivered to large audiences, essentially outsourcing the task of replication to CDN providers.  Most CDNs utilize unicast delivery, as multicast is not an option due to its lack of general availability on the global Internet.  TreeDN is an alternate CDN architecture that leverages tree-based replication to more efficiently utilize network resources to deliver multi-destination traffic.  By leveraging overlay networking to address the "All or Nothing" and "Chicken and Egg" Problems and SSM to address the "It's Too Complex" Problem, TreeDN avoids the practical issues that previously prevented multicast from being a viable option for CDN providers.</t>
      <t>TreeDN has several advantages over traditional unicast-based CDN approaches.  First, the TreeDN functionality can be delivered entirely by the existing network infrastructure.  Specifically, for operators with routers that support AMT natively, multicast traffic can be delivered directly to end users without the need for specialized CDN devices, which typically are servers that need to be racked, powered and connected to revenue-generating ports on routers.  In this way, SPs can offer new RaaS functionality to content providers at potentially zero additional cost in new equipment (modulo the additional bandwidth consumption).</t>
      <t>Additionally, TreeDN is an open, standards-based architecture based on mature, widely implemented protocols.  TreeDN also requires far less coordination between the content provider and the CDN operator.  That is, there are no storage requirements for the data, nor group-key management issues since a TreeDN provider merely forwards packets.  A TreeDN provider simply needs to have enough accounting data (eg, traffic data, number of AMT tunnels, etc) to properly bill customers for the service.  By contrast, traditional unicast-based CDNs often incorporate proprietary, non-interoperable technologies and require significant coordination between the content provider and the CDN to handle such things as file storage, data protection and key-management.</t>
    </section>
    <section anchor="decentralizationdemocratization-of-content-sourcing">
      <name>Decentralization/Democratization of Content Sourcing</name>
      <t>TreeDN is an inherently decentralized architecture.  This reduces the cost for content sourcing, as any host connected to a multicast-enabled network, or on a source-capable overlay, can send out a single data stream that can be reached by an arbitrarily large audience.  By effectively reducing to zero the marginal cost to the source of reaching each additional audience member, TreeDN democratizes content sourcing on the Internet.</t>
    </section>
    <section anchor="integration-with-unicast">
      <name>Integration with Unicast</name>
      <t>Since SSM inherently implies unidirectional traffic flows from one to many, mechanisms that rely on bidirectional communication between receivers and the content provider, such as bespoke advertising, telemetry data from receivers detailing end user experience, distribution of decryption keys, switching to higher/lower bandwidth streams, etc, are not well suited to SSM delivery.  As such, separate unicast streams between receivers and content providers may be used for this type of "out-of-band" functions while SSM is used to deliver the actual content of interest.  Further details on this hybrid unicast-multicast model for content delivery are beyond the scope of this document.</t>
    </section>
    <section anchor="security-consideration">
      <name>Security Consideration</name>
      <t>TreeDN is essentially the synthesis of SSM plus overlay networking technologies like AMT.  As such, the TreeDN architecture introduces no new security threats that aren't already documented in SSM and the overlay technologies that comprise it.  Further, RFC 4609 and RFC 8815 describes the additional security benefits of using SSM instead of ASM.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
    <section anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>Many thanks to those who have contributed to building and operating the first TreeDN network on the Internet, including Pete Morasca, William Zhang, Lauren Delwiche, Natalie Landsberg, Wayne Brassem, Jake Holland, Andrew Gallo, Casey Russell, Janus Varmarken, Csaba Mate, Frederic Loui, Max Franke, Todor Moskov and Erik Herz.  The writing of this document to describe the TreeDN architecture was inspired by a conversation with Dino Farinacci and Mike McBride.  Thanks also to Jeff Haas for his thoughtful review and suggestions.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized.  This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="RFC7761" target="https://www.rfc-editor.org/info/rfc7761" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7761.xml">
          <front>
            <title>Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)</title>
            <author fullname="B. Fenner" initials="B." surname="Fenner"/>
            <author fullname="M. Handley" initials="M." surname="Handley"/>
            <author fullname="H. Holbrook" initials="H." surname="Holbrook"/>
            <author fullname="I. Kouvelas" initials="I." surname="Kouvelas"/>
            <author fullname="R. Parekh" initials="R." surname="Parekh"/>
            <author fullname="Z. Zhang" initials="Z." surname="Zhang"/>
            <author fullname="L. Zheng" initials="L." surname="Zheng"/>
            <date month="March" year="2016"/>
            <abstract>
              <t>This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and it optionally creates shortest-path trees per source.</t>
              <t>This document obsoletes RFC 4601 by replacing it, addresses the errata filed against it, removes the optional (*,*,RP), PIM Multicast Border Router features and authentication using IPsec that lack sufficient deployment experience (see Appendix A), and moves the PIM specification to Internet Standard.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="83"/>
          <seriesInfo name="RFC" value="7761"/>
          <seriesInfo name="DOI" value="10.17487/RFC7761"/>
        </reference>
        <reference anchor="RFC6388" target="https://www.rfc-editor.org/info/rfc6388" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6388.xml">
          <front>
            <title>Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths</title>
            <author fullname="IJ. Wijnands" initials="IJ." role="editor" surname="Wijnands"/>
            <author fullname="I. Minei" initials="I." role="editor" surname="Minei"/>
            <author fullname="K. Kompella" initials="K." surname="Kompella"/>
            <author fullname="B. Thomas" initials="B." surname="Thomas"/>
            <date month="November" year="2011"/>
            <abstract>
              <t>This document describes extensions to the Label Distribution Protocol (LDP) for the setup of point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) Label Switched Paths (LSPs) in MPLS networks.  These extensions are also referred to as multipoint LDP.  Multipoint LDP constructs the P2MP or MP2MP LSPs without interacting with or relying upon any other multicast tree construction protocol.  Protocol elements and procedures for this solution are described for building such LSPs in a receiver-initiated manner.  There can be various applications for multipoint LSPs, for example IP multicast or support for multicast in BGP/MPLS Layer 3 Virtual Private Networks (L3VPNs).  Specification of how such applications can use an LDP signaled multipoint LSP is outside the scope of this document. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6388"/>
          <seriesInfo name="DOI" value="10.17487/RFC6388"/>
        </reference>
        <reference anchor="RFC7450" target="https://www.rfc-editor.org/info/rfc7450" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7450.xml">
          <front>
            <title>Automatic Multicast Tunneling</title>
            <author fullname="G. Bumgardner" initials="G." surname="Bumgardner"/>
            <date month="February" year="2015"/>
            <abstract>
              <t>This document describes Automatic Multicast Tunneling (AMT), a protocol for delivering multicast traffic from sources in a multicast-enabled network to receivers that lack multicast connectivity to the source network. The protocol uses UDP encapsulation and unicast replication to provide this functionality.</t>
              <t>The AMT protocol is specifically designed to support rapid deployment by requiring minimal changes to existing network infrastructure.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7450"/>
          <seriesInfo name="DOI" value="10.17487/RFC7450"/>
        </reference>
        <reference anchor="RFC6830" target="https://www.rfc-editor.org/info/rfc6830" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6830.xml">
          <front>
            <title>The Locator/ID Separation Protocol (LISP)</title>
            <author fullname="D. Farinacci" initials="D." surname="Farinacci"/>
            <author fullname="V. Fuller" initials="V." surname="Fuller"/>
            <author fullname="D. Meyer" initials="D." surname="Meyer"/>
            <author fullname="D. Lewis" initials="D." surname="Lewis"/>
            <date month="January" year="2013"/>
            <abstract>
              <t>This document describes a network-layer-based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. The Locator/ID Separation Protocol (LISP) can be incrementally deployed, without a "flag day", and offers Traffic Engineering, multihoming, and mobility benefits to early adopters, even when there are relatively few LISP-capable sites.</t>
              <t>Design and development of LISP was largely motivated by the problem statement produced by the October 2006 IAB Routing and Addressing Workshop. This document defines an Experimental Protocol for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6830"/>
          <seriesInfo name="DOI" value="10.17487/RFC6830"/>
        </reference>
        <reference anchor="RFC4607" target="https://www.rfc-editor.org/info/rfc4607" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4607.xml">
          <front>
            <title>Source-Specific Multicast for IP</title>
            <author fullname="H. Holbrook" initials="H." surname="Holbrook"/>
            <author fullname="B. Cain" initials="B." surname="Cain"/>
            <date month="August" year="2006"/>
            <abstract>
              <t>IP version 4 (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 IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-specific multicast use.  This document defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this extension. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4607"/>
          <seriesInfo name="DOI" value="10.17487/RFC4607"/>
        </reference>
        <reference anchor="RFC7716" target="https://www.rfc-editor.org/info/rfc7716" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7716.xml">
          <front>
            <title>Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures</title>
            <author fullname="J. Zhang" initials="J." surname="Zhang"/>
            <author fullname="L. Giuliano" initials="L." surname="Giuliano"/>
            <author fullname="E. Rosen" initials="E." role="editor" surname="Rosen"/>
            <author fullname="K. Subramanian" initials="K." surname="Subramanian"/>
            <author fullname="D. Pacella" initials="D." surname="Pacella"/>
            <date month="December" year="2015"/>
            <abstract>
              <t>RFCs 6513, 6514, and others describe protocols and procedures that a Service Provider (SP) may deploy in order to offer Multicast Virtual Private Network (Multicast VPN or MVPN) service to its customers.  Some of these procedures use BGP to distribute VPN-specific multicast routing information across a backbone network.  With a small number of relatively minor modifications, the same BGP procedures can also be used to distribute multicast routing information that is not specific to any VPN.  Multicast that is outside the context of a VPN is known as "Global Table Multicast", or sometimes simply as "Internet multicast".  In this document, we describe the modifications that are needed to use the BGP-MVPN procedures for Global Table Multicast.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7716"/>
          <seriesInfo name="DOI" value="10.17487/RFC7716"/>
        </reference>
        <reference anchor="I-D.ietf-bess-bgp-multicast" target="https://www.ietf.org/archive/id/draft-ietf-bess-bgp-multicast-04.txt" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-bess-bgp-multicast.xml">
          <front>
            <title>BGP Based Multicast</title>
            <author fullname="Zhaohui Zhang">
              <organization>Juniper Networks</organization>
            </author>
            <author fullname="Lenny Giuliano">
              <organization>Juniper Networks</organization>
            </author>
            <author fullname="Keyur Patel">
              <organization>Arrcus</organization>
            </author>
            <author fullname="IJsbrand Wijnands">
              <organization>Cisco Systems</organization>
            </author>
            <author fullname="Mankamana Mishra">
              <organization>Cisco Systems</organization>
            </author>
            <author fullname="Arkadiy Gulko">
              <organization>Refinitiv</organization>
            </author>
            <date day="7" month="January" year="2022"/>
            <abstract>
              <t>This document specifies a BGP address family and related procedures that allow BGP to be used for setting up multicast distribution trees. This document also specifies procedures that enable BGP to be used for multicast source discovery, and for showing interest in receiving particular multicast flows. Taken together, these procedures allow BGP to be used as a replacement for other multicast routing protocols, such as PIM or mLDP. The BGP procedures specified here are based on the BGP multicast procedures that were originally designed for use by providers of Multicast Virtual Private Network service. This document also describes how various signaling mechanisms can be used to set up end-to-end inter-region multiast trees.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-bess-bgp-multicast-04"/>
        </reference>
        <reference anchor="RFC8279" target="https://www.rfc-editor.org/info/rfc8279" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8279.xml">
          <front>
            <title>Multicast Using Bit Index Explicit Replication (BIER)</title>
            <author fullname="IJ. Wijnands" initials="IJ." role="editor" surname="Wijnands"/>
            <author fullname="E. Rosen" initials="E." role="editor" surname="Rosen"/>
            <author fullname="A. Dolganow" initials="A." surname="Dolganow"/>
            <author fullname="T. Przygienda" initials="T." surname="Przygienda"/>
            <author fullname="S. Aldrin" initials="S." surname="Aldrin"/>
            <date month="November" year="2017"/>
            <abstract>
              <t>This document specifies a new architecture for the forwarding of multicast data packets.  It provides optimal forwarding of multicast packets through a "multicast domain".  However, it does not require a protocol for explicitly building multicast distribution trees, nor does it require intermediate nodes to maintain any per-flow state.  This architecture is known as "Bit Index Explicit Replication" (BIER).  When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent.  The ingress router then encapsulates the packet in a BIER header.  The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header.  The procedures for forwarding a packet based on its BIER header are specified in this document.  Elimination of the per-flow state and the explicit tree-building protocols results in a considerable simplification.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8279"/>
          <seriesInfo name="DOI" value="10.17487/RFC8279"/>
        </reference>
        <reference anchor="RFC8815" target="https://www.rfc-editor.org/info/rfc8815" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8815.xml">
          <front>
            <title>Deprecating Any-Source Multicast (ASM) for Interdomain Multicast</title>
            <author fullname="M. Abrahamsson" initials="M." surname="Abrahamsson"/>
            <author fullname="T. Chown" initials="T." surname="Chown"/>
            <author fullname="L. Giuliano" initials="L." surname="Giuliano"/>
            <author fullname="T. Eckert" initials="T." surname="Eckert"/>
            <date month="August" year="2020"/>
            <abstract>
              <t>This document recommends deprecation of the use of Any-Source Multicast (ASM) for interdomain multicast.  It recommends the use of Source-Specific Multicast (SSM) for interdomain multicast applications and recommends that hosts and routers in these deployments fully support SSM.  The recommendations in this document do not preclude the continued use of ASM within a single organization or domain and are especially easy to adopt in existing deployments of intradomain ASM using PIM Sparse Mode (PIM-SM).</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="229"/>
          <seriesInfo name="RFC" value="8815"/>
          <seriesInfo name="DOI" value="10.17487/RFC8815"/>
        </reference>
      </references>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA51b/44bN5L+X0DegTf5Y8cHyfY4ju0MDncne5J4sjPjudE4
wd5icaC6KYmZ7qa22T2ysjCQ11hgF9hnuUfJk9xXVSS7W9LYd/eHbanVJIv1
46uvivRkMhk1tinMqbqtjTm7mvC/k7n2Jldvzq68WrhaXdh7o2ZNbXRpq6Vq
nLrU3qtpm1tTZcaP9Hxem/s4ySh3WaVLTJrXetFMlrYtrK7cBDOYvJo8fTrK
dGOWrt6eKlst3Miu61PV1K1vnj19+s3TZyONtU7Vu7UfbVx9t6xduz5V5dxV
Jh/dmS0e5vjeFo3NtG/Gaja7HKvp5e1YXZzPrsck+lhdn19O8MNopNtm5erT
kVIT/FFY05+qi8fq+yAYPxSJL0xVbYc/uHp5qn5oK7s2tboyDUnk+RdPG2pO
1bNnX5+oN65euxr7Ute6vlNnNZTGb2W2wT7fmrrKXSVPXI6lnj09eXkSvrdV
Q8p4P5vyA1NqW5yqgoT5959l6ceVaUajkW90lf+XLqCKUwUJ1/ZU/bFx2Vh5
V0OehcenbUkf/jQaVa4udQNJTkcj0nT3bTKZKD3HDnSGaadenVcNRDSN0sGs
yttfjDjAyi5XE0svGN+ogtzB3Juq8Qp2ylaqrda1yUyOR/CbAr8VXkFONbcN
qcSrrLDlnDzHt2uoqVHPf//k1e+fTG/GMp1P3pXpSq0LjfU15rV/bo1qtmuj
3IJfgt+1a1epSgwBAbxrazjhYxXcT1msrZqBHytdZyvbmKxpa6Ny4+0SrkTy
6DznSZsVnlvf2CprWKBMFyzOShewwxJ7gAQ7smJ8SZEQVdYTwlR6XtAgmE43
rvb0slss4EM3Zl3Abxvrqon2Ez2ZmfreYsPHN1rPHikNG6gFGQZvsGCZg9qx
PJSZW3qqizEph5y/F6wTeDbcoMQAPIMjYKaKtxgGyUQQhCaFP9QYX7esFEh+
XqVX6R2zWNgM22qKrWobW9hfaMt7eqdXc0OKqZX5wBpcSmhOoGd80zIhoADz
jbE02advDl14l/RVmQ3bm9WdOThU1bArtT5sCzNgX3C4e+taD+E2cMvqt1//
iofOe4tpELPKYLAroaICr9xbmh1zsNU6LYpvrNe1gxuz+b6DwBgxHjhTDudG
hMIjfoGqh8JDNHqhdBnsLDrCb6vKFW655eiJuyD3qu28paUfKwnB0uZ5YUaj
Lyn+ape3bPTR6OIzjsZhYkts2MQogQwQBno7HBzfkU4+6HJdmBhzFIg0e4jl
ObSQk0spR8YkH0mgQP4gRoAnr7SHhRH3hdvQi66AjxNi0G6BTEsK4K1rGzVv
yePZZBWZlcwBASciK8ySG9dtE1L+aM2GBqRY25FxpfGQl5gbU5FqxZQwy3zb
20FjgELWR1f+sIa5GH6MCRElNkHAYPFCNbaEWja2WUE8chhTb5VfEVLFPdDm
ugXg8nrLzk+eSFPBiRa6AtizTzisUis3/9mwRdn94qKL2pWw5x3tK0S4trU6
pg+//fo3T/NNPDlwLuv89uvfH0E5P5F4tposkaqw/4YUM2bNSFR9PTl5qvrj
2Evm2LFzrLTH6jWeuXKta+tdhQ2vMHajGzg0yxINU7p7ywBSQXdwfPxkJhRV
8KsJTNUizQ1tDI2T80EfWA+Yt8C+oUedZWbd8O5Jf/diXgKbxZ6TsPckoxNI
GIl1En0cx6q6FZVhC3fkJ3NDsmv4YCOQTj+yija2qug3nzlMxVpvsB1VAvA1
ITo/WtSWRadIXRkWhN/ELHNdYwe1C/lB8v1YiQIQMGbhWEazZemUbehL6U1x
j5j7YvTFaFqJI4QYRTYhXDc14WR2IKPAij87ckpkTbL4yhKaPRQwbF+Y27fY
LQEETaZLohMcQns4MOZ9kKw0WlIzGS7YzZcO4rL/wqtzm7HlIEfMUNe1IxEo
QOeAAqy2BJi2CKCQ9CVJEdLDUTOISYCd4IRclRZeQRpAmKsh2JpCWCBuXSMK
JxSKScSVBoUgf9lx3OEWoh776hGILMlAWQGYhDNiNVOSK/rGrNWirTg0vYS9
ABpRgbR15DyKZr+LvVguOmPTVpRJSXoOo875dCM+Q59pS+wO1yFrUXIVH29E
xJRsezZLLIEWfDCjCiQSwtUsHoLXfsDfvkXoQWwSztQlS61zt5bso86vO/5M
XreB6qCiHKu6LYZjgQVWqjIL4waZ/DhouJ/Jej9efPXj9VX6zm6UISo1RCBm
WMO+nnPR65a2HTgN8q4J65aM8RT3RDRrGEEiGqC4IRqWA/rqnJL939MymO4y
bSR52rJwcwie8helrAVItcy3JJGawLDGZGEGfR1gv8RaihOP6H6QCa3vFDcR
1pKLsfFLMnTHHhiqjMeQOJW5d0Ub5w7bCCyub/QSLAL5xMN08iOekX+SxxZG
15TzGKk2hJG0QVI4/QvMUTQpXtgYbMUKYK4hcUdQA/E1IiGCIdekfijNet+K
l6eZkR4Q9eRbSdW8dHSomMZ21U4SRWbnA4asE4bQCMflQMt5s8ckiQZ+jicz
mwYIcNaJuTXNTsmNwHMYXp/msmMWuFm1+ARyRVMRMq368UV6SVSIeFVbE8KP
iX/srRWqnc9Q4h7VrIbsktMf4Zgo8SA7HlOor8iJp+2ylBLsBpyGNHo8vXn0
2aJlfJhR/+7zfDpYPZk7p2ItVhdRD/jD4oZ6BeEx+vJLSPjn1tZGIv5CV8sW
GXk0usVQFPjkvkjJR5fvZ7dHY/lXXb3jzzff/sf785tvz+jz7O304iJ9GIU3
Zm/fvb846z51I9+8u7z89upMBuOpGjwaHV1O/3AkTnD07vr2/N3V9OJIwgfG
yV3WllyO1CYkTCuwZkjn2o9g3Qy4iC8Y8/rN9X//4+S5+stf/unmuzfPTk6+
+fgxfHl18vI5vhD7ktUYfuQrsYkRShJEOM1CUJTptUVgekYqkNJNpeBx5vFo
9M9/JM386VT9yzxbnzz/1/CANjx4GHU2eMg623+yN1iUeODRgWWSNgfPdzQ9
lHf6h8H3qPfeQyqPpmsGA8nJhLBCjRjXQBs0cDtWiIqMJDVBs6pdu1wRyxya
EJ93wiLm2BLJXyc4OaYocSHvjRX1K6heEJJCRUZpGiyd60Y/EnIV4bUfxlgN
4wGMRHF1tU3Tc+BVxiTmHBMA+ZOweIJDyVosHso31QOR/cpO10tsyy2aDbnp
gpTUrnOmSccGNPrdDN+JtRn/qFs/LD9cjyTtqj5yxn5dBP6Vuw0nNcstB1BR
TTag5opF7GtskBpMtnqoJn3P9bhoLHQGkhEhDdJfXnDSAb7tYSvwlvQd5mVY
IX4KXCrVrMGGydCCKAtXoFQVfs25jTkTV5B9B+r1eshQHSehTQ4I00M845Q8
c6JupZCbInYxzxU4NdYm0hLkOx3OVgsWeuLHEANlEWb/Cix5TVXehsQUnbFP
UKeNjBRdZo+NUI53qFtWFvOpdo7KwzZEOvU9GFCktYczdrACEQPEEGN9aXRF
fRld44tIyLC3oB4dZpFHiDM8YwEX2AvRtb30ULbYbGwA6r4CMJisg4zbuMyh
mrB3Rvq3l4DMfwNkvnz54gSQCXWWF2fX4eGLr169+viR9ktC111KUVR6kMtr
ruGYWCRjstNb4vlEACWhcStFch316bAlVBtE5ZIxz5vffv2rh2adeuMo1j4M
DNr1+boWBRUsBdyfgYiY/oMb9oMdU+B6SFRsuXLPZLlxbBmgyqQ+XhEIE4Xb
mBBlYZcAG3qtQi4VKoOFiHytUNftUP5qJ3rSRt+sbHYHl6Px3y6HbktMx7Ae
iGNKXKYpI6jNjeDAgZepBjlEnwMVAYlipP6/jvvUknvyHeDn/0tG/iANZzjI
IUNuhIVTqnmgybwWXZLFPcP8HKMFvYJQ017q6MlKFXbNbQud32suRIMRB3HN
vVJi63xSEDIbCUj9oPQjfQkblcYb95YiRofXiXAk2h5aSQFWDqSnLlMI8QZO
OSQCZtrsi9wmbCKjTtHHCdU2tldyUHAm6km61Uk0MKCc0c/QxwMIxmjAc4xD
7dUZMO7FJiyUeBexuZW7Tm8ToFC5yT2BKFkXsCU0yP3uaAXR67ZXWEgL6Mtk
2HdBrTD2u8oko/TaxQwTe/a2RO0bR2c3Wa/YvW2ryvAhxfH08vZRBMrnXz9l
TGSL8pmYbA/7j0cGTDdTnU6WzbeVjuR+3toip85GRR0dqEew3Uc834/Dta5T
dZsMBW1yK6sLwNCYiXitKSl7FVnGihsCOymDVpd8dwBodu1juNWGvyy1ocm1
YjUYs47vHxrCTaluGtTBn8rakPvCVqGxkRvypHAYkTvGm5jaOkn7SM76DGAx
kaZhJW1ZyLem3hSVFpSvUGjWsY6itymXHnJjIin9UvR2RccBya5RNEl9LPWe
hFxScJMgRNNeHS3TSLOvXe9bYcybjJFkqp+d8LK5QQVopQ/Zdbf62+ghyLZf
SEtHKI0n95TlNSEencRgiFC0LutuVi6aYWsOmaKJZ0yUP8XNbN3vIr2jRNI/
bctgCQ7nvE2kPERQig5CKnAFctBcGCmZYHDoZz5kTLB7M4tFUldADMEeQbpk
pkt8QDJ8kLpHPg8Ifx5q1I3ujq6gdcOHmV0jwktXNjR6epyIyf1GBwTahCZS
ryWQ8Jibpf0jtOPKVZOAZY96Yg7SSzpWAyDJgd9e3D3MO9hJKQgiTPiH+k2N
NKzIV6T7Scm34kVv+ECE9Lt2jZDbjj+UppxTDBFe7xyDMoKG05xdwKacxcTt
AmgDez85P1MzAzQUB7+OdPaYbiVEgH7x6isAdMyn0o2SDBqbX8Nzoj207QLc
9TTCW2e8EQHEH0MX0++i83FoTxeY+IkcQj4Bb4fZSuTuR5+GtZ209j4QCnp6
NQCf/SgMsBJtHrkIGZtoLop2qbZkasa0rj7rE/ywn0RmrO/fLphxuTSZrU1G
lWgvaR7PZpfREs9fPH3JqTLcFIkpgVq8YDXcEfbt3BteTsj5OHLGT1Qv4aCz
4JYE94IwOZZ56zaU08ec8j4xPtNraa8t+g1EzJGcxnO/CeIFE0Q1dL1AqpLG
6vvbrn46eQGvo+B6/f11ILedWvDS+eTssTXNYjJH4Ezmy/UkichKuoCjb6w3
Ij51POgErzJ7/CVhDasUgFO0zENfn397E6R59ezlNx8/jvv7EVoe2n8B/EkD
tO2Qm5KxD7iKmIV4HxQKcBL9c+6FB5guudVQsMhNfQ8JvOg2/ey0UyAFzhIF
20OvT5aHdEbRHXfEgo6r8MXwGAYIUFJrJ7lN9EmQ7DZL29hNI9xDXEd6rfdR
uMuvSsBJhxNZzhpYRzhhvAoRDbNwbcWSTGGFM0O3fEQ7wYyvTr6Gb1Dt8plm
PSjvmz1mwUDdSyUxYPjiWdM7ZjIPN8wGJYg0v3qN7X4fA1HGXZRYgDRazo/7
RsccdCMkiRgNxxIFqE4cIHIXTk8DKxJqQoHhbCR0xYnLFDrjNZdwo5oS0Oc7
MsN7TdQQpud0z2zvXpMclqeyoXcFamePD5yJmP0mXT8tPXiCIcezYWGuOO93
K8zdKvhoyLKPpOe+QwGOYvwI5SYk2J3mvPndIOiOOs4QG7H3zuax9I4lZ2gD
7p57hKsc++dc4Y5BOvcQw1L8DN1lFIt1OjTzrJBCyvWGTSJ9wx552rvEtXsb
qQ7UMG4nnlrL+U4I0y4IyNs5c4XuaLqRFS27d+sr5kihZzukmrherP4GGZ0Y
VaWFXI77LDscSu8JlkOsrImMNnUKsIA05wWOeX1PEoW7VqSRUGpFJOyyq7Cd
+j5J1+tkw9R3Jh+DAG14fT6MdiDt8UyZTd2aiYSiJGDOWjBs2PIur55dSzUi
1/j4iBLYtmOSQ2eRdD6cWCcE/8XU+9fybMVTEsdZM8U5Ll3eFlIG9l6eYysb
m8MycvODffERXSib5h2S7pwqwqYVyAG1hFAy++BvA/RI3a1SN9xHDFcCKIWa
cK6Y2h+9c2Qi86mDvdC1XKLInKvziBOxi32owAxHrgJn0fV2mjhUYOJPRXc7
HIFbnwr6kMcMc5Ix3qoV3xieEJOQZmg48+Gg91RDdtQpyREoHybbkIrUmjyI
755M994NNX1KRHIHo6KzJqo86AIOF45EkvjUJcZFELGlcoMSAcVRqCWRrZrs
kdyDIT1QEFs6/Wux6TJekOI7JZJa460YupnIKPEpXKEKAHonOpYuKtM6NSif
phxGVRz39dkGXM73yxw5eWClDw54/n92ZpXR4Y7wVc4BntIon1cFI48DyYTP
ySU6ngJGnXRGBeKiFAE1SRc0WZInZ+lCZrpBE/nHLJCAYRuYrlNW5GmcDx++
8NkdNuzwsf5Nz8gzpHAFW+be1gB+DrWzA0aPKTHSbsOpzyTVA/eB5EtLhDhf
Sy0jOkUrxP1Dj627OMBnipROuBzk+wV8Kbu2xXaHL4k/9bsGvMmQvRmzuPDB
ILt7mTicTzGd0nKbkG+G93Brp9hOANXdnaVrrTsa3G0IPlZfhMuyZhmqbE5S
78XfR6MZRzdRhZ45uQrA7IgKyUMiUQzKBfchOdG7ysSjz3H/Bg7rk/GB3Hww
C9h8yeE2CIHulC76/W5AdLXanG7B3RHIY0BjPXvO8HBZpOsmzRG1lnu/MZn2
rqiMhxe0uFLI6q2QFsQP/RcBaE3MRKFol1DVE7nN26WX0K5lXBoHAG6kWehb
G/yYNN1r4k0972qcuhCJLcdbeYcVtJ8yqb8eS91UqMT/CXAEx584lKoYe9S/
yccnD2x9L0N7/JXzKIKYbSbLYar43xp6FZIoNzSZMNFqO69t6v11ZTF4NOYe
3vEOqmB1zc3WBeP7zInkg2sISNqEXjOTtTVxB0CUp92zKw3xqV/J8ITbivqk
1scaeV20/iDx3mtWIef0LfXgpYVwIZ0u5TumJj7K2azoeLXrOcnte13gab5N
u0s1bAqBgw00gSrQd7odiCqp3wpGjamev3j6Dc9AX6jiVPGajd+lRknAfvNZ
Lv0LIvgGEnLenV1KF0udT6+mQ8V76UT0r4vIrTp5V24NguvT6Gl2V7kNwFvS
EQ+9JMSnG+/SopOWMPWnmSVwvuaiVqgqHbbsl/B8J4/7ccE06WhuiIf9/sq1
QbhdInX6DBzjJ3AHi0zwnxAEcHKhYdMKibLYgEQDIq6AKgBFunuVe+Ax3vlJ
bwF/rzGBpwLqBw1neeuKAm+M1bRC2bVR39OpzVi9Aa/YqpsWbxYFvVrB+37U
NZLDHTHNN17PtboEAIzVd0gjQKZMXbjWjvHwAx5BO/jp1uUIHpTYd+5eqr7a
3tH/lfoltP42MGc4wxxe4JGjb3aDBz14wwcGfm3rkP1I+QQ5vcRxZmHX75AO
K/A2yzJcUpBcZq8R85Lu2ZLMc7HqD0iQ6q3W8X9GkRMS72sWLZ3S8D1wOWpZ
LqlUJlf5YvQ/e4uZxGo3AAA=

-->

</rfc>
