rfc9706.original   rfc9706.txt 
MOPS L. Giuliano Internet Engineering Task Force (IETF) L. Giuliano
Internet-Draft Juniper Networks Request for Comments: 9706 Juniper Networks
Intended status: Informational C. Lenart Category: Informational C. Lenart
Expires: 22 February 2025 Verizon ISSN: 2070-1721 Verizon
R. Adam R. Adam
GEANT GEANT
21 August 2024 December 2024
TreeDN- Tree-based CDNs for Live Streaming to Mass Audiences TreeDN: Tree-Based Content Delivery Network (CDN) for Live Streaming to
draft-ietf-mops-treedn-07 Mass Audiences
Abstract Abstract
As Internet audience sizes for high-interest live events reach As Internet audience sizes for high-interest live events reach
unprecedented levels and bitrates climb to support 4K/8K/Augmented unprecedented levels and bitrates climb to support 4K /8K / Augmented
Reality (AR), live streaming can place a unique type of stress upon Reality (AR), live streaming can place a unique type of stress upon
network resources. TreeDN is a tree-based CDN architecture designed network resources. TreeDN is a tree-based Content Delivery Network
to address the distinctive scaling challenges of live streaming to (CDN) architecture designed to address the distinctive scaling
mass audiences. TreeDN enables operators to offer Replication-as- challenges of live streaming to mass audiences. TreeDN enables
a-Service (RaaS) at a fraction the cost of traditional, unicast-based operators to offer Replication-as-a-Service (RaaS) at a fraction of
CDNs- in some cases, at no additional cost to the infrastructure. In the cost of traditional, unicast-based CDNs -- in some cases, there
addition to efficiently utilizing network resources to deliver is no additional cost to the infrastructure. In addition to
existing multi-destination traffic, this architecture also enables efficiently utilizing network resources to deliver existing multi-
new types of content and use cases that previously were not possible destination traffic, this architecture also enables new types of
or economically viable using traditional CDN approaches. Finally, 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 TreeDN is a decentralized architecture and a democratizing technology
in the way that it makes content distribution more accessible to more that makes content distribution more accessible to more people by
people by dramatically reducing the costs of replication. dramatically reducing the costs of replication.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on 22 February 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9706.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language
3. Multicast Challenges in the Past . . . . . . . . . . . . . . 4 3. Problem Statement
4. TreeDN Architecture . . . . . . . . . . . . . . . . . . . . . 5 4. Applicability
4.1. TreeDN Overlays . . . . . . . . . . . . . . . . . . . . . 5 5. Multicast Challenges in the Past
4.2. TreeDN Native On-Net . . . . . . . . . . . . . . . . . . 6 6. TreeDN Architecture
5. Replication-as-a-Service (RaaS) . . . . . . . . . . . . . . . 7 6.1. TreeDN Overlays
6. Decentralization/Democratization of Content Sourcing . . . . 8 6.2. TreeDN Native On-Net
7. Transport Layer-Related Differences between TreeDN and 7. Replication-as-a-Service (RaaS)
Traditional CDNs . . . . . . . . . . . . . . . . . . . . 8 8. Decentralization/Democratization of Content Sourcing
7.1. Integration with Unicast . . . . . . . . . . . . . . . . 9 9. Transport-Layer-Related Differences between TreeDN and
7.2. Reliability, Adaptive Bitrate and Congestion Control . . 9 Traditional CDNs
7.3. Authorization and Encryption . . . . . . . . . . . . . . 10 9.1. Integration with Unicast
8. TreeDN Deployments . . . . . . . . . . . . . . . . . . . . . 10 9.2. Reliability, Adaptive Bitrates, and Congestion Control
9. Operational Considerations . . . . . . . . . . . . . . . . . 11 9.3. Authorization and Encryption
10. Security Consideration . . . . . . . . . . . . . . . . . . . 11 10. TreeDN Deployments
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 11. Operational Considerations
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 12. Security Consideration
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 13. IANA Considerations
13.1. Normative References . . . . . . . . . . . . . . . . . . 12 14. References
13.2. Informative References . . . . . . . . . . . . . . . . . 13 14.1. Normative References
Appendix A. Netverses . . . . . . . . . . . . . . . . . . . . . 16 14.2. Informative References
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Appendix A. Netverses
Acknowledgements
Authors' Addresses
1. Problem Statement 1. Introduction
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 Content
Delivery Network (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 infrastructure. In
addition to efficiently utilizing network resources to deliver
existing multi-destination traffic, this architecture also enables
new types of content and use cases that previously 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.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Problem Statement
Live streaming to mass audiences can impose unique demands on network Live streaming to mass audiences can impose unique demands on network
resources. For example, live sporting events broadcast over the resources. For example, live sporting events that broadcast over the
Internet to end users has much lower tolerance for long playout Internet to end users have a much lower tolerance for long playout
buffers than typical on-demand video streaming. Viewers of live buffers than typical on-demand video streaming. Viewers of live
sporting events have long been conditioned by broadcast television to sporting events have long been conditioned by broadcast television to
expect to see the content in real time, with only very short buffers expect to see the content in real time, with only very short buffers
for broadcast delays to prevent profanity and other objectionable for broadcast delays to prevent profanity and other objectionable
content from making on the air (the "seven-second delay" content from making on the air (this is known as the "seven-second
[BROADCAST-DELAY]). With micro-betting, even this 5-10 second delay delay" [BROADCAST-DELAY]). With micro-betting, even this 5 to 10
can be too long. By comparison, when watching on-demand movies, an second delay can be too long. By comparison, when watching on-demand
extra one- or two-minute playout buffer tends to be perfectly movies, an extra one- or two-minute playout buffer tends to be
acceptable for viewers. If playout buffers for live sports are that perfectly acceptable for viewers. If playout buffers for live sports
long, viewers run the risk of being alerted to the game winning score are that long, viewers run the risk of being alerted to a game-
from text messages from friends or cheers from the bar across the winning score from text messages from friends or cheers from the bar
street, minutes before they view it themselves. across the street minutes before they view it themselves.
Another unique characteristic of live streaming is join rate. While Another unique characteristic of live streaming is the join rate.
on-demand video streaming can consume massive amounts of network While on-demand video streaming can consume massive amounts of
resources, the viewing rates tend to be smooth and predictable. network resources, the viewing rates tend to be smooth and
Service Providers observe gradual levels of traffic increases over predictable. Service Providers (SPs) observe gradual levels of
the evening hours corresponding to prime-time viewing habits. By traffic increases over the evening hours corresponding to prime-time
comparison, viewing rates of live video streams can more closely viewing habits. By comparison, viewing rates of live video streams
resemble a step function with much less predictability as mass can more closely resemble a step function with much less
audiences of viewers tune in to watch the game at the same time. predictability as mass audiences of viewers tune in to watch the game
at the same time.
Previous efforts at more efficient network replication of multi- Previous efforts for more efficient network replication of multi-
destination traffic have experienced mixed success in terms of destination traffic have experienced mixed success in terms of
adoption. IP multicast is widely deployed on financial networks, adoption. IP multicast is widely deployed on financial networks,
video distribution networks, L3VPN networks and certain enterprises. video distribution networks, L3VPN networks, and certain enterprises.
But most of these deployments are restricted to "walled-garden" However, most of these deployments are restricted to "walled-garden"
networks. Multicast over the global Internet has failed to gain networks. Multicast over the global Internet has failed to gain
traction, as only a very small portion of the Internet is multicast- traction, as only a very small portion of the Internet is multicast
enabled at this time. enabled at this time.
TreeDN is a tree-based CDN architecture that is the result of the TreeDN is a tree-based CDN architecture that is the result of the
evolution of network-based replication mechanisms based on lessons evolution of network-based replication mechanisms and is based on
learned from what has and has not worked well in the past. TreeDN lessons learned from what has and has not worked well in the past.
addresses the fundamental issues of what has hindered multicast from TreeDN addresses the fundamental issues of what has hindered
adoption on the global Internet and enables service providers the multicast from adoption on the global Internet and enables SPs the
opportunity to deliver new Replication-as-a-Service (RaaS) offerings opportunity to deliver new Replication-as-a-Service (RaaS) offerings
to content providers, while more efficiently utilizing network to content providers, while more efficiently utilizing network
resources by eliminating duplicated traffic, and thus, improving the resources by eliminating duplicated traffic. Thus, this improves the
experience of end users. TreeDN accomplishes this with the experience of end users. TreeDN accomplishes this with the
combination of a simplified model of native multicast along with combination of a simplified model of native multicast along with
network overlays to reach receivers on unicast-only parts of the network overlays to reach receivers on unicast-only parts of the
Internet. Internet.
By more efficiently supporting multi-destination traffic, TreeDN is By more efficiently supporting multi-destination traffic, TreeDN is
an architecture that can enable new types of content, such as an architecture that can enable new types of content (such as AR live
Augmented Reality (AR) live streaming to mass audiences, that streaming to mass audiences) that previously weren't possible or
previously weren't possible or economically viable on the Internet economically viable on the Internet due to the inefficiencies of
due to the inefficiencies of unicast. unicast.
2. Applicability 4. Applicability
While the primary use case mentioned throughout this document is live While the primary use case mentioned throughout this document is live
streaming of multimedia content (audio, video, AR, real-time streaming of multimedia content (e.g., audio, video, AR, and real-
telemetry data), the TreeDN architecture can provide efficient time telemetry data), the TreeDN architecture can provide efficient
delivery for any content that needs to be replicated and delivered to delivery for any content that needs to be replicated and delivered to
multiple destinations. For example, large software file updates (eg, multiple destinations. For example, large software file updates
OS upgrades) that need to be delivered to many end users in a very (e.g., OS upgrades) that need to be delivered to many end users in a
short window of time can cause significant strain on network very short window of time can cause significant strain on network
resources. Using TreeDN, this use case can be handled much more resources. Using TreeDN, this use case can be handled much more
efficiently by the network. efficiently by the network.
3. Multicast Challenges in the Past 5. Multicast Challenges in the Past
The following issues have been the some of the primary challenges for The following issues have been some of the primary challenges for
deployment of IP multicast over the global Internet. This is not deployment of IP multicast over the global Internet. This is not
intended to be an exhaustive list, but to rather to provide context intended to be an exhaustive list but rather a list that provides
to the solution and how it addresses these primary challenges. context for the solution and how it addresses these primary
challenges.
* The "All or Nothing" Problem: IP multicast requires every layer-3 * The "All or Nothing" problem: IP multicast requires every Layer 3
hop between source and receivers to be multicast-enabled. To hop between the source and receivers to be multicast enabled. To
achieve ubiquitous availability on the global Internet, this achieve ubiquitous availability on the global Internet, this
essentially means nearly every interface on every router and essentially means that nearly every interface on every router and
firewall between all end hosts must support a multicast routing firewall between all end hosts must support a multicast routing
protocol like Protocol Independent Multicast - Sparse Mode (PIM- protocol (such as Protocol Independent Multicast - Sparse Mode
SM) [RFC7761] or Multipoint Label Distribution Protocol (mLDP) (PIM-SM) [RFC7761] or the Multipoint Label Distribution Protocol
[RFC6388]. This requirement creates a bar to deployment that is (mLDP) [RFC6388]). This requirement creates a bar to deployment
practically impossible to overcome. that is practically impossible to overcome.
* The "It's Too Complex" Problem: operators have long complained * The "It's Too Complex" problem: Operators have long complained
that multicast routing protocols like PIM-SM are simply too that multicast routing protocols like PIM-SM are simply too
complex, making it costly to design, configure, manage and complex, making it costly to design, configure, manage, and
troubleshoot IP multicast in the network. troubleshoot IP multicast in the network.
* The "Chicken and Egg" Problem: there's not much multicast content * The "Chicken and Egg" problem: There's not much multicast content
because there's not much of a multicast-enabled audience, but because there's not much of a multicast-enabled audience, but
there's not much of a multicast-enabled audience because there's there's not much of a multicast-enabled audience because there's
not much multicast content. not much multicast content.
TreeDN is the evolution of network-based replication based on lessons TreeDN is the evolution of network-based replication based on lessons
learned over decades and is designed to address the problems listed learned over decades and is designed to address the problems listed
above. above.
4. TreeDN Architecture 6. TreeDN Architecture
TreeDN leverages a simplified model for multicast deployment combined TreeDN leverages a simplified model for multicast deployment combined
with network overlays to deliver traffic to receiving hosts on with network overlays to deliver traffic to receiving hosts on
unicast-only networks. With network overlays, a service can be unicast-only networks. With network overlays, a service can be
achieved and delivered to end users while recognizing and tolerating achieved and delivered to end users while recognizing and tolerating
the practical realities of what is possible over a network as diverse the practical realities of what is possible over a network as diverse
as the global Internet. That is, the replication service is as the global Internet. That is, the replication service is
available to users and applications across the global Internet available to users and applications across the global Internet
regardless of what protocols may exist in the underlying networks regardless of what protocols may exist in the underlying networks
that constitute the underlay. that constitute the underlay.
skipping to change at page 5, line 39 skipping to change at line 252
Native Content AMT Tunnel +-------.------+ Native Content AMT Tunnel +-------.------+
Receivers . Receivers .
AMT +-+ AMT +-+
Gateway +-+ Gateway +-+
| |
Content Content
Receiver Receiver
Figure 1: TreeDN Provider Example Figure 1: TreeDN Provider Example
4.1. TreeDN Overlays 6.1. TreeDN Overlays
One overlay technology that TreeDN leverages is Automatic Multicast One overlay technology that TreeDN leverages is Automatic Multicast
Tunneling (AMT) [RFC7450]. With AMT, end hosts on unicast-only Tunneling (AMT) [RFC7450]. With AMT, end hosts on unicast-only
networks (AMT Gateways) can dynamically build tunnels to routers on networks (AMT Gateways) can dynamically build tunnels to routers on
the multicast-enabled part of the network (AMT Relays) and receive the multicast-enabled part of the network (AMT Relays) and receive
multicast streams. The AMT Gateway is a thin software client which multicast streams. The AMT Gateway is a thin software client that
typically sits on the receiving end host and initiates the tunnel at typically sits on the receiving end host and initiates the tunnel at
an AMT Relay, which is a tunnel server that typically sits at the an AMT Relay. The AMT Relay is a tunnel server that typically sits
border of the multicast network. AMT allows any end host on the at the border of the multicast network. AMT allows any end host on
Internet to receive multicast content regardless of whether their the Internet to receive multicast content regardless of whether their
local provider supports multicast (aka, "off-net receivers"), which local provider supports multicast (aka, "off-net receivers"), which
addresses the "All or Nothing" Problem. Links and devices that do addresses the "All or Nothing" problem. Links and devices that do
not support multicast are simply tunneled over- they no longer not support multicast are simply tunneled over -- they no longer
present a barrier to the overall replication service for end users. present a barrier to the overall replication service for end users.
Those networks that do deploy and support multicast, as well as the Those networks that do deploy and support multicast, as well as the
content providers that serve up multicast content, are able to enjoy content providers that serve up multicast content, are able to enjoy
the benefits of efficient replication and delivery. Further, these the benefits of efficient replication and delivery. Further, these
benefits can serve as incentives for operators who do not yet support benefits can serve as incentives for operators who do not yet support
multicast to enable it on their networks, a key benefit of multicast to enable it on their networks, which is a key benefit of
incremental deployment described in section 4.3 of [RFC9049]. Once incremental deployment described in Section 4.3 of [RFC9049]. Once
the cost of carrying duplicated unicast tunnels is perceived by those the cost of carrying duplicated unicast tunnels is perceived by those
operators to exceed the cost of deploying multicast, they are more operators to exceed the cost of deploying multicast, they are more
likely to enable multicast on their networks. In this way, TreeDN likely to enable multicast on their networks. Thus, TreeDN
effectively supports incremental deployment in a way that was not effectively supports incremental deployment in a way that was not
previously possible with traditional (non-overlay) multicast previously possible with traditional (non-overlay) multicast
networking. Finally, AMT also addresses the "Chicken and Egg" networking. Finally, AMT also addresses the "Chicken and Egg"
Problem, as all end hosts on the global Internet that have access to problem, as all end hosts on the global Internet that have access to
an AMT Relay are capable of becoming audience members. an AMT Relay are capable of becoming audience members.
To support receiving on both native and non-native networks, To support receiving on both native and non-native networks,
receiving hosts can first attempt to join the traffic natively and, receiving hosts can first attempt to join the traffic natively, and
if no multicast traffic is received, fallback to AMT. This fallback if no multicast traffic is received, they can fall back to AMT. This
mechanism can be handled by the application layer. fallback mechanism can be handled by the application layer.
In addition to AMT, other overlay technologies like Locator/ID In addition to AMT, other overlay technologies like the Locator/ID
Separation Protocol (LISP) [RFC9300] can be utilized to deliver Separation Protocol (LISP) [RFC9300] can be utilized to deliver
content from multicast-enabled networks to end hosts that are content from multicast-enabled networks to end hosts that are
separated by portions of the network (at the last/middle/first mile) separated by portions of the network (at the last/middle/first mile)
that do not support multicast. that do not support multicast.
4.2. TreeDN Native On-Net 6.2. TreeDN Native On-Net
Networks that support multicast provide the native on-net component Networks that support multicast provide the native on-net component
of TreeDN. The primary requirement of the native on-net is to of TreeDN. The primary requirement of the native on-net component is
support Source-Specific Multicast (SSM) [RFC4607]. PIM-SSM, which is to support Source-Specific Multicast (SSM) [RFC4607]. PIM-SSM, which
merely a subset of PIM-SM, is the multicast routing protocol is merely a subset of PIM-SM, is the multicast routing protocol
typically used in SSM. However, any multicast routing protocol typically used in SSM. However, any multicast routing protocol
capable of supporting SSM can be used as a TreeDN native on-net, such capable of supporting SSM can be used in the TreeDN native on-net
as mLDP, Global Table Multicast (GTM) [RFC7716] and BGP-based component, such as mLDP, Global Table Multicast (GTM) [RFC7716], BGP-
Multicast [I-D.ietf-bess-bgp-multicast], or even BGP-MVPN [RFC6513] based Multicast [BGP-MULTICAST], or even BGP Multicast VPN (BGP-MVPN)
for those operators who carry the global routing table in a VRF. [RFC6513] for those operators who carry the global routing table in a
Likewise, any data plane technology that supports SSM, including BIER Virtual Routing and Forwarding (VRF) table. Likewise, any data plane
[RFC8279] and SR-P2MP [I-D.ietf-spring-sr-replication-segment] can be technology that supports SSM, including Bit Index Explicit
used. Replication (BIER) [RFC8279] and Segment Routing (SR) Point-to-
Multipoint (P2MP) [RFC9524], can be used.
The key benefit of SSM as the native on-net component of TreeDN is The key benefit of SSM as the native on-net component of TreeDN is
that it radically simplifies the control plane needed to support that it radically simplifies the control plane needed to support
replication in the network. This simplification comes by moving replication in the network. This simplification comes by moving
source discovery from the network layer to some sort of out-of-band source discovery from the network layer to some sort of out-of-band
mechanism, usually in the application layer. In SSM, the receiver mechanism, usually in the application layer. In SSM, the receiver
uses Internet Group Management Protocol, Version 3 (IGMPv3) [RFC3376] uses the Internet Group Management Protocol Version 3 (IGMPv3)
for IPv4 or Multicast Listener Discovery Version 2 (MLDv2) [RFC3810] [RFC3376] for IPv4 or the Multicast Listener Discovery Version 2
for IPv6 to specify both the source and group address of the (MLDv2) protocol [RFC3810] for IPv6 to specify both the source and
multicast stream. This allows the last hop router to immediately group address of the multicast stream. This allows the last-hop
join the multicast stream along the shortest-path tree (SPT) without router to immediately join the multicast stream along the shortest-
the need for shared trees. This benefit addresses the "It's Too path tree (SPT) without the need for shared trees. This benefit
Complex" Problem. By eliminating the need for network-based source addresses the "It's Too Complex" problem. By eliminating the need
discovery, most of the complexity of multicast is then eliminated, for network-based source discovery, most of the complexity of
which reduces the cost of deploying and operating a multicast multicast is then eliminated, which reduces the cost of deploying and
network. Further rationale for this SSM-only approach can be found operating a multicast network. Further rationale for this SSM-only
in Any-Source Multicast (ASM) Deprecation [RFC8815]. approach can be found in Any-Source Multicast (ASM) Deprecation
[RFC8815].
5. Replication-as-a-Service (RaaS) 7. Replication-as-a-Service (RaaS)
Content providers have traditionally used CDNs to distribute content Content providers have traditionally used CDNs to distribute content
that needs to be delivered to large audiences, essentially that needs to be delivered to large audiences, essentially
outsourcing the task of replication to CDN providers. Most CDNs outsourcing the task of replication to CDN providers. Most CDNs
utilize unicast delivery, as multicast is not an option due to its utilize unicast delivery, as multicast is not an option due to its
lack of general availability on the global Internet. TreeDN is a CDN lack of general availability on the global Internet. TreeDN is a CDN
architecture that leverages tree-based replication to more architecture that leverages tree-based replication to more
efficiently utilize network resources to deliver simultaneous multi- efficiently utilize network resources to deliver simultaneous multi-
destination traffic. By leveraging overlay networking to address the destination traffic. By leveraging overlay networking to address the
"All or Nothing" and "Chicken and Egg" Problems and SSM to address "All or Nothing" and "Chicken and Egg" problems, and leveraging SSM
the "It's Too Complex" Problem, TreeDN avoids the practical issues to address the "It's Too Complex" problem, TreeDN avoids the
that previously prevented multicast from being a viable option for practical issues that previously prevented multicast from being a
CDN providers. viable option for CDN providers.
TreeDN has several advantages over traditional unicast-based CDN TreeDN has several advantages over traditional unicast-based CDN
approaches. First, the TreeDN functionality can be delivered approaches. First, the TreeDN functionality can be delivered
entirely by the existing network infrastructure. Specifically, for entirely by the existing network infrastructure. Specifically, for
operators with routers that support AMT natively, multicast traffic operators with routers that support AMT natively, multicast traffic
can be delivered directly to end users without the need for can be delivered directly to end users without the need for
specialized CDN devices, which typically are servers that need to be specialized CDN devices, which typically are servers that need to be
racked, powered, cooled and connected to ports on routers that could racked, powered, cooled, and connected to ports on routers that
otherwise have been consumed by paying customers. In this way, SPs otherwise could have been consumed by paying customers. In this way,
can offer new RaaS functionality to content providers at potentially SPs can offer new RaaS functionality to content providers at
zero additional cost in new equipment. potentially zero additional cost in new equipment.
Additionally, TreeDN is an open architecture that leverages mature, Additionally, TreeDN is an open architecture that leverages mature,
IETF-specified and widely implemented network protocols. TreeDN also IETF-specified, and widely implemented network protocols. TreeDN
requires far less coordination between the content provider and the also requires far less coordination between the content provider and
CDN operator. That is, there are no storage requirements for the the CDN operator. That is, there are no storage requirements for the
data, nor group-key management issues since a TreeDN provider merely data, nor group-key management issues, since a TreeDN provider merely
forwards packets. A TreeDN provider simply needs to have enough forwards packets. A TreeDN provider simply needs to have enough
accounting data (eg, traffic data, number of AMT tunnels, etc) to accounting data (e.g., traffic data, number of AMT tunnels, etc.) to
properly bill customers for the service. By contrast, traditional properly bill customers for the service. By contrast, traditional
unicast-based CDNs often incorporate proprietary, non-interoperable unicast-based CDNs often incorporate proprietary, non-interoperable
technologies and require significant coordination between the content technologies and require significant coordination between the content
provider and the CDN to handle such things as file storage, data provider and the CDN to handle such things as file storage, data
protection and key-management. protection, and key management.
TreeDN introduces a deployment model that requires new considerations TreeDN introduces a deployment model that requires new considerations
for transport layer mechanisms that are frequently relied upon by for transport-layer mechanisms that are frequently relied upon by
traditional unicast-based CDNs. A discussion on these considerations traditional unicast-based CDNs. A discussion on these considerations
and differences can be found in section 7. and differences can be found in Section 9.
6. Decentralization/Democratization of Content Sourcing 8. Decentralization/Democratization of Content Sourcing
TreeDN is an inherently decentralized architecture. This reduces the TreeDN is an inherently decentralized architecture. This reduces the
cost for content sourcing, as any host connected to a multicast- cost for content sourcing, as any host connected to a multicast-
enabled network, or on a source-capable overlay, can send out a enabled network or on a source-capable overlay can send out a single
single data stream that can be reached by an arbitrarily large data stream that can be reached by an arbitrarily large audience. By
audience. By effectively reducing to zero the marginal cost of effectively reducing the marginal cost of reaching each additional
reaching each additional audience member, from the perspective of the audience member to zero, from the perspective of the source, TreeDN
source, TreeDN democratizes content sourcing on the Internet. democratizes content sourcing on the Internet.
7. Transport Layer-Related Differences between TreeDN and Traditional 9. Transport-Layer-Related Differences between TreeDN and Traditional
CDNs CDNs
The focus of this document is on the network layer components that The focus of this document is on the network-layer components that
comprise the TreeDN architecture. This section introduces some of comprise the TreeDN architecture. This section introduces some of
the key transport layer-related differences between TreeDN and the key transport-layer-related differences between TreeDN and
traditional unicast-based CDNs that should be taken into traditional unicast-based CDNs that should be taken into
consideration when deploying TreeDN-based services. In many cases, consideration when deploying TreeDN-based services. In many cases,
these issues are more related to TCP-UDP differences than unicast- these issues are more related to differences between TCP and UDP than
multicast differences, thus UDP-based solutions can be leveraged to differences between unicast and multicast; thus, UDP-based solutions
address most gaps. The aim of this section is to point to some of can be leveraged to address most gaps. The aim of this section is to
the existing work to address these gaps, as well as suggest further point to some of the existing work to address these gaps, as well as
work that could be undertaken within the IETF. Further details of to suggest further work that could be undertaken within the IETF.
these transport layer mechanisms are beyond the scope of this Further details of these transport-layer mechanisms are beyond the
document. scope of this document.
7.1. Integration with Unicast 9.1. Integration with Unicast
Since SSM inherently implies unidirectional traffic flows from one to Since SSM inherently implies unidirectional traffic flows from one to
many, mechanisms that rely on bidirectional communication between many, mechanisms that rely on bidirectional communication between
receivers and the content provider, such as bespoke advertising, receivers and the content provider (such as bespoke advertising,
telemetry data from receivers detailing end user experience, telemetry data from receivers detailing end-user experience,
distribution of decryption keys, switching to higher/lower bandwidth distribution of decryption keys, switching to higher or lower
streams, etc, are not well suited to SSM delivery. As such, separate bandwidth streams, etc.) are not well suited to SSM delivery. As
unicast streams between receivers and content providers may be used such, separate unicast streams between receivers and content
for this type of "out-of-band" functions while SSM is used to deliver providers may be used for this type of "out-of-band" function while
the actual content of interest. These "out-of-band" unicast streams SSM is used to deliver the actual content of interest. These "out-
SHOULD use the same congestion control and authentication mechanisms of-band" unicast streams SHOULD use the same congestion control and
that are used today for mass audience unicast delivery. Generally authentication mechanisms that are used today for mass audience
speaking, this hybrid unicast-multicast approach is best handled by unicast delivery. Generally speaking, this hybrid unicast-multicast
the application layer and further detail is beyond the scope of this approach is best handled by the application layer and further detail
document. is beyond the scope of this document.
7.2. Reliability, Adaptive Bitrate and Congestion Control 9.2. Reliability, Adaptive Bitrates, and Congestion Control
Traditional unicast-based CDNs frequently rely on HTTPS over TCP Traditional unicast-based CDNs frequently rely on HTTPS over TCP
transport and are thus able to leverage the granularity of TCP-based transport; thus, they are able to leverage the granularity of TCP-
mechanisms for reliability, congestion control and adaptive bitrate based mechanisms for reliability, congestion control, and adaptive
streaming. But this granularity comes at a cost of sending a bitrate streaming. However, this granularity comes at a cost of
separate datastream to each viewer. Multicast transmissions usually sending a separate data stream to each viewer. Multicast
employ UDP, which inherently lacks many of the aforementioned transmissions usually employ UDP, which inherently lacks many of the
benefits of TCP, but can scale much better for mass audiences of aforementioned benefits of TCP but can scale much better for mass
simultaneous viewers. Forward Error Correction (FEC) is a mechanism audiences of simultaneous viewers. Forward Error Correction (FEC) is
that has demonstrated full recovery for up to 5% packet loss and a mechanism that has demonstrated full recovery for up to 5% packet
interruptions up to 400ms for multicast datastreams in loss and interruptions up to 400 ms for multicast data streams in
[EUMETSAT-TERRESTRIAL]. NACK-Oriented Reliable Multicast (NORM) [EUMETSAT-TERRESTRIAL]. NACK-Oriented Reliable Multicast (NORM)
[RFC5740] leverages FEC-based repair and other Reliable Multicast [RFC5740] leverages FEC-based repair and other Reliable Multicast
Transport building blocks to provide end-to-end reliable transport Transport (RMT) building blocks to provide end-to-end reliable
over multicast networks. transport over multicast networks.
QUIC [RFC9000] is another popular transport used by traditional QUIC [RFC9000] is another popular transport used by traditional
unicast-based CDNs. While QUIC does use UDP, it does not currently unicast-based CDNs. While QUIC does use UDP, it does not currently
support multicast. Multicast extensions to QUIC have been proposed support multicast. Multicast extensions to QUIC have been proposed
in [I-D.jholland-quic-multicast]. in [QUIC-Multicast].
Section 4.1 of [RFC8085] describes how a sender can distribute data Section 4.1 of [RFC8085] describes how a sender can distribute data
across multiple multicast source-group channels so that each receiver across multiple multicast source-group channels so that each receiver
can join the most appropriate channels for its own reception rate can join the most appropriate channels for its own reception rate
capability, thus providing adaptive bitrate capabilities for capability, thus providing adaptive bitrate capabilities for
multicast streams. DVB MABR [DVB-MABR] and MAUD [MAUD] extensively multicast streams. [DVB-MABR] and [MAUD] extensively describe an
describe an architecture that enables reliability and dynamic bitrate architecture that enables reliability and dynamic bitrate adaptation.
adaptation.
TreeDN deployments MUST follow the congestion control guidelines TreeDN deployments MUST follow the congestion control guidelines
described in Section 4.1.4.2 of [RFC7450]. Multicast applications described in Section 4.1.4.2 of [RFC7450]. A multicast application
being distributed over TreeDN deployments SHOULD implement congestion that is being distributed over TreeDN deployments SHOULD implement
control for its data transmission as described in Section 4.1 in congestion control for its data transmission as described in
[RFC8085]. The AMT gateway SHOULD use the topologically closest AMT Section 4.1 of [RFC8085]. The AMT gateway SHOULD use the
relay. Section 3.1 of [RFC8777] describes a set of procedures for topologically closest AMT relay. Section 3.1 of [RFC8777] describes
optimal relay selection. a set of procedures for optimal relay selection.
7.3. Authorization and Encryption 9.3. Authorization and Encryption
A multicast sender typically has little to no control or visibility A multicast sender typically has little to no control or visibility
about which end hosts may receive the datastream. Encryption can be about which end hosts may receive the data stream. Encryption can be
used to ensure that only authorized receivers are able to access used to ensure that only authorized receivers are able to access
meaningful data. That is, even if unauthorized end hosts (eg, non- meaningful data. That is, even if unauthorized end hosts (e.g., non-
paying) receive the datastream, without decryption keys, the data is paying end hosts) receive the data stream, without decryption keys,
useless. [I-D.ietf-ipsecme-g-ikev2] describes an extension to IKEv2 the data is useless. [GKM-IKEv2] describes an extension to the
for the purpose of group key management. DVB MABR [DVB-MABR] and Internet Key Exchange Protocol Version 2 (IKEv2) for the purpose of
MAUD [MAUD] extensively describe an architecture that includes group key management. [DVB-MABR] and [MAUD] extensively describe an
encryption of multicast streams. architecture that includes encryption of multicast streams.
8. TreeDN Deployments 10. TreeDN Deployments
EUMETCast Terrestrial is a service from EUMETSAT that delivers EUMETCast Terrestrial is a service from the European Organisation for
meteorological satellite data to end users for purposes such as the Exploitation of Meteorological Satellites (EUMETSAT) that
operational monitoring of climate and detection of global climate delivers meteorological satellite data to end users for purposes such
as operational monitoring of climates and detection of global climate
changes. EUMETCast Terrestrial connects to the GEANT network, which changes. EUMETCast Terrestrial connects to the GEANT network, which
provides TreeDN services to deliver this real-time data natively to provides TreeDN services to deliver this real-time data natively to
end users on multicast-enabled networks as well as to end users on end users on multicast-enabled networks and to end users on unicast-
unicast-only networks via a global deployment of AMT relays. Details only networks via a global deployment of AMT relays. Details of the
of the EUMETCast Terrestrial service over the GEANT TreeDN network EUMETCast Terrestrial service over the GEANT TreeDN network are
are described in [EUMETCast-TERRESTRIAL-over-AMT]. Additional described in [EUMETCast-TERRESTRIAL-AMT]. Additional details on how
details on how this deployment uses encryption, authorization, this deployment uses encryption, authorization, reliability, and
reliability and unicast feedback channels for end-to-end file unicast feedback channels for end-to-end file delivery monitoring can
delivery monitoring can be found in [EUMETSAT-TERRESTRIAL]. be found in [EUMETSAT-TERRESTRIAL].
The Multicast Menu is a web-based portal that lists and can launch The Multicast Menu [Multicast-Menu] is a web-based portal that can
active multicast streams that are available on a global TreeDN list and launch active multicast streams that are available on a
network of various research and educations networks. Details of the global TreeDN network of various research and education networks.
this TreeDN network, as well as the Multicast Menu, are described in Details of this TreeDN network, as well as the Multicast Menu, are
[Multicast-Menu]. described in [Offnet-Sourcing-Multicast-Menu].
The RARE network is a global testbed interconnecting several national The RARE network is a global testbed interconnecting several National
research and education networks (NRENs) via routers running BIER. Research and Education Networks (NRENs) via routers running BIER.
AMT relays are deployed to deliver multicast traffic from sources on AMT relays are deployed to deliver multicast traffic from sources on
the RARE network to receivers on unicast-only networks across the the RARE network to receivers on unicast-only networks across the
Internet. Details of the RARE network are described in Internet. Details of the RARE network are described in
[BIER-AMT-Deployment]. [BIER-AMT-Deployment].
9. Operational Considerations 11. Operational Considerations
TreeDN is essentially the synthesis of SSM plus overlay networking TreeDN is essentially the synthesis of SSM plus overlay networking
technologies like AMT. As such, any existing tools to manage, technologies like AMT. As such, any existing tools to manage,
operate and troubleshoot a PIM-SSM domain and AMT deployment can be operate, and troubleshoot a PIM-SSM domain and an AMT deployment can
used to manage a TreeDN deployment. Protocol error handling for PIM- be used to manage a TreeDN deployment. Protocol error handling for
SSM can be found in [RFC4607] and in section 4.8 of [RFC7761] and for PIM-SSM can be found in [RFC4607] and in Section 4.8 of [RFC7761];
AMT in [RFC7450]. for AMT, it can be found in [RFC7450].
One potential operational benefit of a multicast-based approach like One potential operational benefit of a multicast-based approach like
TreeDN over traditional, unicast-based CDNs is the visibility that TreeDN over a traditional, unicast-based CDN is the visibility that
multicast state provides in the routing infrastructure. That is, multicast state provides in the routing infrastructure. That is,
multicast routers maintain a forwarding cache of multicast flows that multicast routers maintain a forwarding cache of multicast flows that
usually includes the source address, group address, incoming/outgoing usually includes the source address, group address, incoming/outgoing
interfaces and forwarding rate. Generally speaking, such flow state interfaces, and forwarding rate. Generally speaking, such flow state
information is not typically available in core networks for unicast, information is not typically available in core networks for unicast,
so additional tools outside the routing infrastructure are usually so additional tools outside the routing infrastructure are usually
required for monitoring CDN performance and troubleshooting issues required for monitoring CDN performance and troubleshooting issues
like packet loss location. Of course, this benefit comes at a cost like packet loss location. Of course, this benefit comes at a cost
of additional state being maintained in the routers for multicast. of additional state being maintained in the routers for multicast.
Additionally, since multicast leverages reverse-path forwarding Additionally, since multicast leverages Reverse Path Forwarding
(RPF), the source of the content can potentially have a greater (RPF), the source of the content can potentially have a greater
influence over the path taken through the network from source to influence over the path taken through the network from source to
native receivers/AMT relays. That is, the BGP peer advertising the 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 reachability of the source's subnet can do so in ways where a
a particular path through the network for multicast distribution that particular path through the network is preferred for multicast
are not as easy to accomplish with traditional, destination-based distribution; these methods are not as easy to accomplish with
unicast routing. traditional, destination-based unicast routing.
10. Security Consideration 12. Security Consideration
Since TreeDN is essentially the synthesis of SSM plus overlay Since TreeDN is essentially the synthesis of SSM plus overlay
networking technologies like AMT, the TreeDN architecture introduces networking technologies like AMT, the TreeDN architecture introduces
no new security threats that are not already documented in SSM and no new security threats that are not already documented in SSM and
the overlay technologies that comprise it. In particular, Section 6 the overlay technologies that comprise it. In particular, Section 6
of [RFC7450] candidly notes that AMT, like UDP, IGMP and MLD, of [RFC7450] candidly notes that AMT, like UDP, IGMP, and MLD,
provides no mechanisms for ensuring message delivery or integrity, provides no mechanisms for ensuring message delivery or integrity,
nor does it provide confidentiality, since sources/groups joined nor does it provide confidentiality, since sources/groups joined
through IGMP/MLD could be associated with the particular content through IGMP/MLD could be associated with the particular content
being requested. being requested.
[RFC4609] and [RFC8815] describes the additional security benefits of [RFC4609] and [RFC8815] describe the additional security benefits of
using SSM instead of ASM. using SSM instead of ASM.
11. IANA Considerations 13. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
12. Acknowledgements 14. References
Many thanks to those who have contributed to building and operating
the first TreeDN network on the Internet, including Pete Morasca,
William Zhang, Lauren Delwiche, Natalie Landsberg, Wayne Brassem,
Jake Holland, Andrew Gallo, Casey Russell, Janus Varmarken, Csaba
Mate, Frederic Loui, Max Franke, Todor Moskov, Erik Herz, Bradley
Cao, Katie Merrill, Karel Hendrych, Haruna Oseni and Isabelle 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 thoughtful reviews and suggestions, Chris
Lemmons for his detailed shepherd review and Stephen Farrell, Magnus
Westerlund, Reese Enghardt, Jurgen Schonwalder, Carlos Pignataro,
Erik Kline, Gunter Van de Velde, Warren Kumari and Zaheduzzaman
Sarker for their last call reviews.
13. References 14.1. Normative References
13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
<https://www.rfc-editor.org/info/rfc3376>. <https://www.rfc-editor.org/info/rfc3376>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810, Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004, DOI 10.17487/RFC3810, June 2004,
<https://www.rfc-editor.org/info/rfc3810>. <https://www.rfc-editor.org/info/rfc3810>.
skipping to change at page 13, line 11 skipping to change at line 580
[RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450,
DOI 10.17487/RFC7450, February 2015, DOI 10.17487/RFC7450, February 2015,
<https://www.rfc-editor.org/info/rfc7450>. <https://www.rfc-editor.org/info/rfc7450>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <https://www.rfc-editor.org/info/rfc7761>. 2016, <https://www.rfc-editor.org/info/rfc7761>.
13.2. Informative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
14.2. Informative References
[Algorhyme] [Algorhyme]
"Algorhyme", Wikipedia , n.d., Wikipedia, "Radia Perlman", September 2024,
<https://en.wikipedia.org/wiki/ <https://en.wikipedia.org/w/
Radia_Perlman#Spanning_Tree_Protocol>. index.php?title=Radia_Perlman&oldid=1245484160>.
[BGP-MULTICAST]
Zhang, Z. J., Giuliano, L., Patel, K., Wijnands, I.,
Mishra, M. P., and A. Gulko, "BGP Based Multicast", Work
in Progress, Internet-Draft, draft-ietf-bess-bgp-
multicast-08, 3 June 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
bgp-multicast-08>.
[BIER-AMT-Deployment] [BIER-AMT-Deployment]
"BIER + AMT Deployment in GEANT/RARE Network", IETF112 Mate, C. and F. Loui, "BIER & AMT implementation", IETF
Proceedings , n.d., 112 Proceedings, November 2021,
<https://datatracker.ietf.org/meeting/112/materials/ <https://datatracker.ietf.org/meeting/112/materials/
slides-112-mboned-bier-amt-depolyment-in-geantrare- slides-112-mboned-bier-amt-depolyment-in-geantrare-
network-00>. network-00>.
[BROADCAST-DELAY] [BROADCAST-DELAY]
"Broadcast Delay", Wikipedia , n.d., Wikipedia, "Broadcast delay", May 2024,
<https://en.wikipedia.org/wiki/Broadcast_delay>. <https://en.wikipedia.org/w/
index.php?title=Broadcast_delay&oldid=1225656951>.
[DVB-MABR] "Adaptive media streaming over IP multicast", DVB Document [DVB-MABR] DVB Project, "Adaptive media streaming over IP multicast",
A176 Rev.3 (Fourth edition) , n.d., <https://dvb.org/wp- DVB Document A176 Rev.3 (Fourth edition), March 2023,
content/uploads/2022/01/A176r3_Adaptive-Media-Streaming- <https://dvb.org/wp-content/uploads/2022/01/
over-IP-Multicast_Interim-Draft-TS- A176r3_Adaptive-Media-Streaming-over-IP-Multicast_Interim-
103-769-v121_March_2023.pdf>. Draft-TS-103-769-v121_March_2023.pdf>.
[EUMETCast-TERRESTRIAL-over-AMT] [EUMETCast-TERRESTRIAL-AMT]
"EUMETCast Terrestrial over AMT", IETF115 Proceedings , Britton, R. and R. Adam, "EUMETCast Terrestrial over AMT",
n.d., <https://datatracker.ietf.org/meeting/115/materials/ IETF 115 Proceedings, September 2022,
<https://datatracker.ietf.org/meeting/115/materials/
slides-115-mboned-eumetcast-over-amt>. slides-115-mboned-eumetcast-over-amt>.
[EUMETSAT-TERRESTRIAL] [EUMETSAT-TERRESTRIAL]
"EUMETSAT Terrestrial Service", IETF110 Proceedings , Espanyol, O., "EUMETSAT Terrestrial Service", IETF 110
n.d., <https://datatracker.ietf.org/meeting/110/materials/ Proceedings, February 2021,
<https://datatracker.ietf.org/meeting/110/materials/
slides-110-mboned-eumetsat-multicast-over-the-mbone-00>. slides-110-mboned-eumetsat-multicast-over-the-mbone-00>.
[I-D.ietf-bess-bgp-multicast] [GKM-IKEv2]
Zhang, Z. J., Giuliano, L., Patel, K., Wijnands, I.,
Mishra, M. P., and A. Gulko, "BGP Based Multicast", Work
in Progress, Internet-Draft, draft-ietf-bess-bgp-
multicast-08, 3 June 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
bgp-multicast-08>.
[I-D.ietf-ipsecme-g-ikev2]
Smyslov, V. and B. Weis, "Group Key Management using Smyslov, V. and B. Weis, "Group Key Management using
IKEv2", Work in Progress, Internet-Draft, draft-ietf- IKEv2", Work in Progress, Internet-Draft, draft-ietf-
ipsecme-g-ikev2-13, 21 August 2024, ipsecme-g-ikev2-18, 11 December 2024,
<https://datatracker.ietf.org/api/v1/doc/document/draft- <https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-
ietf-ipsecme-g-ikev2/>. g-ikev2-18>.
[I-D.ietf-spring-sr-replication-segment] [MAUD] Nilsson, M. E., Turnbull, R. S., Stevens, T. S., and S.
Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. Appleby, "Multicast-Assisted Unicast Delivery", IBC2023
J. Zhang, "SR Replication segment for Multi-point Service Tech Papers, September 2023, <https://www.ibc.org/
Delivery", Work in Progress, Internet-Draft, draft-ietf- technical-papers/ibc2023-tech-papers-multicast-assisted-
spring-sr-replication-segment-19, 28 August 2023, unicast-delivery/10235.article>.
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
sr-replication-segment-19>.
[I-D.jholland-quic-multicast] [Multicast-Menu]
"Multicast Menu", <https://menu.treedn.net>.
[Offnet-Sourcing-Multicast-Menu]
Delwiche, L., "Offnet Sourcing with the Multicast Menu",
IETF 114 Proceedings, July 2022,
<https://datatracker.ietf.org/meeting/114/materials/
slides-114-mboned-offnet-sourcing-with-the-multicast-menu-
01>.
[QUIC-Multicast]
Holland, J., Pardue, L., and M. Franke, "Multicast Holland, J., Pardue, L., and M. Franke, "Multicast
Extension for QUIC", Work in Progress, Internet-Draft, Extension for QUIC", Work in Progress, Internet-Draft,
draft-jholland-quic-multicast-05, 7 July 2024, draft-jholland-quic-multicast-05, 7 July 2024,
<https://datatracker.ietf.org/doc/html/draft-jholland- <https://datatracker.ietf.org/doc/html/draft-jholland-
quic-multicast-05>. quic-multicast-05>.
[MAUD] "Multicast-Assisted Unicast Delivery", IBC2023 Tech
Papers , n.d., <https://www.ibc.org/technical-papers/
ibc2023-tech-papers-multicast-assisted-unicast-
delivery/10235.article>.
[Multicast-Menu]
"Offnet Sourcing with the Multicast Menu", IETF114
Proceedings , n.d.,
<https://datatracker.ietf.org/meeting/114/materials/
slides-114-mboned-offnet-sourcing-with-the-multicast-menu-
01>.
[RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol [RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol
Independent Multicast - Sparse Mode (PIM-SM) Multicast Independent Multicast - Sparse Mode (PIM-SM) Multicast
Routing Security Issues and Enhancements", RFC 4609, Routing Security Issues and Enhancements", RFC 4609,
DOI 10.17487/RFC4609, October 2006, DOI 10.17487/RFC4609, October 2006,
<https://www.rfc-editor.org/info/rfc4609>. <https://www.rfc-editor.org/info/rfc4609>.
[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker,
"NACK-Oriented Reliable Multicast (NORM) Transport "NACK-Oriented Reliable Multicast (NORM) Transport
Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009,
<https://www.rfc-editor.org/info/rfc5740>. <https://www.rfc-editor.org/info/rfc5740>.
skipping to change at page 15, line 45 skipping to change at line 714
[RFC9049] Dawkins, S., Ed., "Path Aware Networking: Obstacles to [RFC9049] Dawkins, S., Ed., "Path Aware Networking: Obstacles to
Deployment (A Bestiary of Roads Not Taken)", RFC 9049, Deployment (A Bestiary of Roads Not Taken)", RFC 9049,
DOI 10.17487/RFC9049, June 2021, DOI 10.17487/RFC9049, June 2021,
<https://www.rfc-editor.org/info/rfc9049>. <https://www.rfc-editor.org/info/rfc9049>.
[RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. [RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos, Ed., "The Locator/ID Separation Protocol Cabellos, Ed., "The Locator/ID Separation Protocol
(LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022, (LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022,
<https://www.rfc-editor.org/info/rfc9300>. <https://www.rfc-editor.org/info/rfc9300>.
[Trees] "Trees", Poetry Foundation , n.d., [RFC9524] Voyer, D., Ed., Filsfils, C., Parekh, R., Bidgoli, H., and
Z. Zhang, "Segment Routing Replication for Multipoint
Service Delivery", RFC 9524, DOI 10.17487/RFC9524,
February 2024, <https://www.rfc-editor.org/info/rfc9524>.
[Trees] Kilmer, J., "Trees", Poetry Foundation,
<https://www.poetryfoundation.org/poetrymagazine/ <https://www.poetryfoundation.org/poetrymagazine/
poems/12744/trees>. poems/12744/trees>.
Appendix A. Netverses Appendix A. Netverses
With inspiration from (and apologies to) Radia Perlman [Algorhyme] With inspiration from (and apologies to) Radia Perlman [Algorhyme]
and Joyce Kilmer [Trees], the following poem is not intended to and Joyce Kilmer [Trees], the following poem is not intended to
provide any normative or informative technical value on TreeDN beyond provide any normative or informative technical value on TreeDN beyond
(mild) amusement for the reader who made it this far in the document: (mild) amusement for the reader who made it this far in the document:
skipping to change at page 16, line 30 skipping to change at line 748
A tree extended by AMT, A tree extended by AMT,
Enabling unicast-only receivers full delivery. Enabling unicast-only receivers full delivery.
A tree that scales to reach millions of places A tree that scales to reach millions of places
To viably support the highest of bitrate use cases. To viably support the highest of bitrate use cases.
A CDN is built by folks like me, A CDN is built by folks like me,
But only end users can generate enough demand to necessitate a tree. But only end users can generate enough demand to necessitate a tree.
Acknowledgements
Many thanks to those who have contributed to building and operating
the first TreeDN network on the Internet, including Pete Morasca,
William Zhang, Lauren Delwiche, Natalie Landsberg, Wayne Brassem,
Jake Holland, Andrew Gallo, Casey Russell, Janus Varmarken, Csaba
Mate, Frederic Loui, Max Franke, Todor Moskov, Erik Herz, Bradley
Cao, Katie Merrill, Karel Hendrych, Haruna Oseni, and Isabelle 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
Éric Vyncke for their thoughtful reviews and suggestions, Chris
Lemmons for his detailed shepherd review, and Stephen Farrell, Magnus
Westerlund, Reese Enghardt, Jurgen Schonwalder, Carlos Pignataro,
Erik Kline, Gunter Van de Velde, Warren Kumari, and Zaheduzzaman
Sarker for their last call reviews.
Authors' Addresses Authors' Addresses
Lenny Giuliano Lenny Giuliano
Juniper Networks Juniper Networks
2251 Corporate Park Drive 2251 Corporate Park Drive
Herndon, VA 20171, Herndon, VA 20171
United States of America United States of America
Email: lenny@juniper.net Email: lenny@juniper.net
Chris Lenart Chris Lenart
Verizon Verizon
22001 Loudoun County Parkway 22001 Loudoun County Parkway
Ashburn, VA 20147, Ashburn, VA 20147
United States of America United States of America
Email: chris.lenart@verizon.com Email: chris.lenart@verizon.com
Rich Adam Rich Adam
GEANT GEANT
City House City House
126-130 Hills Road 126-130 Hills Road
Cambridge Cambridge
CB2 1PQ CB2 1PQ
United Kingdom United Kingdom
Email: richard.adam@geant.org Email: richard.adam@geant.org
 End of changes. 107 change blocks. 
332 lines changed or deleted 380 lines changed or added

This html diff was produced by rfcdiff 1.48.