RFC 9706
TreeDN: Tree-Based Content Delivery Network (CDN) for Live Streaming to Mass Audiences
📮 RFC 9706: TreeDN, a Tree-Based CDN for Live Streaming to Mass Audiences 💖
okay so bestie, let's get into this 🎀 this RFC is by L. Giuliano (Juniper Networks), C. Lenart (Verizon), and R. Adam (GEANT) 🫶 it was published in January 2025 and it's Informational 💅 which means it's shared for info, NOT a standards-track spec, so nobody's being told to implement it 🌸 it's from the IETF, reviewed by the community and approved by the IESG ✨ it doesn't obsolete or update any other RFCs, so it's a brand new little gem 💎 its ISSN is 2070-1721 🦋
the main idea is that TreeDN is a tree-shaped CDN built for live streaming to HUGE crowds of viewers 🍓 🔥
Status of This Memo: this document is not an Internet Standards Track specification; it is published for informational purposes.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the 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.
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 (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
Table of Contents 🧚
1. Introduction
2. Requirements Language
3. Problem Statement
4. Applicability
5. Multicast Challenges in the Past
6. TreeDN Architecture
6.1. TreeDN Overlays
6.2. TreeDN Native On-Net
7. Replication-as-a-Service (RaaS)
8. Decentralization/Democratization of Content Sourcing
9. Transport-Layer-Related Differences between TreeDN and
Traditional CDNs
9.1. Integration with Unicast
9.2. Reliability, Adaptive Bitrates, and Congestion Control
9.3. Authorization and Encryption
10. TreeDN Deployments
11. Operational Considerations
12. Security Consideration
13. IANA Considerations
14. References
14.1. Normative References
14.2. Informative References
Appendix A. Netverses
Acknowledgements
Authors' Addresses1. Introduction ✨
okay so the intro is basically the vibe check 💅 live streaming is getting WILD. audiences are hitting record numbers for big moments, and bitrates keep climbing for stuff like 4K, 8K, and Augmented Reality (AR) 😭 that means live streaming can really stress out network resources, no cap.
TreeDN is a tree-based Content Delivery Network (CDN) architecture built to handle exactly those scaling problems when you're streaming to mass audiences 🌳 operators can offer Replication-as-a-Service (RaaS) for a fraction of what traditional, unicast-based CDNs cost, and sometimes it's at no extra cost to the infrastructure 🤑 it's not just about making existing multi-destination traffic run more efficiently either. it also unlocks new kinds of content and use cases that weren't really possible or affordable with the old CDN approach 🦋 and finally, TreeDN is decentralized and kind of democratizing, making content distribution accessible to more people by slashing the cost of replication 🌈 it's giving "everyone gets a seat at the table" energy 🎀
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 🚨
okay so live sports are a whole different beast 🏈 viewers of live sporting events have a much lower tolerance for long playout buffers than regular on-demand streaming 😭 they're used to broadcast TV, where there's only a very short buffer for broadcast delays to stop profanity and other objectionable stuff from going on air (the famous "seven-second delay" [BROADCAST-DELAY]) 🙈 with micro-betting, even a 5 to 10 second delay can be too long 💀 for on-demand movies, though, an extra one- or two-minute buffer is totally fine. but if live sports had buffers that long, viewers could get spoiled by a game-winning score from a text from a friend or a cheer from the bar across the street, minutes before they see it themselves 😭🍿
another thing that makes live streaming unique is the join rate 📈 on-demand video can eat tons of network resources, but the viewing rate is smooth and predictable 🌸 service providers (SPs) see traffic creep up gradually over the evening, matching prime-time habits 🌙 live streams are more like a step function 🪜 with way less predictability, because huge crowds all tune in to the game at the same moment 💥
past efforts to replicate multi-destination traffic more efficiently have had mixed luck with adoption 🥲 IP multicast is widely deployed on financial networks, video distribution networks, L3VPN networks, and some enterprises 🏢 but most of those deployments live inside "walled-garden" networks 🧱 multicast over the global Internet hasn't really taken off, since only a very small portion of the Internet is multicast enabled right now 🫠
TreeDN is a tree-based CDN architecture that grew out of the evolution of network-based replication mechanisms, built on lessons from what did and didn't work in the past 🌳 it tackles the core issues that have kept multicast from being adopted on the global Internet, and it gives SPs a chance to offer new Replication-as-a-Service (RaaS) offerings to content providers 🎁 it does this while using network resources more efficiently by cutting out duplicated traffic, which makes the experience better for end users too 🥰 the trick is combining a simplified model of native multicast with network overlays that reach receivers on unicast-only parts of the Internet 🧩
because it handles multi-destination traffic more efficiently, TreeDN can enable new kinds of content, like AR live streaming to mass audiences 🦋 stuff that wasn't possible or affordable on the Internet before, thanks to unicast's inefficiencies 🙅♀️
4. Applicability 🌈
the primary use case throughout this doc is live streaming of multimedia content (e.g., audio, video, AR, and real-time telemetry data) 📺 but TreeDN can deliver efficiently for ANY content that needs to be replicated and sent to multiple destinations 💅 for example, big software updates (e.g., OS upgrades) that have to reach tons of end users in a very short window can strain network resources badly 😵 with TreeDN, the network can handle that a lot more efficiently 🎀
5. Multicast Challenges in the Past 🕰️
these are some of the biggest problems that held back IP multicast over the global Internet 👀 this isn't meant to be a complete list, just one that gives context for how TreeDN solves them ✨
- The "All or Nothing" problem: IP multicast requires 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) [RFC7761] or the Multipoint Label Distribution Protocol (mLDP) [RFC6388]). This requirement creates a bar to deployment that is practically impossible to overcome. 😤
- The "It's Too Complex" problem: Operators have long complained that multicast routing protocols like PIM-SM are simply too complex, making it costly to design, configure, manage, and troubleshoot IP multicast in the network. 🤯
- The "Chicken and Egg" problem: There's not much multicast content because there's not much of a multicast-enabled audience, but there's not much of a multicast-enabled audience because there's not much multicast content. 🐣🥚
TreeDN is the evolution of network-based replication, built on lessons learned over decades, and it's designed to solve the problems listed above 💖 okay that's the setup, bestie! part 2 is where the architecture gets spicy 🌶️🧚
6. TreeDN Architecture ✨
okay so TreeDN is lowkey genius 🧚 it takes a simplified multicast setup and pairs it with network overlays so the stream can reach receivers on unicast-only networks. the overlay part is what makes it work in the real world, where networks are wildly different from each other. the replication service ends up available to users and apps across the whole global Internet, no matter what protocols are running in the underlying networks (the underlay) 💅
TreeDN Provider
+-------------------------------+
| |
| Native Multicast On-Net |
+----------+ | (PIM-SSM) |
| Content/ |----+ |
| Mcast | | |
| Source | | +-----------+
+----------+ +---|-------|-------| AMT Relay | +--------------+
| | +----|------+ | Unicast-Only |
+-+ +-+ . | Network |
+-+ +-+ ..........|........ |
Native Content AMT Tunnel +-------.------+
Receivers .
AMT +-+
Gateway +-+
|
Content
Receiver
Figure 1: TreeDN Provider Example6.1. TreeDN Overlays
one overlay tech TreeDN uses is Automatic Multicast Tunneling (AMT) [RFC7450] 🦋 with AMT, end hosts stuck on unicast-only networks (AMT Gateways) can build tunnels on their own to routers on the multicast-enabled part of the network (AMT Relays) and receive multicast streams. the AMT Gateway is a thin software client that usually lives on the receiving end host and starts the tunnel at an AMT Relay. the AMT Relay is a tunnel server that usually sits at the border of the multicast network.
AMT lets any end host on the Internet receive multicast content, even if their local provider doesn't support multicast (aka, "off-net receivers"). this solves the "All or Nothing" problem 🙌 links and devices that don't support multicast just get tunneled over, so they're no longer a blocker for the replication service for end users. networks that do deploy and support multicast, plus the content providers serving up multicast content, get to enjoy efficient replication and delivery 🍓 and it gets better: those benefits can give operators who don't support multicast yet a reason to turn it on. that's a key benefit of incremental deployment, described in Section 4.3 of [RFC9049]. once those operators decide the cost of carrying duplicated unicast tunnels is bigger than the cost of deploying multicast, they're more likely to flip the switch on their networks. so TreeDN supports incremental deployment in a way traditional (non-overlay) multicast networking never could 💜 finally, AMT also solves the "Chicken and Egg" problem, because every end host on the global Internet that can reach an AMT Relay can become an audience member ✨
to support receiving on both native and non-native networks, receiving hosts can first try to join the traffic natively. if no multicast traffic shows up, they can fall back to AMT. the application layer can handle this fallback 🫶
on top of AMT, other overlay techs like the Locator/ID Separation Protocol (LISP) [RFC9300] can deliver content from multicast-enabled networks to end hosts separated by parts of the network (at the last/middle/first mile) that don't support multicast 🌈
6.2. TreeDN Native On-Net
networks that support multicast provide the native on-net part of TreeDN 💖 the main requirement for that part is supporting Source-Specific Multicast (SSM) [RFC4607]. PIM-SSM is basically a subset of PIM-SM, and it's the multicast routing protocol usually used for SSM 😭 but honestly any multicast routing protocol that can support SSM works in the TreeDN native on-net part. examples: mLDP, Global Table Multicast (GTM) [RFC7716], BGP-based Multicast [BGP-MULTICAST], or even BGP Multicast VPN (BGP-MVPN) [RFC6513] for operators who carry the global routing table in a Virtual Routing and Forwarding (VRF) table. same deal for the data plane: any data plane tech that supports SSM can be used, including Bit Index Explicit Replication (BIER) [RFC8279] and Segment Routing (SR) Point-to-Multipoint (P2MP) [RFC9524] 🧚
the big win of SSM as the native on-net part is that it radically simplifies the control plane needed for replication in the network 🔥 it does this by moving source discovery out of the network layer and into some kind of out-of-band mechanism, usually in the application layer. with SSM, the receiver uses the Internet Group Management Protocol Version 3 (IGMPv3) [RFC3376] for IPv4, or the Multicast Listener Discovery Version 2 (MLDv2) protocol [RFC3810] for IPv6, to specify both the source and group address of the multicast stream. that lets the last-hop router join the multicast stream immediately along the shortest-path tree (SPT), with no shared trees needed 👑 this handles the "It's Too Complex" problem. without network-based source discovery, most of multicast's complexity just disappears, which makes deploying and operating a multicast network way cheaper 💅 more on why this SSM-only approach makes sense can be found in Any-Source Multicast (ASM) Deprecation [RFC8815] 🌸
7. Replication-as-a-Service (RaaS)
content providers have traditionally used CDNs to distribute content to big audiences, basically outsourcing replication to CDN providers 🎀 most CDNs use unicast delivery, because multicast isn't really an option when it isn't generally available on the global Internet 😭 TreeDN is a CDN architecture that uses tree-based replication to use network resources more efficiently when delivering simultaneous multi-destination traffic ✨ by using overlay networking for the "All or Nothing" and "Chicken and Egg" problems, and SSM for the "It's Too Complex" problem, TreeDN avoids the practical issues that used to stop multicast from being a viable option for CDN providers 🙌
TreeDN has several advantages over traditional unicast-based CDNs 🦋 first, the TreeDN functionality can be delivered entirely by existing network infrastructure. specifically, for operators with routers that support AMT natively, multicast traffic can go straight to end users without specialized CDN devices. those are usually servers that need to be racked, powered, cooled, and plugged into router ports that could've been used by paying customers instead 🍓 so SPs can offer new RaaS functionality to content providers at potentially zero extra cost in new equipment 💖
TreeDN is also an open architecture built on mature, IETF-specified, widely implemented network protocols 🌈 it also needs way less coordination between the content provider and the CDN operator 🫶 there are no storage requirements for the data and no group-key management issues, since a TreeDN provider just forwards packets 💅 a TreeDN provider only needs enough accounting data (e.g., traffic data, number of AMT tunnels, etc.) to bill customers properly for the service. meanwhile traditional unicast-based CDNs often bring in proprietary, non-interoperable technologies and need a lot of coordination between the content provider and the CDN for things like file storage, data protection, and key management 😩
TreeDN also introduces a deployment model that needs new considerations for transport-layer mechanisms that traditional unicast-based CDNs often depend on 👑 you can find a discussion of these considerations and differences in Section 9 ✨
8. Decentralization/Democratization of Content Sourcing
TreeDN is an inherently decentralized architecture 🌸 that cuts the cost of content sourcing, because any host connected to a multicast-enabled network, or on a source-capable overlay, can send out a single data stream that an arbitrarily large audience can reach 🧚 from the source's point of view, the marginal cost of reaching each additional audience member drops to zero. that's why TreeDN democratizes content sourcing on the Internet 🔥🎀
9. Transport-Layer-Related Differences between TreeDN and Traditional CDNs
the focus of this document is the network-layer parts that make up the TreeDN architecture 🦋 this section covers some of the key transport-layer differences between TreeDN and traditional unicast-based CDNs that you should think about when deploying TreeDN-based services 💖 in a lot of cases, these issues have more to do with differences between TCP and UDP than with differences between unicast and multicast, so UDP-based solutions can be used to address most gaps 🫶 the goal of this section is to point to some existing work that addresses these gaps, and to suggest further work the IETF could take on. the details of these transport-layer mechanisms are beyond the scope of this document 🙈
9.1. Integration with Unicast
since SSM inherently implies one-to-many, unidirectional traffic flows, mechanisms that rely on two-way communication between receivers and the content provider are not a great fit for SSM delivery 😭 think bespoke advertising, telemetry data from receivers about end-user experience, distributing decryption keys, switching to higher or lower bandwidth streams, and so on 💅 so separate unicast streams between receivers and content providers may be used for this kind of "out-of-band" function, while SSM delivers the actual content of interest ✨ these "out-of-band" unicast streams SHOULD use the same congestion control and authentication mechanisms 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 🌈
9.2. Reliability, Adaptive Bitrates, and Congestion Control 🔥
Okay so traditional unicast CDNs usually run on HTTPS over TCP, which means they get to use all the granular TCP goodies for reliability, congestion control, and adaptive bitrate streaming 💅. The catch is that this granularity means sending a separate data stream to every single viewer 😭. Multicast usually rides on UDP, which doesn't come with a lot of those TCP perks, but it scales way better when a massive crowd is watching at the same time 🌈.
Forward Error Correction (FEC) is a mechanism that has shown full recovery for up to 5% packet loss and interruptions up to 400 ms for multicast data streams in [EUMETSAT-TERRESTRIAL]. Then there's NACK-Oriented Reliable Multicast (NORM) [RFC5740], which uses FEC-based repair and other Reliable Multicast Transport (RMT) building blocks to deliver end-to-end reliable transport over multicast networks 🦋.
QUIC [RFC9000] is another popular transport with traditional unicast CDNs. It runs on UDP, but it doesn't currently support multicast. Multicast extensions to QUIC have been proposed in [QUIC-Multicast] 🧚.
Section 4.1 of [RFC8085] explains how a sender can spread its data across multiple multicast source-group channels, so each receiver can join the channels that best match its own reception rate capability. That's how you get adaptive bitrate capabilities for multicast streams 🎀. [DVB-MABR] and [MAUD] go deep on an architecture that enables reliability and dynamic bitrate adaptation, so go check those out if you're curious 🤓.
Now the rules, because they matter 👑. TreeDN deployments MUST follow the congestion control guidelines described in Section 4.1.4.2 of [RFC7450], no exceptions. A multicast application being distributed over TreeDN deployments SHOULD implement congestion control for its data transmission as described in Section 4.1 of [RFC8085]. The AMT gateway SHOULD use the topologically closest AMT relay, and Section 3.1 of [RFC8777] lays out a set of procedures for optimal relay selection ✨.
9.3. Authorization and Encryption 🔐
Here's the vibe check: a multicast sender typically has little to no control or visibility over which end hosts receive the data stream 🙈. That's where encryption comes in. It can make sure only authorized receivers can access meaningful data. Even if unauthorized end hosts (like non-paying ones) receive the stream, without decryption keys the data is totally useless 🔑.
[GKM-IKEv2] describes an extension to the Internet Key Exchange Protocol Version 2 (IKEv2) for group key management. [DVB-MABR] and [MAUD] also extensively describe an architecture that includes encryption of multicast streams 💜.
10. TreeDN Deployments 🌍
Let's look at some real-life TreeDN deployments, because these are giving serious main character energy 💖.
EUMETCast Terrestrial is a service from the European Organisation for the Exploitation of Meteorological Satellites (EUMETSAT) that delivers meteorological satellite data to end users for things like operational monitoring of climates and detection of global climate changes 🌦️. EUMETCast Terrestrial connects to the GEANT network, which provides TreeDN services to deliver this real-time data natively to end users on multicast-enabled networks. It also reaches end users on unicast-only networks through a global deployment of AMT relays 🛰️. You can find the details of the EUMETCast Terrestrial service over the GEANT TreeDN network in [EUMETCast-TERRESTRIAL-AMT]. For how this deployment handles encryption, authorization, reliability, and unicast feedback channels for end-to-end file delivery monitoring, check [EUMETSAT-TERRESTRIAL] 🫶.
The Multicast Menu [Multicast-Menu] is a web-based portal that can list and launch active multicast streams available on a global TreeDN network of various research and education networks 🍓. Details on this TreeDN network, plus the Multicast Menu itself, are in [Offnet-Sourcing-Multicast-Menu] 📺.
The RARE network is a global testbed that interconnects several National Research and Education Networks (NRENs) via routers running BIER 🧪. AMT relays are deployed to carry multicast traffic from sources on the RARE network to receivers on unicast-only networks across the Internet 🌸. Details of the RARE network are in [BIER-AMT-Deployment].
11. Operational Considerations 🛠️
TreeDN is basically the synthesis of SSM plus overlay networking tech like AMT, so honestly? It's iconic 😭. That means any existing tools for managing, operating, and troubleshooting a PIM-SSM domain and an AMT deployment can also be used to manage a TreeDN deployment. Protocol error handling for PIM-SSM can be found in [RFC4607] and Section 4.8 of [RFC7761], and for AMT it's in [RFC7450] 📋.
One potential operational perk of a multicast-based approach like TreeDN, compared to a traditional unicast-based CDN, is the visibility that multicast state gives you inside the routing infrastructure 👀. Multicast routers keep a forwarding cache of multicast flows that usually includes the source address, group address, incoming and outgoing interfaces, and forwarding rate. Generally speaking, that kind of flow state isn't typically available in core networks for unicast. So additional tools outside the routing infrastructure are usually needed to monitor CDN performance and troubleshoot issues like locating packet loss 🔍. Of course, this perk comes with a cost: more state has to be maintained in the routers for multicast 💸.
Also, since multicast leverages Reverse Path Forwarding (RPF), the source of the content can potentially have a bigger say in the path taken through the network from source to native receivers or AMT relays 🗺️. The BGP peer advertising reachability of the source's subnet can do that in ways where a particular path is preferred for multicast distribution. Those methods aren't as easy to pull off with traditional, destination-based unicast routing 🙃.
12. Security Consideration 🚨
Okay, serious moment, bestie 🥺. Since TreeDN is basically the synthesis of SSM plus overlay networking tech like AMT, the TreeDN architecture introduces no new security threats that aren't already documented in SSM and the overlay technologies that make it up. In particular, Section 6 of [RFC7450] candidly notes that AMT, like UDP, IGMP, and MLD, provides no mechanisms for ensuring message delivery or integrity. It also doesn't provide confidentiality, since sources and groups joined through IGMP or MLD could be associated with the particular content being requested 😱.
[RFC4609] and [RFC8815] describe the additional security benefits of using SSM instead of ASM 🔒.
13. IANA Considerations 📝
This document has no IANA actions. Nothing to register here, babe ✨.
14. References 📚
14.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.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
<https://www.rfc-editor.org/info/rfc3376>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004,
<https://www.rfc-editor.org/info/rfc3810>.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
<https://www.rfc-editor.org/info/rfc4607>.
[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
Thomas, "Label Distribution Protocol Extensions for Point-
to-Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011,
<https://www.rfc-editor.org/info/rfc6388>.
[RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450,
DOI 10.17487/RFC7450, February 2015,
<https://www.rfc-editor.org/info/rfc7450>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <https://www.rfc-editor.org/info/rfc7761>.
[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 ✨
Okay bestie, these are the extra-credit reads. Not required to build the thing, but super helpful if you want the full story. 📚
[Algorhyme]
Wikipedia, "Radia Perlman", September 2024,
<https://en.wikipedia.org/w/
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]
Mate, C. and F. Loui, "BIER & AMT implementation", IETF
112 Proceedings, November 2021,
<https://datatracker.ietf.org/meeting/112/materials/
slides-112-mboned-bier-amt-depolyment-in-geantrare-
network-00>.
[BROADCAST-DELAY]
Wikipedia, "Broadcast delay", May 2024,
<https://en.wikipedia.org/w/
index.php?title=Broadcast_delay&oldid=1225656951>.
[DVB-MABR] DVB Project, "Adaptive media streaming over IP multicast",
DVB Document A176 Rev.3 (Fourth edition), March 2023,
<https://dvb.org/wp-content/uploads/2022/01/
A176r3_Adaptive-Media-Streaming-over-IP-Multicast_Interim-
Draft-TS-103-769-v121_March_2023.pdf>.
[EUMETCast-TERRESTRIAL-AMT]
Britton, R. and R. Adam, "EUMETCast Terrestrial over AMT",
IETF 115 Proceedings, September 2022,
<https://datatracker.ietf.org/meeting/115/materials/
slides-115-mboned-eumetcast-over-amt>.
[EUMETSAT-TERRESTRIAL]
Espanyol, O., "EUMETSAT Terrestrial Service", IETF 110
Proceedings, February 2021,
<https://datatracker.ietf.org/meeting/110/materials/
slides-110-mboned-eumetsat-multicast-over-the-mbone-00>.
[GKM-IKEv2]
Smyslov, V. and B. Weis, "Group Key Management using
IKEv2", Work in Progress, Internet-Draft, draft-ietf-
ipsecme-g-ikev2-20, 16 January 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-
g-ikev2-20>.
[MAUD] Nilsson, M. E., Turnbull, R. S., Stevens, T. S., and S.
Appleby, "Multicast-Assisted Unicast Delivery", IBC2023
Tech Papers, September 2023, <https://www.ibc.org/
technical-papers/ibc2023-tech-papers-multicast-assisted-
unicast-delivery/10235.article>.
[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
Extension for QUIC", Work in Progress, Internet-Draft,
draft-jholland-quic-multicast-06, 7 January 2025,
<https://datatracker.ietf.org/doc/html/draft-jholland-
quic-multicast-06>.
[RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol
Independent Multicast - Sparse Mode (PIM-SM) Multicast
Routing Security Issues and Enhancements", RFC 4609,
DOI 10.17487/RFC4609, October 2006,
<https://www.rfc-editor.org/info/rfc4609>.
[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker,
"NACK-Oriented Reliable Multicast (NORM) Transport
Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009,
<https://www.rfc-editor.org/info/rfc5740>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <https://www.rfc-editor.org/info/rfc6513>.
[RFC7716] Zhang, J., Giuliano, L., Rosen, E., Ed., Subramanian, K.,
and D. Pacella, "Global Table Multicast with BGP Multicast
VPN (BGP-MVPN) Procedures", RFC 7716,
DOI 10.17487/RFC7716, December 2015,
<https://www.rfc-editor.org/info/rfc7716>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>.
[RFC8777] Holland, J., "DNS Reverse IP Automatic Multicast Tunneling
(AMT) Discovery", RFC 8777, DOI 10.17487/RFC8777, April
2020, <https://www.rfc-editor.org/info/rfc8777>.
[RFC8815] Abrahamsson, M., Chown, T., Giuliano, L., and T. Eckert,
"Deprecating Any-Source Multicast (ASM) for Interdomain
Multicast", BCP 229, RFC 8815, DOI 10.17487/RFC8815,
August 2020, <https://www.rfc-editor.org/info/rfc8815>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[RFC9049] Dawkins, S., Ed., "Path Aware Networking: Obstacles to
Deployment (A Bestiary of Roads Not Taken)", RFC 9049,
DOI 10.17487/RFC9049, June 2021,
<https://www.rfc-editor.org/info/rfc9049>.
[RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos, Ed., "The Locator/ID Separation Protocol
(LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022,
<https://www.rfc-editor.org/info/rfc9300>.
[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/
poems/12744/trees>.Appendix A. Netverses 🧚
Okay so this appendix is a little poem, and it's literally not normative or informative in any technical sense. It's just here for a bit of (mild) amusement for whoever made it this far. 🌸 It's inspired by Radia Perlman [Algorhyme] and Joyce Kilmer [Trees], and we're giving them both a huge apology for the remix. 🙈
I think that I shall never see
A CDN more lovely than a tree.
A tree whose crucial property
Is efficient mass-audience delivery.
Using SSM for simplified operation
Of native branches that eliminate duplication.
A tree extended by AMT,
Enabling unicast-only receivers full delivery.
A tree that scales to reach millions of places
To viably support the highest of bitrate use cases.
A CDN is built by folks like me,
But only end users can generate enough demand to necessitate a tree.Acknowledgements 🫶
Okay bestie, the big thank-you list! 💖 Huge shoutout to everyone who helped build and run the first TreeDN network on the Internet, and that's 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 idea of writing up the TreeDN architecture was sparked by a conversation with Dino Farinacci and Mike McBride, so thank you both! ✨ Also thanks to Jeff Haas, Vinod Kumar, Ron Bonica, Jeffrey Zhang, and Éric Vyncke for their thoughtful reviews and suggestions, and to Chris Lemmons for the detailed shepherd review. 🦋 And last but not least, thanks to 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. You all are literally iconic. 🌈
Authors' Addresses 🦋
Lenny Giuliano
Juniper Networks
2251 Corporate Park Drive
Herndon, VA 20171
United States of America
Email: lenny@juniper.net
Chris Lenart
Verizon
22001 Loudoun County Parkway
Ashburn, VA 20147
United States of America
Email: chris.lenart@verizon.com
Rich Adam
GEANT
City House
126-130 Hills Road
Cambridge
CB2 1PQ
United Kingdom
Email: richard.adam@geant.org📦 where this page comes from
- ietf: rfc9706 2025-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms