rfc9706.original.xml   rfc9706.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!-- pre-edited by ST 08/26/24 -->
<!-- formatting by MC 09/11/24 -->
<!-- reference review by TH 09/18/24 -->
<!-- draft submitted in xml v3 -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.18 (Ruby 3.0. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
2) --> -ietf-mops-treedn-07" number="9706" consensus="true" updates="" obsoletes="" cat
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft egory="info" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="tr
-ietf-mops-treedn-07" category="info" submissionType="IETF" tocInclude="true" so ue" version="3" xml:lang="en">
rtRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.22.0 --> <!-- [rfced] Please review the following questions regarding this document's tit
le:
a.) Per Section 3.6 of RFC 7322 ("RFC Style Guide"), abbreviations should be
expanded in document titles and upon first use in the document. How would you
like to expand "CDN" in the title and running text?
b.) In addition, we note "TreeDN" is not expanded in the document. Is TreeDN
meant to be an abbreviation or just a general term? Please let us know how
to update the document's title to better reflect your intent.
Original:
TreeDN- Tree-based CDNs for Live Streaming to Mass Audiences
Perhaps 1 (describes TreeDN as a term):
TreeDN: Tree-Based Content Delivery Network (CDN) for Live
Streaming to Mass Audiences
or
Perhaps 2 (TreeDN appears to be an abbreviation):
Tree-Based Content Delivery Network (TreeDN) for Live Streaming
to Mass Audiences
-->
<front> <front>
<title abbrev="TreeDN">TreeDN- Tree-based CDNs for Live Streaming to Mass Au diences</title> <title abbrev="TreeDN">TreeDN- Tree-based CDNs for Live Streaming to Mass Au diences</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-mops-treedn-07"/> <seriesInfo name="RFC" value="9706"/>
<author initials="L." surname="Giuliano" fullname="Lenny Giuliano"> <author initials="L." surname="Giuliano" fullname="Lenny Giuliano">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<postal> <postal>
<street>2251 Corporate Park Drive</street> <street>2251 Corporate Park Drive</street>
<city>Herndon, VA 20171</city> <city>Herndon</city>
<country>USA</country> <region>VA</region>
<code>20171</code>
<country>United States of America</country>
</postal> </postal>
<email>lenny@juniper.net</email> <email>lenny@juniper.net</email>
</address> </address>
</author> </author>
<author initials="C." surname="Lenart" fullname="Chris Lenart"> <author initials="C." surname="Lenart" fullname="Chris Lenart">
<organization>Verizon</organization> <organization>Verizon</organization>
<address> <address>
<postal> <postal>
<street>22001 Loudoun County Parkway</street> <street>22001 Loudoun County Parkway</street>
<city>Ashburn, VA 20147</city> <city>Ashburn</city>
<country>USA</country> <region>VA</region>
<code>20147</code>
<country>United States of America</country>
</postal> </postal>
<email>chris.lenart@verizon.com</email> <email>chris.lenart@verizon.com</email>
</address> </address>
</author> </author>
<author initials="R." surname="Adam" fullname="Rich Adam"> <author initials="R." surname="Adam" fullname="Rich Adam">
<organization>GEANT</organization> <organization>GEANT</organization>
<address> <address>
<postal> <postal>
<street>City House</street> <street>City House</street>
<street>126-130 Hills Road</street> <street>126-130 Hills Road</street>
<city>Cambridge</city> <city>Cambridge</city>
<code>CB2 1PQ</code> <code>CB2 1PQ</code>
<country>UK</country> <country>United Kingdom</country>
</postal> </postal>
<email>richard.adam@geant.org</email> <email>richard.adam@geant.org</email>
</address> </address>
</author> </author>
<date year="2024" month="August" day="21"/> <date year="2024" month="December"/>
<area>Ops</area> <area>OPS</area>
<workgroup>MOPS</workgroup> <workgroup>mops</workgroup>
<keyword>multicast, SSM, AMT, LISP, CDN, PIM-SSM</keyword> <keyword>multicast</keyword>
<keyword>SSM</keyword>
<keyword>AMT</keyword>
<keyword>LISP</keyword>
<keyword>CDN</keyword>
<keyword>PIM-SSM</keyword>
<abstract> <abstract>
<?line 112?>
<t>As Internet audience sizes for high-interest live events reach unprecedented <t>As Internet audience sizes for high-interest live events reach
levels and bitrates climb to support 4K/8K/Augmented Reality (AR), live streamin unprecedented levels and bitrates climb to support 4K/8K Augmented Reality
g can place a unique type of stress upon network resources. TreeDN is a tree-ba (AR), live streaming can place a unique type of stress upon network
sed CDN architecture designed to address the distinctive scaling challenges of l resources. TreeDN is a tree-based CDN architecture designed to address
ive streaming to mass audiences. TreeDN enables operators to offer Replication- the distinctive scaling challenges of live streaming to mass audiences.
as-a-Service (RaaS) at a fraction the cost of traditional, unicast-based CDNs- i TreeDN enables operators to offer Replication-as-a-Service (RaaS) at a
n some cases, at no additional cost to the infrastructure. In addition to effic fraction of the cost of traditional, unicast-based CDNs; in some cases, ther
iently utilizing network resources to deliver existing multi-destination traffic e is no
, this architecture also enables new types of content and use cases that previou additional cost to the infrastructure. In addition to efficiently
sly were not possible or economically viable using traditional CDN approaches. utilizing network resources to deliver existing multi-destination traffic,
Finally, TreeDN is a decentralized architecture and a democratizing technology i this architecture also enables new types of content and use cases that
n the way that it makes content distribution more accessible to more people by d previously were not possible or economically viable using traditional CDN
ramatically reducing the costs of replication.</t> approaches. Finally, TreeDN is a decentralized architecture and a
democratizing technology that makes content distribution
more accessible to more people by dramatically reducing the costs of
replication.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 116?>
<!-- [rfced] The RFC Style Guide
(https://www.rfc-editor.org/rfc/rfc7322.html#section-4) states that RFCs
must have an Introduction. We have added an Introduction and copied in
text from the Abstract; please review and let us know if any changes or
updates should be made. -->
<section anchor="introduction">
<name>Introduction</name>
<t>
As Internet audience sizes for high-interest live events reach
unprecedented levels and bitrates climb to support 4K/8K Augmented
Reality (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 of the cost of traditional,
unicast-based CDNs; in some cases, there is no additional cost to the infrast
ructure. 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 were not possible or economically viable using traditional
CDN approaches. Finally, TreeDN is a decentralized architecture and
a democratizing technology that makes content
distribution more accessible to more people by dramatically reducing
the costs of replication.
</t>
</section>
<!-- [rfced] We note that MUST and SHOULD are capitalized in Sections 7.1 and
7.2. These appear to be the requirement key words defined in RFC 2119, so
we have added the paragraph describing their usage and cited RFCs 2119
and 8174 as normative references. If that was not your intention, please let
us know any objections. -->
<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&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</section>
<section anchor="problem-statement"> <section anchor="problem-statement">
<name>Problem Statement</name> <name>Problem Statement</name>
<t>Live streaming to mass audiences can impose unique demands on network r <t>Live streaming to mass audiences can impose unique demands on network
esources. For example, live sporting events broadcast over the Internet to end resources. For example, live sporting events that broadcast over the
users has much lower tolerance for long playout buffers than typical on-demand v Internet to end users have a much lower tolerance for long playout
ideo streaming. Viewers of live sporting events have long been conditioned by b buffers than typical on-demand video streaming. Viewers of live
roadcast television to expect to see the content in real time, with only very sh sporting events have long been conditioned by broadcast television to
ort buffers for broadcast delays to prevent profanity and other objectionable co expect to see the content in real time, with only very short buffers for
ntent from making on the air (the "seven-second delay" <xref target="BROADCAST-D broadcast delays to prevent profanity and other objectionable content
ELAY"/>). With micro-betting, even this 5-10 second delay can be too long. By c from making on the air (this is known as the "seven-second delay" <xref
omparison, when watching on-demand movies, an extra one- or two-minute playout b target="BROADCAST-DELAY"/>). With micro-betting, even this 5 to 10 second
uffer tends to be perfectly acceptable for viewers. If playout buffers for live delay can be too long. By comparison, when watching on-demand movies, an
sports are that long, viewers run the risk of being alerted to the game winning extra one- or two-minute playout buffer tends to be perfectly acceptable
score from text messages from friends or cheers from the bar across the street, for viewers. If playout buffers for live sports are that long, viewers
minutes before they view it themselves.</t> run the risk of being alerted to a game-winning score from text
<t>Another unique characteristic of live streaming is join rate. While on messages from friends or cheers from the bar across the street minutes
-demand video streaming can consume massive amounts of network resources, the vi before they view it themselves.</t>
ewing rates tend to be smooth and predictable. Service Providers observe gradua <t>Another unique characteristic of live streaming is the join rate. Whil
l levels of traffic increases over the evening hours corresponding to prime-time e
viewing habits. By comparison, viewing rates of live video streams can more cl on-demand video streaming can consume massive amounts of network
osely resemble a step function with much less predictability as mass audiences o resources, the viewing rates tend to be smooth and predictable. Service
f viewers tune in to watch the game at the same time.</t> Providers (SPs) observe gradual levels of traffic increases over the eveni
<t>Previous efforts at more efficient network replication of multi-destina ng
tion traffic have experienced mixed success in terms of adoption. IP multicast hours corresponding to prime-time viewing habits. By comparison,
is widely deployed on financial networks, video distribution networks, L3VPN net viewing rates of live video streams can more closely resemble a step
works and certain enterprises. But most of these deployments are restricted to function with much less predictability as mass audiences of viewers tune
"walled-garden" networks. Multicast over the global Internet has failed to gain in to watch the game at the same time.</t>
traction, as only a very small portion of the Internet is multicast-enabled at <t>Previous efforts for more efficient network replication of
this time.</t> multi-destination traffic have experienced mixed success in terms of
<t>TreeDN is a tree-based CDN architecture that is the result of the evolu adoption. IP multicast is widely deployed on financial networks, video
tion of network-based replication mechanisms based on lessons learned from what distribution networks, L3VPN networks, and certain enterprises. However,
has and has not worked well in the past. TreeDN addresses the fundamental issue most
s of what has hindered multicast from adoption on the global Internet and enable of these deployments are restricted to "walled-garden" networks.
s service providers the opportunity to deliver new Replication-as-a-Service (Raa Multicast over the global Internet has failed to gain traction, as only
S) offerings to content providers, while more efficiently utilizing network reso a very small portion of the Internet is multicast enabled at this
urces by eliminating duplicated traffic, and thus, improving the experience of e time.</t>
nd users. TreeDN accomplishes this with the combination of a simplified model o
f native multicast along with network overlays to reach receivers on unicast-onl <t>TreeDN is a tree-based CDN architecture that is the result of the
y parts of the Internet.</t> evolution of network-based replication mechanisms and is based on lessons
<t>By more efficiently supporting multi-destination traffic, TreeDN is an learned from what has and has not worked well in the past. TreeDN
architecture that can enable new types of content, such as Augmented Reality (AR addresses the fundamental issues of what has hindered multicast from
) live streaming to mass audiences, that previously weren't possible or economic adoption on the global Internet and enables SPs the
ally viable on the Internet due to the inefficiencies of unicast.</t> opportunity to deliver new Replication-as-a-Service (RaaS) offerings to
content providers, while more efficiently utilizing network resources by
eliminating duplicated traffic. Thus, this improves the experience of
end users. TreeDN accomplishes this with the combination of a
simplified model of native multicast along with network overlays to
reach receivers on unicast-only parts of the Internet.</t>
<t>By more efficiently supporting multi-destination traffic, TreeDN is
an architecture that can enable new types of content (such as AR live stre
aming to mass audiences) that previously weren't
possible or economically viable on the Internet due to the
inefficiencies of unicast.</t>
</section> </section>
<section anchor="applicability"> <section anchor="applicability">
<name>Applicability</name> <name>Applicability</name>
<t>While the primary use case mentioned throughout this document is live s <t>While the primary use case mentioned throughout this document is live
treaming of multimedia content (audio, video, AR, real-time telemetry data), the streaming of multimedia content (e.g., audio, video, AR, and real-time tel
TreeDN architecture can provide efficient delivery for any content that needs t emetry
o be replicated and delivered to multiple destinations. For example, large soft data), the TreeDN architecture can provide efficient delivery for any
ware file updates (eg, OS upgrades) that need to be delivered to many end users content that needs to be replicated and delivered to multiple
in a very short window of time can cause significant strain on network resources destinations. For example, large software file updates (e.g., OS
. Using TreeDN, this use case can be handled much more efficiently by the netwo upgrades) that need to be delivered to many end users in a very short
rk.</t> window of time can cause significant strain on network resources. Using
TreeDN, this use case can be handled much more efficiently by the
network.</t>
</section> </section>
<section anchor="multicast-challenges-in-the-past"> <section anchor="multicast-challenges-in-the-past">
<name>Multicast Challenges in the Past</name> <name>Multicast Challenges in the Past</name>
<t>The following issues have been the some of the primary challenges for d <t>The following issues have been some of the primary challenges for
eployment of IP multicast over the global Internet. This is not intended to be deployment of IP multicast over the global Internet. This is not
an exhaustive list, but to rather to provide context to the solution and how it intended to be an exhaustive list but rather a list that provides context
addresses these primary challenges.</t> for the solution and how it addresses these primary challenges.</t>
<ul spacing="normal"> <dl>
<li>
<t>The "All or Nothing" Problem: IP multicast requires every layer-3 h <!-- [rfced] FYI - For readability, we have updated the text below as
op between source and receivers to be multicast-enabled. To achieve ubiquitous follows. Please review and let us know any objections.
availability on the global Internet, this essentially means nearly every interfa
ce on every router and firewall between all end hosts must support a multicast r Original:
outing protocol like Protocol Independent Multicast - Sparse Mode (PIM-SM) <xref
target="RFC7761"/> or Multipoint Label Distribution Protocol (mLDP) <xref targe To achieve ubiquitous availability on the global Internet, this
t="RFC6388"/>. This requirement creates a bar to deployment that is practically essentially means nearly every interface on every router and firewall
impossible to overcome.</t> between all end hosts must support a multicast routing protocol like
</li> Protocol Independent Multicast - Sparse Mode (PIM- SM) [RFC7761] or
<li> Multipoint Label Distribution Protocol (mLDP) [RFC6388].
<t>The "It's Too Complex" Problem: operators have long complained that
multicast routing protocols like PIM-SM are simply too complex, making it costl Current:
y to design, configure, manage and troubleshoot IP multicast in the network.</t>
</li> To achieve ubiquitous availability on the global Internet, this
<li> essentially means that nearly every interface on every router and
<t>The "Chicken and Egg" Problem: there's not much multicast content b firewall between all end hosts must support a multicast routing protocol
ecause there's not much of a multicast-enabled audience, but there's not much of (such as Protocol Independent Multicast - Sparse Mode (PIM- SM) [RFC7761]
a multicast-enabled audience because there's not much multicast content.</t> or the Multipoint Label Distribution Protocol (mLDP) [RFC6388]).
</li> -->
</ul>
<t>TreeDN is the evolution of network-based replication based on lessons l <dt>The "All or Nothing" problem:</dt><dd>IP multicast requires
earned over decades and is designed to address the problems listed above.</t> every Layer 3 hop between the source and receivers to be
multicast enabled. To achieve ubiquitous availability on the global
Internet, this essentially means that nearly every interface on every
router and firewall between all end hosts must support a multicast
routing protocol (such as Protocol Independent Multicast - Sparse Mode
(PIM-SM) <xref target="RFC7761"/> or the Multipoint Label Distribution
Protocol (mLDP) <xref target="RFC6388"/>). This requirement creates
a bar to deployment that is practically impossible to overcome.</dd>
<dt>The "It's Too Complex" problem:</dt><dd>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.</dd>
<dt>The "Chicken and Egg" problem:</dt><dd>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.</dd>
</dl>
<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>
<section anchor="treedn-architecture"> <section anchor="treedn-architecture">
<name>TreeDN Architecture</name> <name>TreeDN Architecture</name>
<t>TreeDN leverages a simplified model for multicast deployment combined w <t>TreeDN leverages a simplified model for multicast deployment combined
ith network overlays to deliver traffic to receiving hosts on unicast-only netwo with network overlays to deliver traffic to receiving hosts on
rks. With network overlays, a service can be achieved and delivered to end user unicast-only networks. With network overlays, a service can be achieved
s while recognizing and tolerating the practical realities of what is possible o and delivered to end users while recognizing and tolerating the
ver a network as diverse as the global Internet. That is, the replication servi practical realities of what is possible over a network as diverse as the
ce is available to users and applications across the global Internet regardless global Internet. That is, the replication service is available to users
of what protocols may exist in the underlying networks that constitute the under and applications across the global Internet regardless of what protocols
lay.</t> may exist in the underlying networks that constitute the underlay.</t>
<figure anchor="block"> <figure anchor="block">
<name>TreeDN Provider Example</name> <name>TreeDN Provider Example</name>
<artwork><![CDATA[ <artwork><![CDATA[
TreeDN Provider TreeDN Provider
+-------------------------------+ +-------------------------------+
| | | |
| Native Multicast On-Net | | Native Multicast On-Net |
+----------+ | (PIM-SSM) | +----------+ | (PIM-SSM) |
| Content/ |----+ | | Content/ |----+ |
| Mcast | | | | Mcast | | |
skipping to change at line 120 skipping to change at line 316
Receivers . Receivers .
AMT +-+ AMT +-+
Gateway +-+ Gateway +-+
| |
Content Content
Receiver Receiver
]]></artwork> ]]></artwork>
</figure> </figure>
<section anchor="treedn-overlays"> <section anchor="treedn-overlays">
<name>TreeDN Overlays</name> <name>TreeDN Overlays</name>
<t>One overlay technology that TreeDN leverages is Automatic Multicast T <t>One overlay technology that TreeDN leverages is Automatic Multicast
unneling (AMT) <xref target="RFC7450"/>. With AMT, end hosts on unicast-only ne Tunneling (AMT) <xref target="RFC7450"/>. With AMT, end hosts on
tworks (AMT Gateways) can dynamically build tunnels to routers on the multicast- unicast-only networks (AMT Gateways) can dynamically build tunnels to
enabled part of the network (AMT Relays) and receive multicast streams. The AMT routers on the multicast-enabled part of the network (AMT Relays) and
Gateway is a thin software client which typically sits on the receiving end hos receive multicast streams. The AMT Gateway is a thin software client
t and initiates the tunnel at an AMT Relay, which is a tunnel server that typica that typically sits on the receiving end host and initiates the tunnel
lly sits at the border of the multicast network. AMT allows any end host on the at an AMT Relay. The AMT Relay is a tunnel server that typically sits
Internet to receive multicast content regardless of whether their local provide at the border of the multicast network. AMT allows any end host on
r supports multicast (aka, "off-net receivers"), which addresses the "All or Not the Internet to receive multicast content regardless of whether their
hing" Problem. Links and devices that do not support multicast are simply tunne local provider supports multicast (aka, "off-net receivers"); this
led over- they no longer present a barrier to the overall replication service fo addresses the "All or Nothing" problem. Links and devices that do not
r end users. Those networks that do deploy and support multicast, as well as th support multicast are simply tunneled over; they no longer present a
e content providers that serve up multicast content, are able to enjoy the benef barrier to the overall replication service for end users. Those
its of efficient replication and delivery. Further, these benefits can serve as networks that do deploy and support multicast, as well as the content
incentives for operators who do not yet support multicast to enable it on their providers that serve up multicast content, are able to enjoy the
networks, a key benefit of incremental deployment described in section 4.3 of < benefits of efficient replication and delivery. Further, these
xref target="RFC9049"/>. Once the cost of carrying duplicated unicast tunnels i benefits can serve as incentives for operators who do not yet support
s perceived by those operators to exceed the cost of deploying multicast, they a multicast to enable it on their networks, which is a key benefit of incr
re more likely to enable multicast on their networks. In this way, TreeDN effec emental
tively supports incremental deployment in a way that was not previously possible deployment described in <xref target="RFC9049" sectionFormat="of"
with traditional (non-overlay) multicast networking. Finally, AMT also address section="4.3"/>. Once the cost of carrying duplicated unicast tunnels
es the "Chicken and Egg" Problem, as all end hosts on the global Internet that h is perceived by those operators to exceed the cost of deploying
ave access to an AMT Relay are capable of becoming audience members.</t> multicast, they are more likely to enable multicast on
<t>To support receiving on both native and non-native networks, receivin their networks. Thus, TreeDN effectively supports incremental deployment
g hosts can first attempt to join the traffic natively and, if no multicast traf in a way that was
fic is received, fallback to AMT. This fallback mechanism can be handled by the not previously possible with traditional (non-overlay)
application layer.</t> multicast networking. Finally, AMT also addresses the "Chicken and
<t>In addition to AMT, other overlay technologies like Locator/ID Separa Egg" problem, as all end hosts on the global Internet that have access
tion Protocol (LISP) <xref target="RFC9300"/> can be utilized to deliver content to an AMT Relay are capable of becoming audience members.</t>
from multicast-enabled networks to end hosts that are separated by portions of <t>To support receiving on both native and non-native networks,
the network (at the last/middle/first mile) that do not support multicast.</t> receiving hosts can first attempt to join the traffic natively, and if
no multicast traffic is received, they can fall back to AMT. This fallb
ack
mechanism can be handled by the application layer.</t>
<t>In addition to AMT, other overlay technologies like the Locator/ID
Separation Protocol (LISP) <xref target="RFC9300"/> 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>
<!-- [rfced] Please review the following questions regarding the text below.
a.) Although the term "SR P2MP" does appear in RFC 9524, RFC 9524
cites the Internet-Draft "draft-ietf-pim-sr-p2mp-policy-10"
[P2MP-POLICY] as the source of this term. Should the citation to
"[RFC9524]" be updated to "[P2MP-POLICY]" instead?
b.) Per Section 3.6 of RFC 7322 ("RFC Style Guide"), abbreviations should be
expanded upon first use. How would you like to expand "VRF" below? Note that
RFC 9300 uses "Virtual Routing and Forwarding (VRF)".
Original:
However, any multicast routing protocol
capable of supporting SSM can be used as a TreeDN native on-net, such
as mLDP, Global Table Multicast (GTM) [RFC7716] and BGP-based
Multicast [I-D.ietf-bess-bgp-multicast], or even BGP-MVPN [RFC6513]
for those operators who carry the global routing table in a VRF.
Likewise, any data plane technology that supports SSM, including BIER
[RFC8279] and SR-P2MP [I-D.ietf-spring-sr-replication-segment] can
be used.
Perhaps:
However, any multicast routing protocol
capable of supporting SSM can be used as a TreeDN native on-net, such
as mLDP, Global Table Multicast (GTM) [RFC7716] and BGP-based
Multicast [BGP-MULTICAST], or even BGP Multicast VPN (BGP-MVPN)
[RFC6513] for those operators who carry the global Virtual Routing
and Forwarding (VRF) table. Likewise, any data plane technology that
supports SSM, including Bit Index Explicit Replication (BIER) [RFC8279]
and Segment Routing (SR) Point-to-Multipoint (P2MP) [P2MP-POLICY], can
be used.
-->
<section anchor="treedn-native-on-net"> <section anchor="treedn-native-on-net">
<name>TreeDN Native On-Net</name> <name>TreeDN Native On-Net</name>
<t>Networks that support multicast provide the native on-net component o <t>Networks that support multicast provide the native on-net component
f TreeDN. The primary requirement of the native on-net is to support Source-Spe of TreeDN. The primary requirement of the native on-net is to support
cific Multicast (SSM) <xref target="RFC4607"/>. PIM-SSM, which is merely a subs Source-Specific Multicast (SSM) <xref target="RFC4607"/>. PIM-SSM,
et of PIM-SM, is the multicast routing protocol typically used in SSM. However, which is merely a subset of PIM-SM, is the multicast routing protocol
any multicast routing protocol capable of supporting SSM can be used as a TreeD typically used in SSM. However, any multicast routing protocol
N native on-net, such as mLDP, Global Table Multicast (GTM) <xref target="RFC771 capable of supporting SSM can be used as a TreeDN native on-net, such
6"/> and BGP-based Multicast <xref target="I-D.ietf-bess-bgp-multicast"/>, or ev as mLDP, Global Table Multicast (GTM) <xref target="RFC7716"/> and
en BGP-MVPN <xref target="RFC6513"/> for those operators who carry the global ro BGP-based multicast <xref target="I-D.ietf-bess-bgp-multicast"/>, or
uting table in a VRF. Likewise, any data plane technology that supports SSM, in even BGP Multicast VPN (BGP-MVPN) <xref target="RFC6513"/> for those ope
cluding BIER <xref target="RFC8279"/> and SR-P2MP <xref target="I-D.ietf-spring- rators who carry
sr-replication-segment"/> can be used.</t> the global routing table in a VRF. Likewise, any data plane
<t>The key benefit of SSM as the native on-net component of TreeDN is th technology that supports SSM, including Bit Index Explicit Replication
at it radically simplifies the control plane needed to support replication in th (BIER) <xref target="RFC8279"/> and Segment Routing (SR) Point-to-Multip
e network. This simplification comes by moving source discovery from the networ oint (P2MP) <xref target="RFC9524"/>,
k layer to some sort of out-of-band mechanism, usually in the application layer. can be used.</t>
In SSM, the receiver uses Internet Group Management Protocol, Version 3 (IGMPv
3) <xref target="RFC3376"/> for IPv4 or Multicast Listener Discovery Version 2 ( <t>The key benefit of SSM as the native on-net component of TreeDN is
MLDv2) <xref target="RFC3810"/> for IPv6 to specify both the source and group ad that it radically simplifies the control plane needed to support
dress of the multicast stream. This allows the last hop router to immediately j replication in the network. This simplification comes by moving
oin the multicast stream along the shortest-path tree (SPT) without the need for source discovery from the network layer to some sort of out-of-band
shared trees. This benefit addresses the "It's Too Complex" Problem. By elimi mechanism, usually in the application layer. In SSM, the receiver
nating the need for network-based source discovery, most of the complexity of mu uses the Internet Group Management Protocol Version 3 (IGMPv3) <xref
lticast is then eliminated, which reduces the cost of deploying and operating a target="RFC3376"/> for IPv4 or the Multicast Listener Discovery Version
multicast network. Further rationale for this SSM-only approach can be found in 2
Any-Source Multicast (ASM) Deprecation <xref target="RFC8815"/>.</t> (MLDv2) protocol <xref target="RFC3810"/> for IPv6 to specify both the s
ource
and group address of the multicast stream. This allows the last-hop
router to immediately join the multicast stream along the
shortest-path tree (SPT) without the need for shared trees. This
benefit addresses the "It's Too Complex" problem. By eliminating the
need for network-based source discovery, most of the complexity of
multicast is then eliminated, which reduces the cost of deploying and
operating a multicast network. Further rationale for this SSM-only
approach can be found in Any-Source Multicast (ASM) deprecation <xref
target="RFC8815"/>.</t>
</section> </section>
</section> </section>
<section anchor="replication-as-a-service-raas"> <section anchor="replication-as-a-service-raas">
<name>Replication-as-a-Service (RaaS)</name> <name>Replication-as-a-Service (RaaS)</name>
<t>Content providers have traditionally used CDNs to distribute content th <t>Content providers have traditionally used CDNs to distribute content
at needs to be delivered to large audiences, essentially outsourcing the task of that needs to be delivered to large audiences, essentially outsourcing
replication to CDN providers. Most CDNs utilize unicast delivery, as multicast the task of replication to CDN providers. Most CDNs utilize unicast
is not an option due to its lack of general availability on the global Internet delivery, as multicast is not an option due to its lack of general
. TreeDN is a CDN architecture that leverages tree-based replication to more ef availability on the global Internet. TreeDN is a CDN architecture that
ficiently utilize network resources to deliver simultaneous multi-destination tr leverages tree-based replication to more efficiently utilize network
affic. By leveraging overlay networking to address the "All or Nothing" and "Ch resources to deliver simultaneous multi-destination traffic. By
icken and Egg" Problems and SSM to address the "It's Too Complex" Problem, TreeD leveraging overlay networking to address the "All or Nothing" and
N avoids the practical issues that previously prevented multicast from being a v "Chicken and Egg" problems, and leveraging SSM to address the "It's Too Co
iable option for CDN providers.</t> mplex"
<t>TreeDN has several advantages over traditional unicast-based CDN approa problem, TreeDN avoids the practical issues that previously prevented
ches. First, the TreeDN functionality can be delivered entirely by the existing multicast from being a viable option for CDN providers.</t>
network infrastructure. Specifically, for operators with routers that support <t>TreeDN has several advantages over traditional unicast-based CDN
AMT natively, multicast traffic can be delivered directly to end users without t approaches. First, the TreeDN functionality can be delivered entirely
he need for specialized CDN devices, which typically are servers that need to be by the existing network infrastructure. Specifically, for operators
racked, powered, cooled and connected to ports on routers that could otherwise with routers that support AMT natively, multicast traffic can be
have been consumed by paying customers. In this way, SPs can offer new RaaS fun delivered directly to end users without the need for specialized CDN
ctionality to content providers at potentially zero additional cost in new equip devices, which typically are servers that need to be racked, powered,
ment.</t> cooled, and connected to ports on routers that otherwise could have been
<t>Additionally, TreeDN is an open architecture that leverages mature, IET consumed by paying customers. In this way, SPs can offer new RaaS
F-specified and widely implemented network protocols. TreeDN also requires far functionality to content providers at potentially zero additional cost
less coordination between the content provider and the CDN operator. That is, t in new equipment.</t>
here are no storage requirements for the data, nor group-key management issues s <t>Additionally, TreeDN is an open architecture that leverages mature,
ince a TreeDN provider merely forwards packets. A TreeDN provider simply needs IETF-specified, and widely implemented network protocols. TreeDN also
to have enough accounting data (eg, traffic data, number of AMT tunnels, etc) to requires far less coordination between the content provider and the CDN
properly bill customers for the service. By contrast, traditional unicast-base operator. That is, there are no storage requirements for the data, nor
d CDNs often incorporate proprietary, non-interoperable technologies and require group-key management issues, since a TreeDN provider merely forwards
significant coordination between the content provider and the CDN to handle suc packets. A TreeDN provider simply needs to have enough accounting data
h things as file storage, data protection and key-management.</t> (e.g., traffic data, number of AMT tunnels, etc.) to properly bill
<t>TreeDN introduces a deployment model that requires new considerations f customers for the service. By contrast, traditional unicast-based CDNs
or transport layer mechanisms that are frequently relied upon by traditional uni often incorporate proprietary, non-interoperable technologies and
cast-based CDNs. A discussion on these considerations and differences can be fo require significant coordination between the content provider and the
und in section 7.</t> CDN to handle such things as file storage, data protection, and
key management.</t>
<t>TreeDN introduces a deployment model that requires new considerations
for transport-layer mechanisms that are frequently relied upon by
traditional unicast-based CDNs. A discussion on these considerations
and differences can be found in <xref
target="decentralizationdemocratization-of-content-sourcing"/>.</t>
</section> </section>
<section anchor="decentralizationdemocratization-of-content-sourcing"> <section anchor="decentralizationdemocratization-of-content-sourcing">
<name>Decentralization/Democratization of Content Sourcing</name> <name>Decentralization/Democratization of Content Sourcing</name>
<t>TreeDN is an inherently decentralized architecture. This reduces the c <t>TreeDN is an inherently decentralized architecture. This reduces the
ost for content sourcing, as any host connected to a multicast-enabled network, cost for content sourcing, as any host connected to a multicast-enabled
or on a source-capable overlay, can send out a single data stream that can be re network or on a source-capable overlay can send out a single data
ached by an arbitrarily large audience. By effectively reducing to zero the mar stream that can be reached by an arbitrarily large audience. By
ginal cost of reaching each additional audience member, from the perspective of effectively reducing the marginal cost of reaching each
the source, TreeDN democratizes content sourcing on the Internet.</t> additional audience member to zero, from the perspective of the source, Tr
eeDN
democratizes content sourcing on the Internet.</t>
</section> </section>
<!-- [rfced] For clarity, may we update the text below as follows?
Original:
In many cases, these issues are more related to TCP-UDP differences than
unicast- multicast differences, thus UDP-based solutions can be leveraged
to address most gaps.
Perhaps:
In many cases, these issues are more related to differences between TCP and
UDP than differences between unicast and multicast; thus, UDP-based
solutions can be leveraged to address most gaps.
-->
<section anchor="transport-layer-related-differences-between-treedn-and-trad itional-cdns"> <section anchor="transport-layer-related-differences-between-treedn-and-trad itional-cdns">
<name>Transport Layer-Related Differences between TreeDN and Traditional C <name>Transport-Layer-Related Differences between TreeDN and Traditional C
DNs</name> DNs</name>
<t>The focus of this document is on the network layer components that comp <t>The focus of this document is on the network-layer components that
rise the TreeDN architecture. This section introduces some of the key transport comprise the TreeDN architecture. This section introduces some of the
layer-related differences between TreeDN and traditional unicast-based CDNs tha key transport-layer-related differences between TreeDN and traditional
t should be taken into consideration when deploying TreeDN-based services. In m unicast-based CDNs that should be taken into consideration when
any cases, these issues are more related to TCP-UDP differences than unicast-mul deploying TreeDN-based services. In many cases, these issues are more
ticast differences, thus UDP-based solutions can be leveraged to address most ga related to TCP-UDP differences than unicast-multicast differences; thus,
ps. The aim of this section is to point to some of the existing work to address UDP-based solutions can be leveraged to address most gaps. The aim of
these gaps, as well as suggest further work that could be undertaken within the this section is to point to some of the existing work to address these
IETF. Further details of these transport layer mechanisms are beyond the scope gaps, as well as to suggest further work that could be undertaken within
of this document.</t> the IETF. Further details of these transport-layer mechanisms are
<section anchor="integration-with-unicast"> beyond the scope of this document.</t>
<!-- [rfced] May we update the text below as follows for ease of the reader?
Original:
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.
Perhaps:
Since SSM inherently implies that 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 or lower bandwidth
streams, etc.) are not well suited to SSM delivery.
-->
<section anchor="integration-with-unicast">
<name>Integration with Unicast</name> <name>Integration with Unicast</name>
<t>Since SSM inherently implies unidirectional traffic flows from one to <t>Since SSM inherently implies unidirectional traffic flows from one
many, mechanisms that rely on bidirectional communication between receivers and to many, mechanisms that rely on bidirectional communication between
the content provider, such as bespoke advertising, telemetry data from receiver receivers and the content provider, such as bespoke advertising,
s detailing end user experience, distribution of decryption keys, switching to h telemetry data from receivers detailing end-user experience,
igher/lower bandwidth streams, etc, are not well suited to SSM delivery. As suc distribution of decryption keys, switching to higher/lower bandwidth
h, separate unicast streams between receivers and content providers may be used streams, etc., are not well suited to SSM delivery. As such, separate
for this type of "out-of-band" functions while SSM is used to deliver the actual unicast streams between receivers and content providers may be used
content of interest. These "out-of-band" unicast streams SHOULD use the same c for this type of "out-of-band" function while SSM is used to deliver
ongestion control and authentication mechanisms that are used today for mass aud the actual content of interest. These "out-of-band" unicast streams
ience unicast delivery. Generally speaking, this hybrid unicast-multicast appro <bcp14>SHOULD</bcp14> use the same congestion control and authentication
ach is best handled by the application layer and further detail is beyond the sc mechanisms
ope of this document.</t> that are used today for mass audience unicast delivery. Generally
speaking, this hybrid unicast-multicast approach is best handled by
the application layer and further detail is beyond the scope of this
document.</t>
</section> </section>
<section anchor="reliability-adaptive-bitrate-and-congestion-control"> <section anchor="reliability-adaptive-bitrate-and-congestion-control">
<name>Reliability, Adaptive Bitrate and Congestion Control</name> <name>Reliability, Adaptive Bitrates, and Congestion Control</name>
<t>Traditional unicast-based CDNs frequently rely on HTTPS over TCP tran <t>Traditional unicast-based CDNs frequently rely on HTTPS over TCP
sport and are thus able to leverage the granularity of TCP-based mechanisms for transport; thus, they are able to leverage the granularity of TCP-based
reliability, congestion control and adaptive bitrate streaming. But this granul mechanisms for reliability, congestion control, and adaptive bitrate
arity comes at a cost of sending a separate datastream to each viewer. Multicas streaming. However, this granularity comes at a cost of sending a separ
t transmissions usually employ UDP, which inherently lacks many of the aforement ate
ioned benefits of TCP, but can scale much better for mass audiences of simultane data stream to each viewer. Multicast transmissions usually employ
ous viewers. Forward Error Correction (FEC) is a mechanism that has demonstrate UDP, which inherently lacks many of the aforementioned benefits of
d full recovery for up to 5% packet loss and interruptions up to 400ms for multi TCP but can scale much better for mass audiences of simultaneous
cast datastreams in <xref target="EUMETSAT-TERRESTRIAL"/>. NACK-Oriented Reliab viewers. Forward Error Correction (FEC) is a mechanism that has
le Multicast (NORM) <xref target="RFC5740"/> leverages FEC-based repair and othe demonstrated full recovery for up to 5% packet loss and interruptions
r Reliable Multicast Transport building blocks to provide end-to-end reliable tr up to 400 ms for multicast data streams in <xref
ansport over multicast networks.</t> target="EUMETSAT-TERRESTRIAL"/>. NACK-Oriented Reliable Multicast
<t>QUIC <xref target="RFC9000"/> is another popular transport used by tr (NORM) <xref target="RFC5740"/> leverages FEC-based repair and other
aditional unicast-based CDNs. While QUIC does use UDP, it does not currently su Reliable Multicast Transport (RMT) building blocks to provide end-to-end
pport multicast. Multicast extensions to QUIC have been proposed in <xref targe reliable transport over multicast networks.</t>
t="I-D.jholland-quic-multicast"/>.</t> <t>QUIC <xref target="RFC9000"/> is another popular transport used by
<t>Section 4.1 of <xref target="RFC8085"/> describes how a sender can di traditional unicast-based CDNs. While QUIC does use UDP, it does not
stribute data across multiple multicast source-group channels so that each recei currently support multicast. Multicast extensions to QUIC have been
ver can join the most appropriate channels for its own reception rate capability proposed in <xref target="I-D.jholland-quic-multicast"/>.</t>
, thus providing adaptive bitrate capabilities for multicast streams. DVB MABR
<xref target="DVB-MABR"/> and MAUD <xref target="MAUD"/> extensively describe an <!-- [rfced] FYI - We have updated the text below to avoid the duplicate
architecture that enables reliability and dynamic bitrate adaptation.</t> appearance of these terms. Please review and let us know any objections.
<t>TreeDN deployments MUST follow the congestion control guidelines desc
ribed in Section 4.1.4.2 of <xref target="RFC7450"/>.  Multicast applications be Original:
ing distributed over TreeDN deployments SHOULD implement congestion control for
its data transmission as described in Section 4.1 in <xref target="RFC8085"/>. DVB MABR [DVB-MABR] and MAUD [MAUD] extensively
The AMT gateway SHOULD use the topologically closest AMT relay. Section 3.1 of < describe an architecture that enables reliability and dynamic bitrate
xref target="RFC8777"/> describes a set of procedures for optimal relay selectio adaptation.
n.</t>
DVB MABR [DVB-MABR] and
MAUD [MAUD] extensively describe an architecture that includes
encryption of multicast streams.
Current:
[DVB-MABR] and [MAUD] extensively describe an
architecture that enables reliability and dynamic bitrate adaptation.
[DVB-MABR] and [MAUD] extensively describe an architecture that
includes encryption of multicast streams.
-->
<t><xref target="RFC8085" sectionFormat="of" section="4.1"/> describes
how a sender can distribute data across multiple multicast
source-group channels so that each receiver can join the most
appropriate channels for its own reception rate capability, thus
providing adaptive bitrate capabilities for multicast streams. <xref tar
get="DVB-MABR"/> and <xref target="MAUD"/>
extensively describe an architecture that enables reliability and
dynamic bitrate adaptation.</t>
<t>TreeDN deployments <bcp14>MUST</bcp14> follow the congestion control
guidelines
described in <xref target="RFC7450" sectionFormat="of"
section="4.1.4.2"/>. A multicast application that is being distributed o
ver
TreeDN deployments <bcp14>SHOULD</bcp14> implement congestion control fo
r its data
transmission as described in <xref target="RFC8085" sectionFormat="of"
section="4.1"/>. The AMT gateway <bcp14>SHOULD</bcp14> use the topologi
cally closest
AMT relay. <xref target="RFC8777" sectionFormat="of" section="3.1"/>
describes a set of procedures for optimal relay selection.</t>
</section> </section>
<section anchor="authorization-and-encryption"> <section anchor="authorization-and-encryption">
<name>Authorization and Encryption</name> <name>Authorization and Encryption</name>
<t>A multicast sender typically has little to no control or visibility a
bout which end hosts may receive the datastream. Encryption can be used to ensu <!-- [rfced] For clarity, may we add a noun to the text in parentheses below?
re that only authorized receivers are able to access meaningful data. That is,
even if unauthorized end hosts (eg, non-paying) receive the datastream, without Original:
decryption keys, the data is useless. <xref target="I-D.ietf-ipsecme-g-ikev2"/>
describes an extension to IKEv2 for the purpose of group key management. DVB M That is, even if unauthorized end hosts (eg, non-
ABR <xref target="DVB-MABR"/> and MAUD <xref target="MAUD"/> extensively describ paying) receive the datastream, without decryption keys, the data is
e an architecture that includes encryption of multicast streams.</t> useless.
Perhaps:
That is, even if unauthorized end hosts (e.g., non-paying end hosts)
receive the data stream, without decryption keys, the data is useless.
-->
<t>A multicast sender typically has little to no control or visibility
about which end hosts may receive the data stream. Encryption can be
used to ensure that only authorized receivers are able to access
meaningful data. That is, even if unauthorized end hosts (e.g.,
non-paying) receive the data stream, without decryption keys, the data
is useless. <xref target="I-D.ietf-ipsecme-g-ikev2"/> describes an
extension to the Internet Key Exchange Protocol Version 2 (IKEv2) for th
e
purpose of group key management. <xref target="DVB-MABR"/>
and <xref target="MAUD"/> extensively describe an architecture
that includes encryption of multicast streams.</t>
</section> </section>
</section> </section>
<section anchor="treedn-deployments"> <section anchor="treedn-deployments">
<name>TreeDN Deployments</name> <name>TreeDN Deployments</name>
<t>EUMETCast Terrestrial is a service from EUMETSAT that delivers meteorol <t>EUMETCast Terrestrial is a service from the European Organisation for t
ogical satellite data to end users for purposes such as operational monitoring o he Exploitation of Meteorological Satellites (EUMETSAT) that delivers
f climate and detection of global climate changes. EUMETCast Terrestrial connec meteorological satellite data to end users for purposes such as
ts to the GEANT network, which provides TreeDN services to deliver this real-tim operational monitoring of climates and detection of global climate
e data natively to end users on multicast-enabled networks as well as to end use changes. EUMETCast Terrestrial connects to the GEANT network, which
rs on unicast-only networks via a global deployment of AMT relays. Details of t provides TreeDN services to deliver this real-time data natively to end
he EUMETCast Terrestrial service over the GEANT TreeDN network are described in users on multicast-enabled networks and to end users on
<xref target="EUMETCast-TERRESTRIAL-over-AMT"/>. Additional details on how this unicast-only networks via a global deployment of AMT relays. Details of
deployment uses encryption, authorization, reliability and unicast feedback cha the EUMETCast Terrestrial service over the GEANT TreeDN network are
nnels for end-to-end file delivery monitoring can be found in <xref target="EUME described in <xref target="EUMETCast-TERRESTRIAL-AMT"/>.
TSAT-TERRESTRIAL"/>.</t> Additional details on how this deployment uses encryption,
<t>The Multicast Menu is a web-based portal that lists and can launch acti authorization, reliability, and unicast feedback channels for end-to-end
ve multicast streams that are available on a global TreeDN network of various re file delivery monitoring can be found in <xref
search and educations networks. Details of the this TreeDN network, as well as target="EUMETSAT-TERRESTRIAL"/>.</t>
the Multicast Menu, are described in <xref target="Multicast-Menu"/>.</t>
<t>The RARE network is a global testbed interconnecting several national r <t>The Multicast Menu is a web-based portal that can list and launch
esearch and education networks (NRENs) via routers running BIER. AMT relays are active multicast streams that are available on a global TreeDN network
deployed to deliver multicast traffic from sources on the RARE network to recei of various research and education networks. Details of this TreeDN
vers on unicast-only networks across the Internet. Details of the RARE network network, as well as the Multicast Menu, are described in <xref
are described in <xref target="BIER-AMT-Deployment"/>.</t> target="Multicast-Menu"/>.</t>
<t>The RARE network is a global testbed interconnecting several National
Research and Education Networks (NRENs) via routers running BIER. AMT
relays are deployed to deliver multicast traffic from sources on the
RARE network to receivers on unicast-only networks across the Internet.
Details of the RARE network are described in <xref
target="BIER-AMT-Deployment"/>.</t>
</section> </section>
<section anchor="operational-considerations"> <section anchor="operational-considerations">
<name>Operational Considerations</name> <name>Operational Considerations</name>
<t>TreeDN is essentially the synthesis of SSM plus overlay networking tech <t>TreeDN is essentially the synthesis of SSM plus overlay networking
nologies like AMT. As such, any existing tools to manage, operate and troublesh technologies like AMT. As such, any existing tools to manage, operate,
oot a PIM-SSM domain and AMT deployment can be used to manage a TreeDN deploymen and troubleshoot a PIM-SSM domain and an AMT deployment can be used to
t. Protocol error handling for PIM-SSM can be found in <xref target="RFC4607"/> manage a TreeDN deployment. Protocol error handling for PIM-SSM can be
and in section 4.8 of <xref target="RFC7761"/> and for AMT in <xref target="RFC found in <xref target="RFC4607"/> and in <xref target="RFC7761"
7450"/>.</t> sectionFormat="of" section="4.8"/>; for AMT, it can be found in <xref
<t>One potential operational benefit of a multicast-based approach like Tr target="RFC7450"/>.</t>
eeDN over traditional, unicast-based CDNs is the visibility that multicast state <t>One potential operational benefit of a multicast-based approach like
provides in the routing infrastructure. That is, multicast routers maintain a TreeDN over a traditional, unicast-based CDN is the visibility that
forwarding cache of multicast flows that usually includes the source address, gr multicast state provides in the routing infrastructure. That is,
oup address, incoming/outgoing interfaces and forwarding rate. Generally speaki multicast routers maintain a forwarding cache of multicast flows that
ng, such flow state information is not typically available in core networks for usually includes the source address, group address, incoming/outgoing
unicast, so additional tools outside the routing infrastructure are usually requ interfaces, and forwarding rate. Generally speaking, such flow state
ired for monitoring CDN performance and troubleshooting issues like packet loss information is not typically available in core networks for unicast, so
location. Of course, this benefit comes at a cost of additional state being mai additional tools outside the routing infrastructure are usually required
ntained in the routers for multicast.</t> for monitoring CDN performance and troubleshooting issues like packet
<t>Additionally, since multicast leverages reverse-path forwarding (RPF), loss location. Of course, this benefit comes at a cost of additional
the source of the content can potentially have a greater influence over the path state being maintained in the routers for multicast.</t>
taken through the network from source to native receivers/AMT relays. That is,
the BGP peer advertising the reachability of the source's subnet can do so in w <!-- [rfced] May we update the text below for clarity? Please let us
ays that can prefer a particular path through the network for multicast distribu know if it changes the sentence's intended meaning.
tion that are not as easy to accomplish with traditional, destination-based unic
ast routing.</t> Original:
That is, the BGP peer advertising the
reachability of the source's subnet can do so in ways that can prefer
a particular path through the network for multicast distribution that
are not as easy to accomplish with traditional, destination-based
unicast routing.
Perhaps:
That is, the BGP peer advertising the
reachability of the source's subnet can do so in ways where
a particular path through the network is preferred for
multicast distribution; these methods are not as easy to
accomplish with traditional, destination-based unicast
routing.
-->
<t>Additionally, since multicast leverages Reverse Path Forwarding
(RPF), the source of the content can potentially have a greater
influence over the path taken through the network from source to native
receivers/AMT relays. That is, the BGP peer advertising the
reachability of the source's subnet can do so in ways that can prefer a
particular path through the network for multicast distribution that are
not as easy to accomplish with traditional, destination-based unicast
routing.</t>
</section> </section>
<section anchor="security-consideration"> <section anchor="security-consideration">
<name>Security Consideration</name> <name>Security Consideration</name>
<t>Since TreeDN is essentially the synthesis of SSM plus overlay networkin <t>Since TreeDN is essentially the synthesis of SSM plus overlay
g technologies like AMT, the TreeDN architecture introduces no new security thre networking technologies like AMT, the TreeDN architecture introduces no
ats that are not already documented in SSM and the overlay technologies that com new security threats that are not already documented in SSM and the
prise it. In particular, Section 6 of <xref target="RFC7450"/> candidly notes t overlay technologies that comprise it. In particular, <xref
hat AMT, like UDP, IGMP and MLD, provides no mechanisms for ensuring message del target="RFC7450" sectionFormat="of" section="6"/> candidly notes that
ivery or integrity, nor does it provide confidentiality, since sources/groups jo AMT, like UDP, IGMP, and MLD, provides no mechanisms for ensuring message
ined through IGMP/MLD could be associated with the particular content being requ delivery or integrity, nor does it provide confidentiality, since
ested.</t> sources/groups joined through IGMP/MLD could be associated with the
<t><xref target="RFC4609"/> and <xref target="RFC8815"/> describes the add particular content being requested.</t>
itional security benefits of using SSM instead of ASM.</t> <t><xref target="RFC4609"/> and <xref target="RFC8815"/> describe the
additional security benefits of using SSM instead of ASM.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document has no IANA actions.</t> <t>This document has no IANA actions.</t>
</section> </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, La
uren Delwiche, Natalie Landsberg, Wayne Brassem, Jake Holland, Andrew Gallo, Cas
ey Russell, Janus Varmarken, Csaba Mate, Frederic Loui, Max Franke, Todor Moskov
, Erik Herz, Bradley Cao, Katie Merrill, Karel Hendrych, Haruna Oseni and Isabel
le Xiong. 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, Vinod Kumar, Ron Bonica, Jeffrey Zhang and Eric Vyncke for their tho
ughtful reviews and suggestions, Chris Lemmons for his detailed shepherd review
and Stephen Farrell, Magnus Westerlund, Reese Enghardt, Jurgen Schonwalder, Carl
os Pignataro, Erik Kline, Gunter Van de Velde, Warren Kumari and Zaheduzzaman Sa
rker for their last call reviews.</t>
</section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-bess-bgp-multicast" to="BGP-MULTICAST"/>
<displayreference target="I-D.jholland-quic-multicast" to="QUIC-Multicast"/>
<displayreference target="I-D.ietf-ipsecme-g-ikev2" to="GKM-IKEv2"/>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC7761" target="https://www.rfc-editor.org/info/rfc7
761" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7761.xml"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
<front> 19.xml"/>
<title>Protocol Independent Multicast - Sparse Mode (PIM-SM): Protoc <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
ol Specification (Revised)</title> 74.xml"/>
<author fullname="B. Fenner" initials="B." surname="Fenner"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.77
<author fullname="M. Handley" initials="M." surname="Handley"/> 61.xml"/>
<author fullname="H. Holbrook" initials="H." surname="Holbrook"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.63
<author fullname="I. Kouvelas" initials="I." surname="Kouvelas"/> 88.xml"/>
<author fullname="R. Parekh" initials="R." surname="Parekh"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.74
<author fullname="Z. Zhang" initials="Z." surname="Zhang"/> 50.xml"/>
<author fullname="L. Zheng" initials="L." surname="Zheng"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.46
<date month="March" year="2016"/> 07.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.33
<t>This document specifies Protocol Independent Multicast - Sparse 76.xml"/>
Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlyi <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.38
ng unicast routing information base or a separate multicast-capable routing info 10.xml"/>
rmation 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 Ro
uter features and authentication using IPsec that lack sufficient deployment exp
erience (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/rfc6
388" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6388.xml">
<front>
<title>Label Distribution Protocol Extensions for Point-to-Multipoin
t 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="Min
ei"/>
<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 Pr
otocol (LDP) for the setup of point-to-multipoint (P2MP) and multipoint-to-multi
point (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 construc
tion protocol. Protocol elements and procedures for this solution are described
for building such LSPs in a receiver-initiated manner. There can be various appl
ications 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 thi
s 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/rfc7
450" 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 ne
twork to receivers that lack multicast connectivity to the source network. The p
rotocol uses UDP encapsulation and unicast replication to provide this functiona
lity.</t>
<t>The AMT protocol is specifically designed to support rapid depl
oyment 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="RFC4607" target="https://www.rfc-editor.org/info/rfc4
607" 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.25
5.255.255) range are designated as source-specific multicast (SSM) destination a
ddresses 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-sp
ecific multicast use. This document defines an extension to the Internet network
service that applies to datagrams sent to SSM addresses and defines the host an
d 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="RFC3376" target="https://www.rfc-editor.org/info/rfc3
376" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3376.xml">
<front>
<title>Internet Group Management Protocol, Version 3</title>
<author fullname="B. Cain" initials="B." surname="Cain"/>
<author fullname="S. Deering" initials="S." surname="Deering"/>
<author fullname="I. Kouvelas" initials="I." surname="Kouvelas"/>
<author fullname="B. Fenner" initials="B." surname="Fenner"/>
<author fullname="A. Thyagarajan" initials="A." surname="Thyagarajan
"/>
<date month="October" year="2002"/>
</front>
<seriesInfo name="RFC" value="3376"/>
<seriesInfo name="DOI" value="10.17487/RFC3376"/>
</reference>
<reference anchor="RFC3810" target="https://www.rfc-editor.org/info/rfc3
810" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3810.xml">
<front>
<title>Multicast Listener Discovery Version 2 (MLDv2) for IPv6</titl
e>
<author fullname="R. Vida" initials="R." role="editor" surname="Vida
"/>
<author fullname="L. Costa" initials="L." role="editor" surname="Cos
ta"/>
<date month="June" year="2004"/>
<abstract>
<t>This document updates RFC 2710, and it specifies Version 2 of t
he ulticast Listener Discovery Protocol (MLDv2). MLD is used by an IPv6 router t
o discover the presence of multicast listeners on directly attached links, and t
o discover which multicast addresses are of interest to those neighboring nodes.
MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the ability for a
node to report interest in listening to packets with a particular multicast addr
ess only from specific source addresses or from all sources except for specific
source addresses. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3810"/>
<seriesInfo name="DOI" value="10.17487/RFC3810"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="BROADCAST-DELAY" target="https://en.wikipedia.org/wik
i/Broadcast_delay"> <!-- [BROADCAST-DELAY] Added date-specific URL for Wikipedia entry -->
<reference anchor="BROADCAST-DELAY" target="https://en.wikipedia.org/w/i
ndex.php?title=Broadcast_delay&amp;oldid=1225656951">
<front> <front>
<title>Broadcast Delay</title> <title>Broadcast delay</title>
<author> <author>
<organization/> <organization>Wikipedia</organization>
</author> </author>
<date>n.d.</date> <date month="May" year="2024"/>
</front> </front>
<seriesInfo name="Wikipedia" value=""/>
</reference> </reference>
<!-- [EUMETSAT-TERRESTRIAL] -->
<reference anchor="EUMETSAT-TERRESTRIAL" target="https://datatracker.iet f.org/meeting/110/materials/slides-110-mboned-eumetsat-multicast-over-the-mbone- 00"> <reference anchor="EUMETSAT-TERRESTRIAL" target="https://datatracker.iet f.org/meeting/110/materials/slides-110-mboned-eumetsat-multicast-over-the-mbone- 00">
<front> <front>
<title>EUMETSAT Terrestrial Service</title> <title>EUMETSAT Terrestrial Service</title>
<author> <author fullname="Oriol Espanyol">
<organization/> <organization/>
</author> </author>
<date>n.d.</date> <date month="February" year="2021"/>
</front> </front>
<seriesInfo name="IETF110 Proceedings" value=""/> <refcontent>IETF 110 Proceedings</refcontent>
</reference> </reference>
<reference anchor="EUMETCast-TERRESTRIAL-over-AMT" target="https://datat
racker.ietf.org/meeting/115/materials/slides-115-mboned-eumetcast-over-amt"> <!-- [EUMETCast-TERRESTRIAL-AMT] -->
<reference anchor="EUMETCast-TERRESTRIAL-AMT" target="https://datatracke
r.ietf.org/meeting/115/materials/slides-115-mboned-eumetcast-over-amt">
<front> <front>
<title>EUMETCast Terrestrial over AMT</title> <title>EUMETCast Terrestrial over AMT</title>
<author> <author fullname="Ruth Britton"/>
<organization/> <author fullname="Rich Adam"/>
</author> <date month="September" year="2022"/>
<date>n.d.</date>
</front> </front>
<seriesInfo name="IETF115 Proceedings" value=""/> <refcontent>IETF 115 Proceedings</refcontent>
</reference> </reference>
<!-- [DVB-MABR] -->
<reference anchor="DVB-MABR" target="https://dvb.org/wp-content/uploads/ 2022/01/A176r3_Adaptive-Media-Streaming-over-IP-Multicast_Interim-Draft-TS-103-7 69-v121_March_2023.pdf"> <reference anchor="DVB-MABR" target="https://dvb.org/wp-content/uploads/ 2022/01/A176r3_Adaptive-Media-Streaming-over-IP-Multicast_Interim-Draft-TS-103-7 69-v121_March_2023.pdf">
<front> <front>
<title>Adaptive media streaming over IP multicast</title> <title>Adaptive media streaming over IP multicast</title>
<author> <author>
<organization/> <organization>DVB Project</organization>
</author> </author>
<date>n.d.</date> <date month="March" year="2023"/>
</front> </front>
<seriesInfo name="DVB Document A176 Rev.3 (Fourth edition)" value=""/> <refcontent>DVB Document A176 Rev.3 (Fourth edition)</refcontent>
</reference> </reference>
<!-- [MAUD] -->
<reference anchor="MAUD" target="https://www.ibc.org/technical-papers/ib c2023-tech-papers-multicast-assisted-unicast-delivery/10235.article"> <reference anchor="MAUD" target="https://www.ibc.org/technical-papers/ib c2023-tech-papers-multicast-assisted-unicast-delivery/10235.article">
<front> <front>
<title>Multicast-Assisted Unicast Delivery</title> <title>Multicast-Assisted Unicast Delivery</title>
<author> <author initials="M. E." surname="Nilsson"/>
<organization/> <author initials="R. S." surname="Turnbull"/>
</author> <author initials="T. S." surname="Stevens"/>
<date>n.d.</date> <author initials="S." surname="Appleby"/>
<date month="September" year="2023"/>
</front> </front>
<seriesInfo name="IBC2023 Tech Papers" value=""/> <refcontent>IBC2023 Tech Papers</refcontent>
</reference> </reference>
<!-- [Multicast-Menu] -->
<reference anchor="Multicast-Menu" target="https://datatracker.ietf.org/ meeting/114/materials/slides-114-mboned-offnet-sourcing-with-the-multicast-menu- 01"> <reference anchor="Multicast-Menu" target="https://datatracker.ietf.org/ meeting/114/materials/slides-114-mboned-offnet-sourcing-with-the-multicast-menu- 01">
<front> <front>
<title>Offnet Sourcing with the Multicast Menu</title> <title>Offnet Sourcing with the Multicast Menu</title>
<author> <author fullname="Lauren Delwiche"/>
<organization/> <date month="July" year="2022"/>
</author>
<date>n.d.</date>
</front> </front>
<seriesInfo name="IETF114 Proceedings" value=""/> <refcontent>IETF 114 Proceedings</refcontent>
</reference> </reference>
<!-- [BIER-AMT-Deployment] Please review - title appears to be different at the
URL: "BIER & AMT implementation" -->
<reference anchor="BIER-AMT-Deployment" target="https://datatracker.ietf .org/meeting/112/materials/slides-112-mboned-bier-amt-depolyment-in-geantrare-ne twork-00"> <reference anchor="BIER-AMT-Deployment" target="https://datatracker.ietf .org/meeting/112/materials/slides-112-mboned-bier-amt-depolyment-in-geantrare-ne twork-00">
<front> <front>
<title>BIER + AMT Deployment in GEANT/RARE Network</title> <title>BIER + AMT Deployment in GEANT/RARE Network</title>
<author> <author fullname="Csaba Mate"/>
<organization/> <author fullname="Frederic Loui"/>
</author> <date month="November" year="2021"/>
<date>n.d.</date>
</front> </front>
<seriesInfo name="IETF112 Proceedings" value=""/> <refcontent>IETF 112 Proceedings</refcontent>
</reference> </reference>
<reference anchor="Algorhyme" target="https://en.wikipedia.org/wiki/Radi
a_Perlman#Spanning_Tree_Protocol"> <!-- [Algorhyme] Changed title to match page title of Wikipedia page - "Radia Pe
rlman". Added date-specific URL.
Note to PE: It may be worth mentioning to the authors that the poem the
authors are referring to is also available in Section 1.1 of RFC6325
(https://www.rfc-editor.org/rfc/rfc6325.html#section-1.1). Radia Perlman is
one of the authors of RFC6325.
-->
<reference anchor="Algorhyme" target="https://en.wikipedia.org/w/index.p
hp?title=Radia_Perlman&amp;oldid=1245484160">
<front> <front>
<title>Algorhyme</title> <title>Radia Perlman</title>
<author> <author>
<organization/> <organization>Wikipedia</organization>
</author> </author>
<date>n.d.</date> <date month="September" year="2024"/>
</front> </front>
<seriesInfo name="Wikipedia" value=""/>
</reference> </reference>
<!-- [Trees] Please review - missing author name-->
<reference anchor="Trees" target="https://www.poetryfoundation.org/poetr ymagazine/poems/12744/trees"> <reference anchor="Trees" target="https://www.poetryfoundation.org/poetr ymagazine/poems/12744/trees">
<front> <front>
<title>Trees</title> <title>Trees</title>
<author> <author fullname="Joyce Kilmer"/>
<organization/>
</author>
<date>n.d.</date>
</front>
<seriesInfo name="Poetry Foundation" value=""/>
</reference>
<reference anchor="RFC9049" target="https://www.rfc-editor.org/info/rfc9
049" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9049.xml">
<front>
<title>Path Aware Networking: Obstacles to Deployment (A Bestiary of
Roads Not Taken)</title>
<author fullname="S. Dawkins" initials="S." role="editor" surname="D
awkins"/>
<date month="June" year="2021"/>
<abstract>
<t>This document is a product of the Path Aware Networking Researc
h Group (PANRG). At the first meeting of the PANRG, the Research Group agreed to
catalog and analyze past efforts to develop and deploy Path Aware techniques, m
ost of which were unsuccessful or at most partially successful, in order to extr
act insights and lessons for Path Aware networking researchers.</t>
<t>This document contains that catalog and analysis.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9049"/>
<seriesInfo name="DOI" value="10.17487/RFC9049"/>
</reference>
<reference anchor="RFC9300" target="https://www.rfc-editor.org/info/rfc9
300" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9300.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"/>
<author fullname="A. Cabellos" initials="A." role="editor" surname="
Cabellos"/>
<date month="October" year="2022"/>
<abstract>
<t>This document describes the data plane protocol for the Locator
/ID Separation Protocol (LISP). LISP defines two namespaces: Endpoint Identifier
s (EIDs), which identify end hosts; and Routing Locators (RLOCs), which identify
network attachment points. With this, LISP effectively separates control from d
ata and allows routers to create overlay networks. LISP-capable routers exchange
encapsulated packets according to EID-to-RLOC mappings stored in a local Map-Ca
che.</t>
<t>LISP requires no change to either host protocol stacks or under
lay routers and offers Traffic Engineering (TE), multihoming, and mobility, amon
g other features.</t>
<t>This document obsoletes RFC 6830.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9300"/>
<seriesInfo name="DOI" value="10.17487/RFC9300"/>
</reference>
<reference anchor="RFC7716" target="https://www.rfc-editor.org/info/rfc7
716" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7716.xml">
<front>
<title>Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Proc
edures</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="Ros
en"/>
<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 t
hat a Service Provider (SP) may deploy in order to offer Multicast Virtual Priva
te Network (Multicast VPN or MVPN) service to its customers. Some of these proce
dures use BGP to distribute VPN-specific multicast routing information across a
backbone network. With a small number of relatively minor modifications, the sam
e BGP procedures can also be used to distribute multicast routing information th
at 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://datatrac
ker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-08" xml:base="https://bib.ie
tf.org/public/rfc/bibxml3/reference.I-D.ietf-bess-bgp-multicast.xml">
<front>
<title>BGP Based Multicast</title>
<author fullname="Zhaohui (Jeffrey) Zhang" initials="Z. J." surname=
"Zhang">
<organization>Juniper Networks</organization>
</author>
<author fullname="Lenny Giuliano" initials="L." surname="Giuliano">
<organization>Juniper Networks</organization>
</author>
<author fullname="Keyur Patel" initials="K." surname="Patel">
<organization>Arrcus</organization>
</author>
<author fullname="IJsbrand Wijnands" initials="I." surname="Wijnands
">
<organization>Arrcus</organization>
</author>
<author fullname="Mankamana Prasad Mishra" initials="M. P." surname=
"Mishra">
<organization>Cisco Systems</organization>
</author>
<author fullname="Arkadiy Gulko" initials="A." surname="Gulko">
<organization>EdwardJones</organization>
</author>
<date day="3" month="June" year="2024"/>
<abstract>
<t>This document specifies a BGP address family and related proced
ures 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 sou
rce discovery, and for showing interest in receiving particular multicast flows.
Taken together, these procedures allow BGP to be used as a replacement for othe
r multicast routing protocols, such as PIM or mLDP. The BGP procedures specified
here are based on the BGP multicast procedures that were originally designed fo
r use by providers of Multicast Virtual Private Network service. This document a
lso describes how various signaling mechanisms can be used to set up end-to-end
inter-region multicast trees.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-bess-bgp-multicast
-08"/>
</reference>
<reference anchor="RFC6513" target="https://www.rfc-editor.org/info/rfc6
513" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6513.xml">
<front>
<title>Multicast in MPLS/BGP IP VPNs</title>
<author fullname="E. Rosen" initials="E." role="editor" surname="Ros
en"/>
<author fullname="R. Aggarwal" initials="R." role="editor" surname="
Aggarwal"/>
<date month="February" year="2012"/>
<abstract>
<t>In order for IP multicast traffic within a BGP/MPLS IP VPN (Vir
tual Private Network) to travel from one VPN site to another, special protocols
and procedures must be implemented by the VPN Service Provider. These protocols
and procedures are specified in this document. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6513"/>
<seriesInfo name="DOI" value="10.17487/RFC6513"/>
</reference>
<reference anchor="RFC8279" target="https://www.rfc-editor.org/info/rfc8
279" 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="Ros
en"/>
<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 o
f multicast data packets. It provides optimal forwarding of multicast packets th
rough a "multicast domain". However, it does not require a protocol for explicit
ly building multicast distribution trees, nor does it require intermediate nodes
to maintain any per-flow state. This architecture is known as "Bit Index Explic
it Replication" (BIER). When a multicast data packet enters the domain, the ingr
ess 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 ro
uter 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 f
or 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 resul
ts in a considerable simplification.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8279"/>
<seriesInfo name="DOI" value="10.17487/RFC8279"/>
</reference>
<reference anchor="I-D.ietf-spring-sr-replication-segment" target="https
://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-replication-segment-19" xm
l:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-spring-sr-rep
lication-segment.xml">
<front>
<title>SR Replication segment for Multi-point Service Delivery</titl
e>
<author fullname="Daniel Voyer" initials="D." surname="Voyer">
<organization>Bell Canada</organization>
</author>
<author fullname="Clarence Filsfils" initials="C." surname="Filsfils
">
<organization>Cisco Systems, Inc.</organization>
</author>
<author fullname="Rishabh Parekh" initials="R." surname="Parekh">
<organization>Cisco Systems, Inc.</organization>
</author>
<author fullname="Hooman Bidgoli" initials="H." surname="Bidgoli">
<organization>Nokia</organization>
</author>
<author fullname="Zhaohui (Jeffrey) Zhang" initials="Z. J." surname=
"Zhang">
<organization>Juniper Networks</organization>
</author>
<date day="28" month="August" year="2023"/>
<abstract>
<t>This document describes the Segment Routing Replication segment
for Multi-point service delivery. A Replication segment allows a packet to be r
eplicated from a Replication node to Downstream nodes.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-spring-sr-replicat
ion-segment-19"/>
</reference>
<reference anchor="RFC8815" target="https://www.rfc-editor.org/info/rfc8
815" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8815.xml">
<front>
<title>Deprecating Any-Source Multicast (ASM) for Interdomain Multic
ast</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 M
ulticast (ASM) for interdomain multicast. It recommends the use of Source-Specif
ic Multicast (SSM) for interdomain multicast applications and recommends that ho
sts and routers in these deployments fully support SSM. The recommendations in t
his document do not preclude the continued use of ASM within a single organizati
on or domain and are especially easy to adopt in existing deployments of intrado
main 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>
<reference anchor="RFC5740" target="https://www.rfc-editor.org/info/rfc5
740" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5740.xml">
<front>
<title>NACK-Oriented Reliable Multicast (NORM) Transport Protocol</t
itle>
<author fullname="B. Adamson" initials="B." surname="Adamson"/>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<author fullname="M. Handley" initials="M." surname="Handley"/>
<author fullname="J. Macker" initials="J." surname="Macker"/>
<date month="November" year="2009"/>
<abstract>
<t>This document describes the messages and procedures of the Nega
tive- ACKnowledgment (NACK) Oriented Reliable Multicast (NORM) protocol. This pr
otocol can provide end-to-end reliable transport of bulk data objects or streams
over generic IP multicast routing and forwarding services. NORM uses a selectiv
e, negative acknowledgment mechanism for transport reliability and offers additi
onal protocol mechanisms to allow for operation with minimal a priori coordinati
on among senders and receivers. A congestion control scheme is specified to allo
w the NORM protocol to fairly share available network bandwidth with other trans
port protocols such as Transmission Control Protocol (TCP). It is capable of ope
rating with both reciprocal multicast routing among senders and receivers and wi
th asymmetric connectivity (possibly a unicast return path) between the senders
and receivers. The protocol offers a number of features to allow different types
of applications or possibly other higher-level transport protocols to utilize i
ts service in different ways. The protocol leverages the use of FEC-based (forwa
rd error correction) repair and other IETF Reliable Multicast Transport (RMT) bu
ilding blocks in its design. This document obsoletes RFC 3940. [STANDARDS-TRACK]
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5740"/>
<seriesInfo name="DOI" value="10.17487/RFC5740"/>
</reference>
<reference anchor="RFC9000" target="https://www.rfc-editor.org/info/rfc9
000" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml">
<front>
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
<author fullname="J. Iyengar" initials="J." role="editor" surname="I
yengar"/>
<author fullname="M. Thomson" initials="M." role="editor" surname="T
homson"/>
<date month="May" year="2021"/>
<abstract>
<t>This document defines the core of the QUIC transport protocol.
QUIC provides applications with flow-controlled streams for structured communica
tion, low-latency connection establishment, and network path migration. QUIC inc
ludes security measures that ensure confidentiality, integrity, and availability
in a range of deployment circumstances. Accompanying documents describe the int
egration of TLS for key negotiation, loss detection, and an exemplary congestion
control algorithm.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9000"/>
<seriesInfo name="DOI" value="10.17487/RFC9000"/>
</reference>
<reference anchor="I-D.jholland-quic-multicast" target="https://datatrac
ker.ietf.org/doc/html/draft-jholland-quic-multicast-05" xml:base="https://bib.ie
tf.org/public/rfc/bibxml3/reference.I-D.jholland-quic-multicast.xml">
<front>
<title>Multicast Extension for QUIC</title>
<author fullname="Jake Holland" initials="J." surname="Holland">
<organization>Akamai Technologies, Inc.</organization>
</author>
<author fullname="Lucas Pardue" initials="L." surname="Pardue"/>
<author fullname="Max Franke" initials="M." surname="Franke">
<organization>TU Berlin</organization>
</author>
<date day="7" month="July" year="2024"/>
<abstract>
<t>This document defines a multicast extension to QUIC to enable t
he efficient use of multicast-capable networks to send identical data streams to
many clients at once, coordinated through individual unicast QUIC connections.<
/t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-jholland-quic-multicast
-05"/>
</reference>
<reference anchor="RFC8085" target="https://www.rfc-editor.org/info/rfc8
085" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml">
<front>
<title>UDP Usage Guidelines</title>
<author fullname="L. Eggert" initials="L." surname="Eggert"/>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst"/>
<author fullname="G. Shepherd" initials="G." surname="Shepherd"/>
<date month="March" year="2017"/>
<abstract>
<t>The User Datagram Protocol (UDP) provides a minimal message-pas
sing transport that has no inherent congestion control mechanisms. This document
provides guidelines on the use of UDP for the designers of applications, tunnel
s, and other protocols that use UDP. Congestion control guidelines are a primary
focus, but the document also provides guidance on other topics, including messa
ge sizes, reliability, checksums, middlebox traversal, the use of Explicit Conge
stion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports
.</t>
<t>Because congestion control is critical to the stable operation
of the Internet, applications and other protocols that choose to use UDP as an I
nternet transport must employ mechanisms to prevent congestion collapse and to e
stablish some degree of fairness with concurrent traffic. They may also need to
implement additional mechanisms, depending on how they use UDP.</t>
<t>Some guidance is also applicable to the design of other protoco
ls (e.g., protocols layered directly on IP or via IP-based tunnels), especially
when these protocols do not themselves provide congestion control.</t>
<t>This document obsoletes RFC 5405 and adds guidelines for multic
ast UDP usage.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="145"/>
<seriesInfo name="RFC" value="8085"/>
<seriesInfo name="DOI" value="10.17487/RFC8085"/>
</reference>
<reference anchor="RFC8777" target="https://www.rfc-editor.org/info/rfc8
777" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8777.xml">
<front>
<title>DNS Reverse IP Automatic Multicast Tunneling (AMT) Discovery<
/title>
<author fullname="J. Holland" initials="J." surname="Holland"/>
<date month="April" year="2020"/>
<abstract>
<t>This document updates RFC 7450, "Automatic Multicast Tunneling"
(or AMT), by modifying the relay discovery process. A new DNS resource record n
amed AMTRELAY is defined for publishing AMT relays for source-specific multicast
channels. The reverse IP DNS zone for a multicast sender's IP address is config
ured to use AMTRELAY resource records to advertise a set of AMT relays that can
receive and forward multicast traffic from that sender over an AMT tunnel. Other
extensions and clarifications to the relay discovery process are also defined.<
/t>
</abstract>
</front>
<seriesInfo name="RFC" value="8777"/>
<seriesInfo name="DOI" value="10.17487/RFC8777"/>
</reference>
<reference anchor="I-D.ietf-ipsecme-g-ikev2" target="https://datatracker
.ietf.org/api/v1/doc/document/draft-ietf-ipsecme-g-ikev2/" xml:base="https://bib
.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-ipsecme-g-ikev2.xml">
<front>
<title>Group Key Management using IKEv2</title>
<author fullname="Valery Smyslov"/>
<author fullname="Brian Weis"/>
<date day="21" month="August" year="2024"/>
<abstract>
<t>This document presents an extension to the Internet Key Exchang
e
version 2 (IKEv2) protocol for the purpose of a group key management.
The protocol is in conformance with the Multicast Security (MSEC) key
management architecture, which contains two components: member
registration and group rekeying. Both components are required for a
GCKS (Group Controller/Key Server) to provide authorized Group
Members (GMs) with IPsec group security associations. The group
members then exchange IP multicast or other group traffic as IPsec
packets.</t>
<t>This document obsoletes RFC 6407. This documents also updates
RFC
7296 by renaming a transform type 5 from "Extended Sequence Numbers
(ESN)" to the "Replay Protection (RP)" and by renaming IKEv2
authentication method 0 from "Reserved" to "NONE".</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-ipsecme-g-ikev2-13
"/>
</reference>
<reference anchor="RFC4609" target="https://www.rfc-editor.org/info/rfc4
609" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4609.xml">
<front>
<title>Protocol Independent Multicast - Sparse Mode (PIM-SM) Multica
st Routing Security Issues and Enhancements</title>
<author fullname="P. Savola" initials="P." surname="Savola"/>
<author fullname="R. Lehtonen" initials="R." surname="Lehtonen"/>
<author fullname="D. Meyer" initials="D." surname="Meyer"/>
<date month="October" year="2006"/>
<abstract>
<t>This memo describes security threats for the larger (intra-doma
in or inter-domain) multicast routing infrastructures. Only Protocol Independent
Multicast - Sparse Mode (PIM-SM) is analyzed, in its three main operational mod
es: the traditional Any-Source Multicast (ASM) model, the source-specific multic
ast (SSM) model, and the ASM model enhanced by the Embedded Rendezvous Point (Em
bedded-RP) group-to-RP mapping mechanism. This memo also describes enhancements
to the protocol operations that mitigate the identified threats. This memo provi
des information for the Internet community.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="4609"/> <refcontent>Poetry Foundation</refcontent>
<seriesInfo name="DOI" value="10.17487/RFC4609"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
049.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
300.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
716.xml"/>
<!-- [I-D.ietf-bess-bgp-multicast] IESG state: I-D Expired as of 12/16/24-->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.
ietf-bess-bgp-multicast"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
513.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
279.xml"/>
<!-- [I-D.ietf-spring-sr-replication-segment] Published as RFC 9524-->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
524.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
815.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
740.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
000.xml"/>
<!-- [I-D.jholland-quic-multicast] IESG state: I-D Exists as of 12/16/24-->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.
jholland-quic-multicast"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
085.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
777.xml"/>
<!-- [I-D.ietf-ipsecme-g-ikev2] IESG state: IESG Eval as of 12/16/24-->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.
ietf-ipsecme-g-ikev2"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
609.xml"/>
</references> </references>
</references> </references>
<?line 251?>
<section anchor="netverses"> <section anchor="netverses">
<name>Netverses</name> <name>Netverses</name>
<t>With inspiration from (and apologies to) Radia Perlman <xref target="Al gorhyme"/> and Joyce Kilmer <xref target="Trees"/>, the following poem is not in tended to provide any normative or informative technical value on TreeDN beyond (mild) amusement for the reader who made it this far in the document:</t> <t>With inspiration from (and apologies to) Radia Perlman <xref target="Al gorhyme"/> and Joyce Kilmer <xref target="Trees"/>, the following poem is not in tended to provide any normative or informative technical value on TreeDN beyond (mild) amusement for the reader who made it this far in the document:</t>
<t>I think that I shall never see<br/> <t>I think that I shall never see<br/>
A CDN more lovely than a tree.</t> A CDN more lovely than a tree.</t>
<t>A tree whose crucial property<br/> <t>A tree whose crucial property<br/>
Is efficient mass-audience delivery.</t> Is efficient mass-audience delivery.</t>
<t>Using SSM for simplified operation<br/> <t>Using SSM for simplified operation<br/>
Of native branches that eliminate duplication.</t> Of native branches that eliminate duplication.</t>
<t>A tree extended by AMT,<br/> <t>A tree extended by AMT,<br/>
Enabling unicast-only receivers full delivery.</t> Enabling unicast-only receivers full delivery.</t>
<t>A tree that scales to reach millions of places<br/> <t>A tree that scales to reach millions of places<br/>
To viably support the highest of bitrate use cases.</t> To viably support the highest of bitrate use cases.</t>
<t>A CDN is built by folks like me,<br/> <t>A CDN is built by folks like me,<br/>
But only end users can generate enough demand to necessitate a tree.</t> But only end users can generate enough demand to necessitate a tree.</t>
</section> </section>
</back>
<!-- ##markdown-source:
H4sIAAAAAAAAA81963Ibx5Lmf0Scd6iRY+NQITRvuloRE3MgUpJpkRKHpOTd
mdlwFNAFoM2+TV8IwbLeZZ9ln2zzy6yqrm4AlI/XZ2IYYYsEu6uysvLy5aWK
URSNmqRJzUt1Uxlz+j7if6Oprk2sTk7f12peVOo8uTPquqmMzpJ8oZpCXei6
VpM2Tkw+M/VIT6eVuXODjOJiluuMBo0rPW+ixDTzKCvKOqIhTJxHh89HM92Y
RVGtX6oknxejpKxeqqZq6+b48PD7w+NRzbO9VGevb96MNH3/Un0o69GqqG4X
VdGWL9XFh8vr0a1Z00fxS5W1aZPMdN2M1fX1xVhNLm7G6vzs+nKMZYzV5dlF
RL8YjXTbLIvq5UipiP5TNH39Up3vq7dJmyY6L/hDof7c5Pm6/4uiWrxUP7Z5
UppKvTcN6Kn5NyDYNC/V8fHTI3VSVGVR0RLVpa5u1WlFDOSnZklDS/7BVHlc
5GP1aaKOD4+eH8nvijZvwJGP1xP+wGQ6SV+qFGT87ReZdD83TZ/2k30Qqqsm
oPxkWSV1+DHT/clUya9FPiD38PBInRdtTLMT3UTCmole6XVA8aReTtvKU/zk
+b0UzzD9fsrT/+1OZt2fFVmf8Kt9NYl1FpB9lcyW3WdM89vXk/c3IcX8faRO
iCz1Q9HWxn5wdPwsOnp8qH5I0rRWV4WOA/JPdDatknhhN6GIwaNXx+ro8l8H
C3kXrqMienQV72si6W8Lo/Nmn4gakXDqPP5Zp0VO45BklMlL9e9NMRuruqiI
zHlN360zfPO/R6O8qDLdkAS8HI0g7P4npV5dfZicnkyub6LT1+eT/yWLa3S1
wNYsm6asXx4cmHx/ldzS5seJxvwH+OngVUVLhMD/HJvU7pVVZf8rdep/VdMu
mBrTyyRKPfjJDfqAPxHC3G8vT9/8/RS8/njx+uZ6chPdvL66en19c3U2Od++
plg3uqn07JYkGuaBR81of8m+HBwdHR4QKUSxTuuDOk1iU0f0YZRNieNxZNrM
NLVuIq/0UUFSFjVLI49Eh4chPxxZ6sZUlSE5onHVtanukpnZxRzYHZpSXVbF
jGwWkVV/k03/FYvitZzgtwGP5UkyeX+I2U+30fW0R1dHjs6aDdaCnB5v8SQs
8P3MffpnMvcPLOL006voYvLqagfT7qYi6mU0K/LG5M1BW6Yk8fXB8eHx8cHh
0cHk6Pmz6vHPZLBKKHR0Af2IvJ+Uuc4uowu3oz+f5aAxi07ZL95cR0eHj6Pn
z76P7o6Oj36+0NVs+TON/ni/jOchm90UKsMUqvaumDl9dtm5v10sp8Wq02JG
fMgbBcLVlbnbf6z23hRt1SwVjdskRf7w2/vw34AvF5OPp9t3bbVa7SfTGVPY
mNkyp/HTqNTkOesD+gUGifAL+1mgbYRokrohYWlz+YCsGlFfrQ+O6KWn++TL
kllqwm3xC4gm9mX1UV6G5eWXd6rAqxPQQmpDLu+Safkm6/9LFtet6cLk7R8y
KE+26eITp4vFfE4YJqpJ7maQhlXSLMXK+ZlJSNvo8Chk9Qd+S13btxTeUvRW
R68CvfdbnCd/psX5E1f56uz1Fcx3dGpIldbQ0T/E+ONtJB07kqaJmD7a+7JI
eZYoySPGNRVB7CgXPDvwniBOPYI5Vx15hOAEmh1cTa5eOyR8P/eP/0zu/5lL
naQUiSzpqb8Hf11p+vHnS1Olmc6/uy51nhNlPyMC+pnWSWiwSHsm3E3yj4Jj
v5Mg/FzvNp5lYQgIzwkP0waQQ+Dx5cNML/SvSW7wY1YfHB0/f/LkAKC8Dtd5
4z/YssZLHki98cP/Lpv3x2gajaIoUnpaQ4qa0WhSK3YzMCPaRq6qTn41EuMu
k8WSZIQeIBSjYByVuSO5qRW5LbLRbV5WZmZi+ojMfEq/ozCDwgA1TRpEerWa
pUk2RXBctyVFf4168u7gxbuDSbvI5KUro1OELXuTq4djmaLz5DOdqzLVRJOm
uZL/bI1q1qVRxZwfonC7LYtcWcEloti0mHpf2ahbUcSnVdML3xU8Z0IuoWkr
o0hJkgWpB2jUccyDwoTG5BqSfMYAoyaXwuQsdUoB3ILWRRQMaKX3MyQAHBsD
Iijmm6Z4iRyQboqqxsNkDAmmXJH1IMuHHSR/FBEiEAiu9q60vn6oNO2LmmOz
6AkmbFbQVtD0xGCBJzodK+fBuhxFBGtUFxm9QJ9R7EUj5bxE+5IMRIRgUBLI
it6vWmYKUX6W+0fxjJnPkxktq0nXqm2SNPkVS97gOx61TlSZz8zBhcAwMjr4
ScuAhGhovDFNjf0Jt4NMV+H5lZsV7zez2wIrFi+KcGVZNAKti4TwLqGwl4hb
kajSOumzgrw7jUIRszL0bpEBGNATdwkGpyF40zomimiUJQVwsyXv3huil94Y
92QpJnmHvSQWEKf7tBNleCArZrTNwiKGJEVaLNbYD7B6pddCddKQwNxCR+zK
IHJVMm2ZR1mBEWfEVFkGxAsflaYo6cfpGnkkBM2yqsrELWMAJyLMs6qTrn0l
up8lcUyYZvQdHA8NnKlr8ikG2jganX9DpFkhk4x4a5w+0nJp3TTbdjV8A/Z/
1hnR7LQbZgCjW0sy9YE543bQ700SJE+2m3RmqWuSJbI6abHCg0VK2gR7BUuV
FjQimYp10TZq2kK3WDhyCBB4RARGQitJQGyKbplE5afErPCC1+oBjUtNH/IU
U2NybJhIDUkAbUS3gsaQDUxqpzSfS5IMNn7G2I2RnSZRoMlTcg8ZsYVhW5FD
Ngl8qnoJO+nWgMV1E3BSgdUMMo+hSF7nOocFxdIKmqVSxfQXwwaDJd1NOq+K
DBLHIZLIok4qtYdvHtQYLaqhKbHM8kB9+TJIxXz9+pCY9RPIJW2qimhqGrBp
zHwSbX5KYYoKx2GZmUKAC2bhvnpFnxVZqaukRr5vtaR3V7ohTWLK3DZlxV3C
hisnTpLGKcT7UGeSsog2rm3MYMeJ/xBF4s4UilLNiQvEVWhR2TAvwM072WwY
ufmGyLAseRGAcTKirSB97N5VVSsMpCXcQmqmBrRrkshGXAl+udBkfVcJQw7y
IdBe3oOGlkNBa11reBL+aE6ogLWoIidjmBB+kkaZ6opWUBXWL0nGb6yEAaQ+
Zl4wjWbN1MGs0A9ZbdI70sC/jP4ymuQiFlZjkb4jf0JAhCzybIsno138pYCI
kl3Afi8TmNFd6sP7S9tdUxjN5gKD6QzJQ1aoDasw5nWAVrwtMAEbZ/etzgoi
l6WZZDxOZrxzRIfzjGS3QALUdUqGgWZbkBVvSZ0sABHnCA9DijYjMuEovHGB
qGLiJVED24sMTQmFFoNXUshtIiimJ3GpCc5AXgaC21+C42PIHjGYbLdnKRlN
NtS1ySCKyFiYUs3bXHw7WwGxb8Agfu0JwyPYvr4ppvmcNDZtbti9FKJHnfTp
RoQG32NNLA+X1l3Cq4uQN0Kj9/LBpnkHggl3unKxkDB4FZNH2pt8pv/XLXsw
Js5UGVOt46IUj9RL0kDsVsQ74lHMIRW9ThPMaaZ8hgSapakeWxb33GX3y/PH
ny7f+59ZjmaklppIAOKsaINrdk2vWizbginy+MbOm7HJh+JL7m5mVfrBCugv
jha6IsD7wE+xH+QHOjFbpMWUiPauDN5rrkmTeKwFyGksrBtjd9n+a+sBMppJ
sQ8SvvecYlJ3TIsEKsWy0fQbv8m/F/8KFBHbQuulgd2E5q5IW0eBiw1llFAs
MkI45IBq2lz5JX0GCSaLQP/qCk6SjdkKM4EN2BL8C5iGQemBlaEFW4BU0ro6
7GwxuREK5wh3sEHE2qSuW9EDPzJ5EDIMkD6/ITy1Eznn94abA4oc6KytmSm9
mcEbBUcvLTvaAOQCoX4LwjPQR3iPF50z9qPD/8G+9hXwGzCbQAcRkLES0gNx
KxRAthy0xpKaZUvjE17DZBYbdjoKznl0FTB8BhuXJvWSec5aadNK9IupU3wo
MkWKeHKegOMF8YQlRUtS1u+AZuDEg7iVQEsckJFIEmEkOMpA0kUzrBNkbsWR
hEqwPxqRMd7gmQ0yvxF1BKqRb1EGmGwRhq0ByBhGbQmV3R7EfjMuHG8NWvK/
fjtmsdLrxTZuTRfAOT7Qf0yuZSIZA4D9SckiIt4E9kG8OusbeTxNVscFVQqL
EnDbLKuiXSwBkFgSYpcsp+8Hy3TeQZLxTsz3sOrCWuyxmlyNGfiKfwVazjj3
gbzWQ8EFTgrDbeE0gChM4KNctpYxm87XflJmb26Mh4LOXMFOCizFi2KJmWhE
VIGobAYuSApRND1vVvALc7CuLWP2+3uGcOGHa/oZMMTUD7v57fT9+UBpF9SQ
zdMh7CdAERcrFvckk5XPNHYGWQrSNPqgAdfhP3aEXB85shU+2hDbb63F4mSw
45TNJEnyhhZN17wTdmwI0HeBhzvpkiDWYF+ixDK6gXkuUgrOBEOycWZYwDET
wxCkI6wmO6kLcirYx84F48EePtjlWmG6sMhEPArSVeQFHPM5elgSC9kqkVkj
BZ62HJURbltyIOmFiyXos8+K1M4BsscqGFv3/FG9bR3sfiMFfjyYkFujVb0n
REtceeBi7pf9lVXmP9uERgU2paHIMpoqekwzlrSCZgX2yfYyIZ2plBVugAEw
pCA7vkxoPNVOCfUnDfCeviMA4hDldldoBQYrJCPAxiczOkcuRlf0g1DIKcE5
8nI0inxEhoI+YwLntBZgJU88vjfMQuQlMtoLnw7UIRtoCMhOaROztFu3DPfl
pzPa1RJbS7LRiWOkrslD0EZckANSe9zScvGQYtd/unpz8vz5s6OvX7ED/EJJ
UU2jzvWUPNVpiB79HHvZ+emle/vZ4xcvvn514mU3iUUTQQV0X3N0xnjAi60D
VCWjO7HfnDLxeRwIMrlS4DQrJmfNX2vas0KdwPWaz4GgdDnDLgnBDposAFto
gPedLKwtD5krjGnZZa85Gp/JZGOXFCDpRuYotQgHFmcMlZgnC7LCeCyniFWQ
BU0EtLSkWG2A4vOB8bBLPFkms1sjqvR6EaoClND8VZRXDJIfzFn0qREjuPEo
o5AtaNj6Wqvqf+dbu6fboGwAtf8O2LwTK7OZi4mC2AhUht/dkaQuhYc12zWs
YEpvi8G2RE0CPxrQiki54vTDFhAHO9ytNBBtwX+A67vAnMPFLixkfAdzJRE3
pyUH+C4Io37aNuwYJFpEbd2XNW1bvHnnWAVV0+QF+U2G0Sy3nDRsHBj2Osqo
JGmSIJ6ACns8hjVpTxphv5gtsMG3u1wSjzG2gVW38W4tibfHYhWEbM4hl/7p
Okz9DKOWyiAU5WyBI7rT+0yvJQXvNLJFaJSug4DCZs+Ru2mSBum07jm93lck
LuqeLytKLh2z9dlH0f1fj7a+9dt90+L3O996L8FH5x4+5NF7YlX3VkDRo/5c
e7Yd8uGWuX4jyyx9Heo3/+o3KfxNXTARbprft67fpKBv7nvr0QYPh+vCz7/Z
D/y/XLC+4qzsbxubs30vQgrcv4+CQR/hY9vgEX2AQm/fHX7tUe9f+drvT2Or
5mrXLu8ex3/95r6xw24fx4qK3Vf3KRh00+Y5mUHPn/1v8efKI7J7v/bvVafd
X6AJX4/uIeH+r7eEVlB3+uMj+K+du/J7viyz/3+GcLwefXmpvpumxexWiuz/
/GBgj9Rrid4efEUA7B3iB+tWyEl+yI3zMmGdjo3ihp9MEO83BVfcAvsisgKj
ukfb5HHnk6eHjBzZo3HbdYd/dzlAHsFtFYWRcHbxOtcuCTBtkzRGrjdHkhue
lSF37ZD8JqBB6sTFW8537XkTQFME4UTg8W3ump2YUQFRNpu45MqyjYVnKQfj
5G6Rd5ZaGzIxSeMJ6xCAY4LgmpwcrmT/6SFZF9e7885Mje3AMrE8wjn/SrZp
MKFNd0+LCgJgV94tzIFSUSmNWLVWLh5nuoYZFo9fzBZUOvS/RsLJpUlQjwSq
cFk+F+4EmVu1p2/1WD0o5vNInLm1IQ8eukX3U5+7YklazXmS20x3bIAtrGOP
C0auLtQKMnJBHMA8tbAzkjJSLoU6IrtEtQI1d8Q5VSLBMqdDoRZpuhXYAD72
8opLlIv7mCN2IRNTvUEhZ8Q5J2zx1UbaVIaR8k9bbm7OmBfpsJXJfykkqTE1
uZknklDsUknhMgJMuUYeCJ2gphrbcN+/D+2U6TUSIWgKoFckidHFbKtl4bZh
bbZtReO6HRB9ifQlVVDN0OqWdsTOCqK5omUz4AE0pwhhRuGsibntQ6q/6sn+
Y7zy5cu/kE36/vDJ92yTPiDECTtJZrS360Ee2Voob26AhilqhYjGkiDCpvYa
WsznGee8gpGFQJ+Ola1lGcPucOIJ8alEnJYPQcJnyA7pS5GctO76MmgfDTfq
dBngehefON/mWzBWtgoR5GI95pesd9AfspcXeWT9xcNNqyKdBL5nRCxMXQy1
eFcczCLfT5TsKFY0Uu24c+0hHBQGNpN5O9OlpIxRm6a4jQMgF99mJptCN0ej
m64xq7PSiE5RgrWZfFCKpdsfO9kcRnZQiXlSwcA0jclKlm6uJLOBtyGhDJOy
5o9VMoe5CfTBFW5rZxHpoTnxZarh6Qss02Vk/Me+BDXMb9pMZhBQSXKNw/ZB
ixN7ads/MQQFiAs5kXJOZp3k/eDsVF0bcq96kD7C4aqHTuEeHxIIcCRJOUei
VBcl9zszNtx3ZzKLQCp4+9mCCwGyTFssrDfcvXWJKQ18IL0/B7JHGcXHD+93
FPvEpQ45WcAsERUY+L5n0jdtm8uqMj3yMsTIcCKhLHKb5JXhLdpw6dQw2+aW
1BsiqcOuQomYouvSzJAkDwDa3nWXDnzy7PA5m0Ab6QXoIjMVyySNOK0NzylJ
s7HL69yTp+xQSFuLBabBaZofihXw45gxxj3vB8oaVLBoDC88GBb2we1Fjxdd
RQrZy7F6KwbjhscMOPH25sLJ5vPnR89INqHar95e2vRU9yg9dBadcotxNCUT
E00XZdek/fXrmCtU6PnB2xcouMu4z54ePaZx4QSHHgKukD1NaNQcK6Q7h43z
p6s3DGluzSqpjfAO9SG06uRmA6h7g8/7SVY/bbmVgzu0hagXx8+/t4u9voou
jy8uewusS1Rno7qKAhgQ1YaLe4ECE4sk3UfkD5wytsoilW8KusiT9P/Buzj4
apNwHd6pSDJkzaglieXojHVn0QYZV2sc3YD2IeSbuW6cSSnY1hPipJ4VUkRz
/UbOcrCh5DlRtcEZPqyB9isqSCi4QcuZ3TExp5VEd77D4LLn5i3qIgK0JMEv
es/2FodY1QWnmVnznWEd45gmt9U9Vntnby8u7x47nX78+PkzK3Fnl3dPfK6f
5fgcadGc5jn163QDHau9i/PTu2M/zoujw26cZ7xwtiZrcYZSD/JFGD5v63Ox
G5GGhFBuL2yk4ewwF3ZsvYSmSTKumTawP95bDoeyVXSmAoVCQ36i1IxQjCEj
d0mxJxCLlGpFZHgx9VJzbhTt344eJ7kDaLKzCiGtT2HHQW+KfpJ7KFnjsMnG
1Ry4ADXvN/806AN0k8Dti3HmzlavFkNcyU2Ppcvp6q3BnoXwSry1tm2ADCNJ
IiUId42/Ttu5sR7iPMnXkc3HBaZ0AqdyatD9LlJuLc2Lo6fkYJB//0ZXyF9G
o5ONmIZBXQA5nUPhM+dN0PFkdte6e+lwqVsHnQdhXY9ExZ3EEYCmpZcxtC00
BjqGPInodcIeMEUW0vhYwUVNDGV7Wwt0QXy1TTi2bQFRVAr4RnMuoKXkD35H
hXLQ27+9oanL2wS9T4OF7ei4MZtF9RCzkV2llZFVRkF1Z5OJaIylwp1JBKTs
goVhLWcjvodo7wwXJNyH3xkOs1OLfbyk74okdgUkVwCxBftha4ptM95sqbId
r741RbYWitUXmJErOaE/q2aG0DbHd5ois4XvywzCrI2jDMOm/MoGkW45roNS
WnCs/nZqAHlnbGeDAX8uwW3zxtkHhyIlkBsE9IgKXeKth3sRf7nYZrwlotkg
LCayZo2LfX3daqsRB0X2yAE4YtM84420m8QF1Z2nLmhD4XNjZFZLtM/jm1lR
pLaIRuYkN67RUfAU7WZvnbOiTW2DOYBZ0Nphm38lDtFslmdt3RBsqDZC9utL
iRPl9Au3z5E5HOzhtj455PbKovHW61dTbZ5mSXIeErFDCQCBQw+TuDOng94v
2tZtDWCd8ch0w5VvnNWLBA4klmO2VRUoy9guMCdQvggXNNUhE+DbPOa6kiZf
2oEqdqbDdUtsy3fZdj7Du++kcVBlRL6LD78QZChAfxhE1dbnGcbSY3qqEgwT
AcpmHeSydqBGSquLNzwdNk6iwVa6IiNSQqi4OXqy8axNMXrvJD3COTrKuMuw
zaV7EeCeu6icqlgSW2Qp4B2gWjYRRS6smT20PTslCpqKvEXaCZxfp01HurZt
nNlhw3GfqQGSI74jjPCXlWCeigIFDceGPAg3v/AecHYxzBFIPp2Z3mvY+mP7
zCxDIkPiO3YLNXwr95/ZTR7b4Ihkzmb9MARtatRtameEE4QVgqd0mBaTwj9L
v5dSaBJUG3TZYjTzttI5H46wEULQ/+tTE3MMIk6VxAUqw+f0YIHvZT+LEZBj
W9ddu25thnRwjjaBCemOJYWgzSVAn3MGg4CaP7PFAxyc+jNavpnVoTF3mHrQ
Qw2ZgIrxmnafAeuahQagFZxzm+1Ql6T8KLzl0kPPBG9rT7HmhWNvbLNF2pHP
HgjEGNvUNIBx23B/R75IRe9dMOH7XLk5Eq6VjTe3w/LRzSpJ1wP0aIOAINfa
nTkrxBxz4EIvJd4gM5zUcrKH+3wDiz1IR467EBTn9EuZxsUNslZvv7tDdsH5
OY9mB1UceAFksZzcnnN/HXKl4PZpIEdONZ3VJh7e9E8I1q7RkURUaBu0xRa9
aNzqiE8DeF+a8TGEXR2vPoi3chyobdhDCdM9UMeossuK71/WN8ygIJslu3yc
3dK3bBXFMXeaKGe3umjM3pdlA0ExwBYCcN+rPYoqOm09ja8EOMppkpuTy+jj
6WVvEXyYz5EatCd1j2Bg2hV60Yei0onlDYTz7L1GKg5PF7p0BU+dZH5n/QbI
mTvuH3QpEXdMwuFJ3u8+Gq8ND9wrZ9XtYoHT1HMblcprHcKa2hYc4TngoE0J
AIQE0WxMLilJXe6hNvcZZvB4ataFdS4UmZdmQ3pZTb5jrVm47QXatc0do9E1
YwLEHIEt5DQTbQ/tjABakSnnyuec+WDNLnLjGqDHG16DUQVcRG8U0pOMt7zn
OLsGWOcth260y4hOcbjr1iDiIJYmNZvdfuO5UNcNKox15Wqg8uDQxLh/7Ihz
EbNqLdEP6SMuuSKuicWDA08WxKoDObKKrBnhRuKpLbEzmhlb2NaIiNRtYrUA
nA4qkZOaVzX2iX8feLvDZtsZtAml0Rvmsso+FeIO1j8IUnwPPDB3DXW8+7W8
Gvb7QW/IdPGeyXRcq5SbA0SxSET7Yw/Jv/7hw8fzU2U7L+XQ2gyF6NqmMCUn
yi1yLbJFzZYzSB6DWBJjLQcEemcwNlIWROFbSUEgF1saboi1vdDLNa5J22J6
fM6IU2rI632j7CTd0T39lXd/n2aSx0psbmTc3X70Sq5a4LFPOm6dCLeA/O61
9H2oxjr4w83N5bUE5mSIA7vCnOcoCc3ktrbubKrkaujZlnCDze/BjstcwQ5h
N6pwKbv22K3QXibRO7H9yh1JCWeUJDdfmeDQB3CQJCq81kDnHQ4qBJXIQcre
QT5edZYwDq19fttk3LTwEWUWWzvqTCGSWbU4OusbNM7mdsdpwuYDYo10JzNa
m2mufNN4OFJNjN8QWX6pl3zqzjG/kWhMva4q5F9wpFXc1t6b1ycPJU/W1Ugb
d1oOICqvG6khzltu53DVABqnLcGfp//DxngqRR+qNO4QhVVbil2Qx54cHtqt
DVyzZzQfFfnyZdtVeFyPez85eRd9gIWV01RpMqxdvf9w5YtXT58/Qaq+C9Np
lV2KD2fau6PwW8bqgCB3VEE6uI+sDk+CkNhETREZDujsEJ0isG5spJqR7PrX
j2cnvuGC678cPQgxZVFCVIOB2Ej9nrBIjmvx6HFh5EQPS2HSyAfwH7O2qnoH
4YJSbijb5jNZaBFsWjIP2mVzEO8Wtoxpy2S/LIs0JZ5GFBnOwjogjUqwwHeb
HHXdJi8OXzylxbu2lJqPz2hWR+BhtLZ1yWz2wrbR2Z/HCiogEudIyQVSzB0p
dSGS3Ds+yCN3RZTCWWlC21B9/zIElRVxJd5S/DebBw6nrGViQyciwUZkaJH8
s4kZCn/XRIdb5nClHnHG3a5nq5G4so0+xT/0id2VOzkBLXzbfkLRHVUNrKiE
xNIt6MljeuX2D58BCM84X3y8vrFnthyMGhriRYs8V5Kbut9iFGz6/pP9Y9n4
oPXx//6fQN56De2SOO5235542EKexQM+xbaNPreRLEKhzeYm/R0UW9H2Yhp0
Oi5sp+MAizSkE8jxSJaVz/LXkvJF1ELwwY3+uKcEz58/7ykBFIDdUolLv+K2
8g1jTZLxKQTUCGqCpzO7a+T2J3w5r0tVcCEgd5BzNJqEMifa1aWDYeVJOhrx
1Hnh2cbXYNSJk50pMgXiz4JzWnrtmx9d4tDXNTsSej0KnMquvaBKac3Sb8Kj
a2F3nm1jwjkzEg1yRDxVmN3kVoMEZ1qDwTpKOXmI1Jxknx/uIHvsk+sbmN09
aLEtkrM0f9glkJQUC2ZkhaLk1twd97c170wqFnT27vXdsU9Elm3FF+agzMUm
rJ9x/YdYCOmDwInCbp969dbOPAWHhbqr7OrRaPstpkkdHMfhwMlfJCutRAKo
sZuNKSqnNATmKegiYbNs7pU8wCjLpNoHbraoyx6RYErSFJU9ZowrxRzgJRBt
FQ/clUKh+z2M/YLTD9uXYhNutetp5av7uiybqIPFA7VjkUtq9IMfzvi5Y828
QN/l1lspQpXdbV5hz+vgre0N43cJuU237P7JWW+a2AP1UgU72OE21R+zFX64
hiN39EmuTOvMqkV1O2/fZeva1WC6tEXOkEDinI50bgjphHbsrYeWH4cuzwVy
c2Ni7gXsufgAxXHO3B8ZDyRqmDveCVMl89e/WlP0YWWmFq0BdGmbSMeZPBuB
awSAFEmj7jG4HcEBZB+3dofCOMlrd3ewDbj8hWIehAFo0YYBkEss4tb52aBp
drD/zPP+gBsN1/1ljrfte/9SVM8gvvvS11brbgnoWZGXG5x/ZeXjViRbFM6d
um9fUXBO4v3V6/f1QxZ/V6KsWrlmCW1ftr9fxN9Sbi+UCbR2s0LL5syV/G0e
t7ea7jTAfVoZnNgLehYGe9Abdwtzt9x+Cg6jmvEhsIwnvbrIKKhYhJ0enFlY
50gTJrXrVyvTtt7alrDR9Cottz79xAcmXNKzKQo5jCIObWzt9pZTwtp1XVK8
kuH6AjyBfQoPmPahhDtwvAkO0cPpuicNR72cewFF0Hs306Zud22gNpQNmuVf
BChWDo5zvqbga7u71y3ClfNDviTdc1hBa2BYyREb4dNGzFy7tGEbxLYrHV0n
aoDcBse/68ZWLMVn2TDINVluNDp4fNXvTZUUIakp75Kr9YqtnC1NH0jMbWub
boImQAs+wp45SYqP+41z3LDJzekHNO+iECrt3QK1Y7+b3d5Hti1Rx6gBpFgW
+D8pILl7BMdBk4S3sAkCiSo4nMJ5j9weVKh7DQYi6Wiacj3N2/lqk4+tvZaR
i6kiRYHT4R4ZWiaIzGeb2hJcocFSEqZgcLTI3p/1AbfStBXaZJuwsW9LIixY
ibBI4jC3z2J33KocKgs6wQd9FNIf0IlBl4xBwxBRJN2Jwe7tXV2+sXe8WJnw
LYGSMOZbXoIODzniQAKDuxYqcDlt5d4ih1CkAZLrJPamml7tLbDnHP5IZ663
4Ac9jNQ7r/3q7SVtDxK2XdnANq6SBvj+tLA0+VeYxyn3/CK5gRoROLrig/Gu
3FpWZs4nyUu+W5yTQbKIbeT3k2lh2cGDBW6sI2Ov67WNpOzdTRvHV8bhBTfW
qDjwZAWZ+xYpkG05mdpzLaiGS/nnH+Vhdt/+ExQ/KYJFV0LtaCS2kXDUA36k
9GG89tlz35Hvy0Vbz3f0C7NJI2XLbqPGPsZ/Nsx2YG/jJAYIKBo3FK+JV8d5
OnQtS0h3fjruTDQOv/RT4xw/s2rKDZEdaEWqg4tznJtCBw9n/pLupAVf1hHL
rvBDoqYW0xyw7ZXLHbvLnZiyA6Kqqz/qui5mCaeF/d1fgcR2t3KwVUb9ALdP
oEoheQ9ysK7hPuyLDSJmTo4HFsltaJghlxt6pdxI4+uY45rrC27C/06dTd5P
BvhHuvPDgrxcMyfPymV7tYCoyew2L1YUfkkQzq9eANmgzHxrY0JE7Ti2wJaI
Uyc2Y4WGOpc77ncgY2FyvmaI2Ps9CeFRhUsKYtVFQT5kpsfqp4TiZJ2pf0P4
OlbnmnQgx59OWFE8Sob+PYWXaWLoF3lcT01Fz/yk1wRFXtEANdo8fySLqH6Q
lO1YTXJytSv1Fk3oY0Vxmlmrq5aeTFM8mpOOftLkhioyo/T7Wk+1uqC9H6s3
5LhMRcD4vGiTMX34mT4i7qANo4jRaF/Ut8XdWL2uklv8/aZfxyAiTmmGE02T
vSOe0MoIoCWY7B1paErPEUFrAMkfNKF2rT6QGUmYjWc1ruYhv/w/E74olrNy
KxIMG/n3my3kkhpJguyyHSs+nFmX7IPR4YJthPEP6tunCUnIG4qmcjKfQsgF
1PZi9qoi2RLfwAds0cRHs/5o5nMiXpOz+ETvxupdm8E+XNGIrwrY1DE/UxEf
eBclaQdOflrn5MhdaijhUzKkgw2SXmi6Navanohd2EwnTeL+cFWWuR4sCZob
uU6yXppyaarYDiCNwQ0+y7Gsijf6Qi+w0z9BU6u0hWBcGZRkX+cL/DknEsgf
22pBr1zPlkW+0imX0U90RZhDXSYLchy6Kuxev0NGeKzetpBmEh/0gKhPht6B
MKIIITwRbv6bXlIU9+uvmrCOuoagVQEH+ETETA4TMwP25aJqRPNwSO9Nw4CC
ohs+TS/bKfvHHn5P7kzxdrx4qPjaf2Wv/Scb5P/OgLVKPxZrMovvkjQjUr58
4ev5caqJtdffYYbr87fdKuasLcyF/ztWYp39H7JS/m+RUKBOuAX6bwXUlnv3
MjIgD5XOKNpheXb5Qngv9IUsEQDFRi70TaRr1GI0pwMvR6Mz7gu0HSRnOO6R
4qpUblU35j/+YzRhsClnbQtJSaGTRm4FBa6TIyQrtnYzArGJHFwnk9as6f2z
OjgojZJk5Kvovno+Gn30xpr7lbsrhXxYREN98LdDTnFz99K5Sn/ow59AluS3
JY3TnrEoMLwqjfQauTPM2AvBu+Ccq5ldcd8PJX1NqLYGd09msLj27CT/tYGa
ZrgppLW9q6WB8dzOIYDaFVn8XfRM8IlgI3iHBvSSNN1akJMZUI7CNRPb5feA
DOUAROP7Y+1dy4Cthu+AZ8zuNu3/AZlNJ2OjcAAA
<section anchor="acknowledgements" numbered="false">
<name>Acknowledgements</name>
<t>Many thanks to those who have contributed to building and operating
the first TreeDN network on the Internet, including <contact
fullname="Pete Morasca"/>, <contact fullname="William Zhang"/>, <contact
fullname="Lauren Delwiche"/>, <contact fullname="Natalie Landsberg"/>,
<contact fullname="Wayne Brassem"/>, <contact fullname="Jake Holland"/>,
<contact fullname="Andrew Gallo"/>, <contact fullname="Casey Russell"/>,
<contact fullname="Janus Varmarken"/>, <contact fullname="Csaba Mate"/>,
<contact fullname="Frederic Loui"/>, <contact fullname="Max Franke"/>,
<contact fullname="Todor Moskov"/>, <contact fullname="Erik Herz"/>,
<contact fullname="Bradley Cao"/>, <contact fullname="Katie Merrill"/>,
<contact fullname="Karel Hendrych"/>, <contact fullname="Haruna
Oseni"/>, and <contact fullname="Isabelle Xiong"/>. The writing of this
document to describe the TreeDN architecture was inspired by a
conversation with <contact fullname="Dino Farinacci"/> and <contact
fullname="Mike McBride"/>. Thanks also to <contact fullname="Jeff
Haas"/>, <contact fullname="Vinod Kumar"/>, <contact fullname="Ron
Bonica"/>, <contact fullname="Jeffrey Zhang"/>, and <contact
fullname="Éric Vyncke"/> for their thoughtful reviews and suggestions,
<contact fullname="Chris Lemmons"/> for his detailed shepherd review,
and <contact fullname="Stephen Farrell"/>, <contact fullname="Magnus
Westerlund"/>, <contact fullname="Reese Enghardt"/>, <contact
fullname="Jurgen Schonwalder"/>, <contact fullname="Carlos Pignataro"/>,
<contact fullname="Erik Kline"/>, <contact fullname="Gunter Van de
Velde"/>, <contact fullname="Warren Kumari"/>, and <contact
fullname="Zaheduzzaman Sarker"/> for their last call reviews.</t>
</section>
<!-- [rfced] Please review the use of the "/" character to separate terms
throughout this document and let us know if it may be updated for
clarity. In some cases, it may be unclear to the reader whether the "/"
stands for "and", "or", or "and/or".
Originals:
As Internet audience sizes for high-interest live events reach
unprecedented levels and bitrates climb to support 4K/8K/Augmented
Reality (AR)...
...(LISP) [RFC9300] 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.
Decentralization/Democratization of Content Sourcing
That is, multicast routers maintain a forwarding cache of multicast flows
that usually includes the source address, group address, incoming/outgoing
interfaces and forwarding rate.
Additionally, since multicast leverages reverse-path forwarding
(RPF), the source of the content can potentially have a greater
influence over the path taken through the network from source to
native receivers/AMT relays.
In particular, Section 6 of [RFC7450] candidly notes that AMT, like UDP,
IGMP and MLD, provides no mechanisms for ensuring message delivery or
integrity, nor does it provide confidentiality, since sources/groups joined
through IGMP/MLD could be associated with the particular content being
requested.
-->
<!-- [rfced] Abbreviations
a) FYI - We have added expansions for abbreviations upon first use
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
BGP Multicast VPN (BGP-MVPN)
Bit Index Explicit Replication (BIER)
European Organisation for the Exploitation of
Meteorological Satellites (EUMETSAT)
Internet Key Exchange Protocol Version 2 (IKEv2)
Point-to-Multipoint (P2MP)
Segment Routing (SR)
--> -->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
a.) For example, please consider whether various instances of "native" and
"natively" should be updated throughout this document.
b.) In addition, please consider whether "traditional" should be updated for
clarity. While the NIST website <https://www.nist.gov/nist-research-library/
nist-technical-series-publications-author-instructions#table1> indicates
that this term is potentially biased, it is also ambiguous. "Tradition"
is a subjective term, as it is not the same for everyone.
-->
</back>
</rfc> </rfc>
 End of changes. 74 change blocks. 
1169 lines changed or deleted 873 lines changed or added

This html diff was produced by rfcdiff 1.48.