Internet Engineering Task Force (IETF) L. Giuliano
Request for Comments: 9706 Juniper Networks
Category: Informational C. Lenart
ISSN: 2070-1721 Verizon
R. Adam
GEANT
January 2025
As Internet audience sizes for high-interest live events reach unprecedented levels and bitrates climb to support formats and applications such as 4K, 8K, and 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, at no additional cost to the infrastructure. In addition to efficiently utilizing network resources to deliver existing multi-destination traffic, this architecture also enables new types of content and use cases that previously 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.
高度なライブイベントのインターネットオーディエンスサイズが前例のないレベルに達し、ビットレートが上昇して4K、8K、拡張現実（AR）などの形式やアプリケーションをサポートするため、ライブストリーミングはネットワークリソースにユニークなタイプのストレスをかける可能性があります。Treednは、大量の視聴者へのライブストリーミングの特徴的なスケーリングの課題に対処するために設計されたツリーベースのコンテンツ配信ネットワーク（CDN）アーキテクチャです。Treednにより、オペレーターは、従来のユニキャストベースのCDNのコストの一部で、サービスとしてのレプリケーション（RAAS）を提供できます。ネットワークリソースを効率的に利用して既存のマルチデスティングトラフィックを提供することに加えて、このアーキテクチャは、従来のCDNアプローチを使用して以前は不可能または経済的に実行可能であった新しいタイプのコンテンツとユースケースも可能にします。最後に、Treednは分散化されたアーキテクチャであり、民主化技術であり、複製のコストを劇的に削減することにより、より多くの人々がコンテンツ分布をよりアクセスしやすくします。
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.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。RFC 7841のセクション2を参照してください。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9706で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
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' Addresses
As Internet audience sizes for high-interest live events reach unprecedented levels and bitrates climb to support formats and applications such as 4K, 8K, and 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, at no additional cost to the infrastructure. In addition to efficiently utilizing network resources to deliver existing multi-destination traffic, this architecture also enables new types of content and use cases that previously 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.
高度なライブイベントのインターネットオーディエンスサイズが前例のないレベルに達し、ビットレートが上昇して4K、8K、拡張現実（AR）などの形式やアプリケーションをサポートするため、ライブストリーミングはネットワークリソースにユニークなタイプのストレスをかける可能性があります。Treednは、大量の視聴者へのライブストリーミングの特徴的なスケーリングの課題に対処するために設計されたツリーベースのコンテンツ配信ネットワーク（CDN）アーキテクチャです。Treednにより、オペレーターは、従来のユニキャストベースのCDNのコストの一部で、サービスとしてのレプリケーション（RAAS）を提供できます。ネットワークリソースを効率的に利用して既存のマルチデスティングトラフィックを提供することに加えて、このアーキテクチャは、従来のCDNアプローチを使用して以前は不可能または経済的に実行可能であった新しいタイプのコンテンツとユースケースも可能にします。最後に、Treednは分散化されたアーキテクチャであり、民主化技術であり、複製のコストを劇的に削減することにより、より多くの人々がコンテンツ分布をよりアクセスしやすくします。
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.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Live streaming to mass audiences can impose unique demands on network resources. For example, live sporting events that broadcast over the Internet to end users have a much lower tolerance for long playout buffers than typical on-demand video streaming. Viewers of live sporting events have long been conditioned by broadcast television to expect to see the content in real time, with only very short buffers for broadcast delays to prevent profanity and other objectionable content from making on the air (this is known as the "seven-second delay" [BROADCAST-DELAY]). With micro-betting, even this 5 to 10 second delay can be too long. By comparison, when watching on-demand movies, an extra one- or two-minute playout buffer tends to be perfectly acceptable for viewers. If playout buffers for live sports are that long, viewers run the risk of being alerted to a game-winning score from text messages from friends or cheers from the bar across the street minutes before they view it themselves.
大規模な視聴者へのライブストリーミングは、ネットワークリソースに独自の要求を課すことができます。たとえば、インターネットを介してエンドユーザーにブロードキャストするライブスポーツイベントは、典型的なオンデマンドビデオストリーミングよりも長いプレイアウトバッファーに対する許容度がはるかに低くなっています。ライブスポーツイベントの視聴者は、放送テレビによって長い間、リアルタイムでコンテンツを見ることを期待するために条件付けられてきました。冒とくやその他の不快なコンテンツが空中に作らないようにするための非常に短いバッファーしかありません（これは「7つ」と呼ばれています-second Delay "[Broadcast-Delay]）。マイクロベットでは、この5〜10秒の遅延でさえ長すぎる場合があります。比較すると、オンデマンド映画を見ているとき、1分または2分間の追加のプレイアウトバッファーは、視聴者にとって完全に受け入れられる傾向があります。ライブスポーツのプレイアウトバッファーが長い場合、視聴者は、自分で見る前に数分前に、友人からのテキストメッセージや、通りの向こうのバーからの歓声からゲームに勝ったスコアにアラートされるリスクを負います。
Another unique characteristic of live streaming is the join rate. While on-demand video streaming can consume massive amounts of network resources, the viewing rates tend to be smooth and predictable. Service Providers (SPs) observe gradual levels of traffic increases over the evening hours corresponding to prime-time viewing habits. By comparison, viewing rates of live video streams can more closely resemble a step function with much less predictability as mass audiences of viewers tune in to watch the game at the same time.
ライブストリーミングのもう1つのユニークな特徴は、結合レートです。オンデマンドのビデオストリーミングは大量のネットワークリソースを消費する可能性がありますが、視聴率はスムーズで予測可能になる傾向があります。サービスプロバイダー（SPS）は、プライムタイムの視聴習慣に対応する夕方の時間にわたって、トラフィックの段階的なレベルの増加を観察します。それに比べて、ライブビデオストリームの視聴率は、視聴者の大衆オーディエンスが同時にゲームを見るためにチューニングするため、予測可能性がはるかに低いステップ関数にぴったりと似ています。
Previous efforts for more efficient network replication of multi-destination traffic have experienced mixed success in terms of adoption. IP multicast is widely deployed on financial networks, video distribution networks, L3VPN networks, and certain enterprises. However, most of these deployments are restricted to "walled-garden" networks. Multicast over the global Internet has failed to gain traction, as only a very small portion of the Internet is multicast enabled at this time.
マルチ誘引トラフィックのより効率的なネットワーク複製のための以前の取り組みは、採用の面で混合成功を経験しています。IPマルチキャストは、財務ネットワーク、ビデオ配信ネットワーク、L3VPNネットワーク、および特定の企業に広く展開されています。ただし、これらの展開のほとんどは、「壁画」ネットワークに制限されています。グローバルインターネット上のマルチキャストは、インターネットのごくわずかな部分のみがマルチキャストを有効にしているため、牽引力を得ることができませんでした。
TreeDN is a tree-based CDN architecture that is the result of the evolution of network-based replication mechanisms and is based on lessons learned from what has and has not worked well in the past. TreeDN addresses the fundamental issues of what has hindered multicast from adoption on the global Internet and enables SPs the opportunity to deliver new Replication-as-a-Service (RaaS) offerings to content providers, while more efficiently utilizing network resources by eliminating duplicated traffic. Thus, this improves the experience of end users. TreeDN accomplishes this with the combination of a simplified model of native multicast along with network overlays to reach receivers on unicast-only parts of the Internet.
Treednは、ネットワークベースの複製メカニズムの進化の結果であるツリーベースのCDNアーキテクチャであり、過去にうまく機能していないことから学んだ教訓に基づいています。Treednは、マルチキャストがグローバルなインターネットでの採用を妨げているものの基本的な問題に対処し、SPSがコンテンツプロバイダーに新しいレプリケーション（RAAS）の提供を提供する機会を可能にし、重複するトラフィックを排除することでネットワークリソースをより効率的に利用することができます。したがって、これによりエンドユーザーのエクスペリエンスが向上します。Treednは、ネットワークオーバーレイとともにネットワークオーバーレイとともに、ネットワークマルチキャストの単純化されたモデルの組み合わせでこれを達成し、インターネットのユニキャストのみの部分のレシーバーに到達します。
By more efficiently supporting multi-destination traffic, TreeDN is an architecture that can enable new types of content (such as AR live streaming to mass audiences) that previously weren't possible or economically viable on the Internet due to the inefficiencies of unicast.
マルチデステーショントラフィックをより効率的にサポートすることにより、Treednは、ユニキャストの効率性のためにインターネット上で以前は不可能または経済的に実行可能であった新しいタイプのコンテンツ（ARライブストリーミングなど）を可能にするアーキテクチャです。
While the primary use case mentioned throughout this document is live streaming of multimedia content (e.g., audio, video, AR, and real-time telemetry data), the TreeDN architecture can provide efficient delivery for any content that needs to be replicated and delivered to multiple destinations. For example, large software file updates (e.g., OS upgrades) that need to be delivered to many end users in a very short window of time can cause significant strain on network resources. Using TreeDN, this use case can be handled much more efficiently by the network.
このドキュメント全体で言及されている主要なユースケースは、マルチメディアコンテンツ（オーディオ、ビデオ、AR、リアルタイムテレメトリデータなど）のライブストリーミングですが、Treednアーキテクチャは、複製および配信する必要があるコンテンツに効率的な配信を提供できます。複数の目的地。たとえば、非常に短い時間内に多くのエンドユーザーに配信する必要がある大きなソフトウェアファイルの更新（OSのアップグレードなど）は、ネットワークリソースに大きな負担をかける可能性があります。Treednを使用して、このユースケースは、ネットワークによりはるかに効率的に処理できます。
The following issues have been some of the primary challenges for deployment of IP multicast over the global Internet. This is not intended to be an exhaustive list but rather a list that provides context for the solution and how it addresses these primary challenges.
以下の問題は、グローバルインターネット上でIPマルチキャストを展開するための主要な課題の一部です。これは、網羅的なリストではなく、ソリューションのコンテキストとこれらの主要な課題にどのように対処するかを提供するリストです。
* 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.
* 「すべてまたは何もない」問題：IPマルチキャストでは、ソースとレシーバーの間のすべてのレイヤー3ホップがマルチキャストを有効にする必要があります。グローバルなインターネットでユビキタスな可用性を実現するために、これは本質的に、すべてのルーターとすべてのエンドホストのファイアウォール上のほぼすべてのインターフェイスがマルチキャストルーティングプロトコル（プロトコル独立マルチキャスト - スパースモード（PIM -SM）[RFC7761など）をサポートする必要があることを意味します。マルチポイントラベル分布プロトコル（MLDP）[RFC6388]）。この要件により、展開することは事実上不可能な展開を作成します。
* 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.
* 「それは複雑すぎる」という問題：オペレーターは、PIM-SMのようなマルチキャストルーティングプロトコルが単純に複雑すぎて、ネットワーク内のIPマルチキャストの設計、構成、管理、トラブルシューティングに費用がかかると長い間不満を述べてきました。
* 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 based on lessons learned over decades and is designed to address the problems listed above.
Treednは、数十年にわたって学んだ教訓に基づいたネットワークベースの複製の進化であり、上記の問題に対処するように設計されています。
TreeDN leverages a simplified model for multicast deployment combined with network overlays to deliver traffic to receiving hosts on unicast-only networks. With network overlays, a service can be achieved and delivered to end users while recognizing and tolerating the practical realities of what is possible over a network as diverse as the global Internet. That is, the replication service is available to users and applications across the global Internet regardless of what protocols may exist in the underlying networks that constitute the underlay.
Treednは、ネットワークオーバーレイと組み合わせたマルチキャスト展開用の簡略化されたモデルを活用して、ユニキャストのみのネットワークで受信ホストにトラフィックを配信します。ネットワークオーバーレイを使用すると、グローバルなインターネットと同じくらい多様なネットワーク上で可能なことの実用的な現実を認識し、許容しながら、エンドユーザーにサービスを達成して配信できます。つまり、レプリケーションサービスは、アンダーレイを構成する基礎となるネットワークにどのプロトコルが存在するかに関係なく、グローバルインターネット全体のユーザーとアプリケーションが利用できます。
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 Example
図1：Treednプロバイダーの例
One overlay technology that TreeDN leverages is Automatic Multicast Tunneling (AMT) [RFC7450]. With AMT, end hosts on unicast-only networks (AMT Gateways) can dynamically build tunnels 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 typically sits on the receiving end host and initiates the tunnel at an AMT Relay. The AMT Relay is a tunnel server that typically sits at the border of the multicast network. AMT allows any end host on the Internet to receive multicast content regardless of whether their local provider supports multicast (aka, "off-net receivers"), which addresses the "All or Nothing" problem. Links and devices that do not support multicast are simply tunneled over -- they no longer present a barrier to the overall replication service for end users. Those networks that do deploy and support multicast, as well as the content providers that serve up multicast content, are able to enjoy the benefits of efficient replication and delivery. Further, these benefits can serve as incentives for operators who do not yet support multicast to enable it on their networks, which is a key benefit of incremental deployment described in Section 4.3 of [RFC9049]. Once the cost of carrying duplicated unicast tunnels is perceived by those operators to exceed the cost of deploying multicast, they are more likely to enable multicast on their networks. Thus, TreeDN effectively supports incremental deployment in a way that was not previously possible with traditional (non-overlay) multicast networking. Finally, AMT also addresses the "Chicken and Egg" problem, as all end hosts on the global Internet that have access to an AMT Relay are capable of becoming audience members.
レバレッジを講じる1つのオーバーレイテクノロジーは、自動マルチキャストトンネル（AMT）[RFC7450]です。AMTを使用すると、ユニキャストのみのネットワーク（AMTゲートウェイ）のエンドホストが、ネットワークのマルチキャスト対応部分（AMTリレー）のルーターにトンネルを動的に構築し、マルチキャストストリームを受信できます。AMTゲートウェイは、通常、受信エンドのホストに座って、AMTリレーでトンネルを開始する薄いソフトウェアクライアントです。AMTリレーは、通常、マルチキャストネットワークの境界にあるトンネルサーバーです。AMTでは、インターネット上のエンドホストが、地元のプロバイダーがマルチキャスト（別名、「オフネットレシーバー」）をサポートしているかどうかにかかわらず、マルチキャストコンテンツを受信することを許可しています。マルチキャストをサポートしていないリンクとデバイスは、単にトンネルに登録されています。エンドユーザー向けの全体的なレプリケーションサービスに対する障壁はなくなりました。マルチキャストを展開およびサポートするネットワーク、およびマルチキャストコンテンツを提供するコンテンツプロバイダーは、効率的な複製と配信の利点を享受できます。さらに、これらの利点は、[RFC9049]のセクション4.3で説明されている増分展開の重要な利点である、ネットワークでそれを有効にするためにマルチキャストをまだサポートしていないオペレーターのインセンティブとして機能します。重複したユニキャストトンネルを運ぶコストが、それらのオペレーターによってマルチキャストの展開コストを超えると認識されると、ネットワークでマルチキャストを有効にする可能性が高くなります。したがって、Treednは、従来の（非オーバーレイ）マルチキャストネットワーキングでは以前は不可能であった方法で、増分展開を効果的にサポートします。最後に、AMTは「鶏肉と卵」の問題にも対処します。AMTリレーにアクセスできるグローバルなインターネット上のすべてのエンドホストは、観客になることができます。
To support receiving on both native and non-native networks, receiving hosts can first attempt to join the traffic natively, and if no multicast traffic is received, they can fall back to AMT. This fallback mechanism can be handled by the application layer.
ネイティブネットワークと非ネイティブネットワークの両方で受信をサポートするために、受信ホストは最初にトラフィックにネイティブに参加しようとすることができ、マルチキャストトラフィックが受け取られない場合、AMTに戻ることができます。このフォールバックメカニズムは、アプリケーションレイヤーによって処理できます。
In addition to AMT, other overlay technologies like the Locator/ID Separation Protocol (LISP) [RFC9300] can be utilized to deliver content from multicast-enabled networks to end hosts that are separated by portions of the network (at the last/middle/first mile) that do not support multicast.
AMTに加えて、ロケーター/ID分離プロトコル（LISP）[RFC9300]などの他のオーバーレイテクノロジーを利用して、マルチキャスト対応ネットワークからコンテンツを配信して、ネットワークの部分で区切られたホストを終了することができます（最後/中央/最初のマイル）マルチキャストをサポートしていません。
Networks that support multicast provide the native on-net component of TreeDN. The primary requirement of the native on-net component is to support Source-Specific Multicast (SSM) [RFC4607]. PIM-SSM, which is merely a subset of PIM-SM, is the multicast routing protocol typically used in SSM. However, any multicast routing protocol capable of supporting SSM can be used in the TreeDN native on-net component, such as mLDP, Global Table Multicast (GTM) [RFC7716], BGP-based Multicast [BGP-MULTICAST], or even BGP Multicast VPN (BGP-MVPN) [RFC6513] for those operators who carry the global routing table in a Virtual Routing and Forwarding (VRF) table. Likewise, any data plane technology that supports SSM, including Bit Index Explicit Replication (BIER) [RFC8279] and Segment Routing (SR) Point-to-Multipoint (P2MP) [RFC9524], can be used.
マルチキャストをサポートするネットワークは、Treednのネイティブオンネットコンポーネントを提供します。ネイティブON-NETコンポーネントの主な要件は、ソース固有のマルチキャスト（SSM）[RFC4607]をサポートすることです。PIM-SMは、PIM-SMのサブセットにすぎないPIM-SSMは、SSMで通常使用されるマルチキャストルーティングプロトコルです。ただし、SSMをサポートできるマルチキャストルーティングプロトコルは、MLDP、Global Table Multicast（GTM）[RFC7716]、BGPベースのマルチキャスト[BGP-Multicast]、またはBGPマルチカスタントなどのTreednネイティブオンネットコンポーネントで使用できます。VPN（BGP-MVPN）[RFC6513]は、仮想ルーティングと転送（VRF）テーブルにグローバルルーティングテーブルを運ぶ演算子用。同様に、SSMをサポートするデータプレーンテクノロジーは、BITインデックス明示的複製（BIER）[RFC8279]やセグメントルーティング（SR）ポイントツーマルチポイント（P2MP）[RFC9524]を含むものです。
The key benefit of SSM as the native on-net component of TreeDN is that it radically simplifies the control plane needed to support replication in the network. This simplification comes by moving source discovery from the network layer to some sort of out-of-band mechanism, usually in the application layer. In 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. This allows the last-hop router to immediately join the multicast stream along the shortest-path tree (SPT) without the need for shared trees. This benefit addresses the "It's Too Complex" problem. By eliminating the need for network-based source discovery, most of the complexity of multicast is then eliminated, which reduces the cost of deploying and operating a multicast network. Further rationale for this SSM-only approach can be found in Any-Source Multicast (ASM) Deprecation [RFC8815].
TreednのネイティブOn-NetコンポーネントとしてのSSMの重要な利点は、ネットワークの複製をサポートするために必要なコントロールプレーンを根本的に簡素化することです。この単純化は、通常、アプリケーションレイヤーで、ネットワークレイヤーから何らかのバンド外のメカニズムにソースの発見を移動することによってもたらされます。SSMでは、受信者はIPv4用にインターネットグループ管理プロトコルバージョン3（IGMPV3）[RFC3376]またはIPv6にマルチキャストリスナーディスカバリーバージョン2（MLDV2）プロトコル[RFC3810]を使用して、マルチキャストストリームのソースとグループアドレスの両方を指定します。これにより、ラストホップルーターは、共有ツリーを必要とせずに、最短パスツリー（SPT）に沿ってマルチキャストストリームに直ちに参加できます。この利点は、「複雑すぎる」問題に対処します。ネットワークベースのソース発見の必要性を排除することにより、マルチキャストの複雑さのほとんどが排除され、マルチキャストネットワークの展開と操作のコストが削減されます。このSSMのみのアプローチのさらなる理論的根拠は、任意のソースマルチキャスト（ASM）廃止[RFC8815]にあります。
Content providers have traditionally used CDNs to distribute content that needs to be delivered to large audiences, essentially outsourcing the task of replication to CDN providers. Most CDNs utilize unicast delivery, as multicast is not an option due to its lack of general availability on the global Internet. TreeDN is a CDN architecture that leverages tree-based replication to more efficiently utilize network resources to deliver simultaneous multi-destination traffic. By leveraging overlay networking to address the "All or Nothing" and "Chicken and Egg" problems, and leveraging SSM to address the "It's Too Complex" problem, TreeDN avoids the practical issues that previously prevented multicast from being a viable option for CDN providers.
コンテンツプロバイダーは、伝統的にCDNを使用して、大規模な視聴者に配信する必要があるコンテンツを配布しており、本質的にレプリケーションのタスクをCDNプロバイダーにアウトソーシングしていました。マルチキャストはグローバルインターネットでの一般的な可用性がないためにオプションではないため、ほとんどのCDNはユニキャスト配信を利用しています。Treednは、ツリーベースの複製を活用して、ネットワークリソースをより効率的に利用して、同時マルチデスティングトラフィックを提供するCDNアーキテクチャです。オーバーレイネットワーキングを活用して「すべてか何もない」と「鶏と卵」の問題に対処し、SSMを活用して「複雑すぎる」問題に対処することにより、Treednは以前にマルチキャストがCDNプロバイダーにとって実行可能なオプションであることを妨げていた実際的な問題を回避します。。
TreeDN has several advantages over traditional unicast-based CDN approaches. First, the TreeDN functionality can be delivered entirely by the existing network infrastructure. Specifically, for operators with routers that support AMT natively, multicast traffic can be delivered directly to end users without the need for specialized CDN devices, which typically are servers that need to be racked, powered, cooled, and connected to ports on routers that otherwise could have been consumed by paying customers. In this way, SPs can offer new RaaS functionality to content providers at potentially zero additional cost in new equipment.
Treednには、従来のユニキャストベースのCDNアプローチよりもいくつかの利点があります。まず、Treedn機能は、既存のネットワークインフラストラクチャによって完全に提供できます。具体的には、AMTをネイティブにサポートするルーターを備えたオペレーターの場合、マルチキャストトラフィックは、特殊なCDNデバイスを必要とせずにエンドユーザーに直接配信できます。これは、通常、ラック、駆動、冷却、およびそれ以外の場合はポートのポートに接続する必要があるサーバーです。顧客を支払うことで消費される可能性があります。このようにして、SPSは、新しい機器の追加コストで潜在的にゼロの追加コストで、コンテンツプロバイダーに新しいRAAS機能を提供できます。
Additionally, TreeDN is an open architecture that leverages mature, IETF-specified, and widely implemented network protocols. TreeDN also requires far less coordination between the content provider and the CDN operator. That is, there are no storage requirements for the data, nor group-key management issues, since a TreeDN provider merely forwards packets. A TreeDN provider simply needs to have enough accounting data (e.g., traffic data, number of AMT tunnels, etc.) to properly bill customers for the service. By contrast, traditional unicast-based CDNs often incorporate proprietary, non-interoperable technologies and require significant coordination between the content provider and the CDN to handle such things as file storage, data protection, and key management.
さらに、Treednは、成熟、IETF指定、広く実装されたネットワークプロトコルを活用するオープンアーキテクチャです。Treednは、コンテンツプロバイダーとCDN演算子との間の調整がはるかに少ないことも必要です。つまり、Treednプロバイダーは単にパケットを転送するだけなので、データのストレージ要件もグループキー管理の問題もありません。Treednプロバイダーは、サービスのために顧客を適切に請求するために、十分な会計データ（トラフィックデータ、AMTトンネルの数など）を必要とするだけです。対照的に、従来のユニキャストベースのCDNには、多くの場合、独自の非挿入性テクノロジーが組み込まれており、ファイルストレージ、データ保護、主要な管理などのものを処理するために、コンテンツプロバイダーとCDNの間に重要な調整が必要です。
TreeDN introduces a deployment model that requires new considerations for transport-layer mechanisms that are frequently relied upon by traditional unicast-based CDNs. A discussion on these considerations and differences can be found in Section 9.
Treednは、従来のユニキャストベースのCDNによって頻繁に依存する輸送層メカニズムの新しい考慮事項を必要とする展開モデルを導入します。これらの考慮事項と違いに関する議論は、セクション9に記載されています。
TreeDN is an inherently decentralized architecture. This reduces the cost for content sourcing, as any host connected to a multicast-enabled network or on a source-capable overlay can send out a single data stream that can be reached by an arbitrarily large audience. By effectively reducing the marginal cost of reaching each additional audience member to zero, from the perspective of the source, TreeDN democratizes content sourcing on the Internet.
Treednは本質的に分散化されたアーキテクチャです。これにより、マルチキャスト対応ネットワークに接続されているホストまたはソース対応オーバーレイに接続されているホストは、任意の大手オーディエンスが到達できる単一のデータストリームを送信できるため、コンテンツソーシングのコストが削減されます。情報源の観点から、各追加の聴衆メンバーに到達するという限界費用をゼロに効果的に削減することにより、Treednはインターネット上のコンテンツを民主化します。
The focus of this document is on the network-layer components that comprise the TreeDN architecture. This section introduces some of the key transport-layer-related differences between TreeDN and traditional unicast-based CDNs that should be taken into consideration when deploying TreeDN-based services. In many cases, these issues are more related to differences between TCP and UDP than differences between unicast and multicast; thus, UDP-based solutions can be leveraged to address most gaps. The aim of this section is to point to some of the existing work to address these gaps, as well as to suggest further work that could be undertaken within the IETF. Further details of these transport-layer mechanisms are beyond the scope of this document.
このドキュメントの焦点は、Treednアーキテクチャを構成するネットワーク層コンポーネントにあります。このセクションでは、TreednとTreednベースのサービスを展開する際に考慮すべき従来のユニキャストベースのCDNとの間の主要な輸送層関連の違いのいくつかを紹介します。多くの場合、これらの問題は、ユニキャストとマルチキャストの違いよりもTCPとUDPの違いに関連しています。したがって、UDPベースのソリューションを活用して、ほとんどのギャップに対処できます。このセクションの目的は、これらのギャップに対処するために既存の作業の一部を指摘し、IETF内で実施できるさらなる作業を提案することです。これらの輸送層メカニズムの詳細は、このドキュメントの範囲を超えています。
Since SSM inherently implies unidirectional traffic flows from one to many, mechanisms that rely on bidirectional communication between receivers and the content provider (such as bespoke advertising, telemetry data from receivers detailing end-user experience, distribution of decryption keys, switching to higher or lower bandwidth streams, etc.) are not well suited to SSM delivery. As such, separate unicast streams between receivers and content providers may be used for this type of "out-of-band" function while SSM is used to deliver 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.
SSMは本質的に一方向のトラフィックが1から多くのものに流れることを意味するため、レシーバーとコンテンツプロバイダー間の双方向通信に依存するメカニズム（オーダーメイドの広告、エンドユーザーエクスペリエンスの詳細、脱凍結キーの分布を詳述したレシーバーからのテレメトリーデータ、より高いまたは低いまたは低いか低いか低いか帯域幅のストリームなど）は、SSM配信にはあまり適していません。そのため、レシーバーとコンテンツプロバイダーの間の個別のユニキャストストリームをこのタイプの「バンド外」関数に使用することができますが、SSMは実際の関心のあるコンテンツを提供するために使用できます。これらの「帯域外」ユニキャストストリームは、大量視聴者のユニキャスト配信に今日使用されている同じ輻輳制御と認証メカニズムを使用する必要があります。一般的に言えば、このハイブリッドユニキャストマルチキャストアプローチは、アプリケーションレイヤーによって最適に処理され、詳細はこのドキュメントの範囲を超えています。
Traditional unicast-based CDNs frequently rely on HTTPS over TCP transport; thus, they are able to leverage the granularity of TCP-based mechanisms for reliability, congestion control, and adaptive bitrate streaming. However, this granularity comes at a cost of sending a separate data stream to each viewer. Multicast transmissions usually employ UDP, which inherently lacks many of the aforementioned benefits of TCP but can scale much better for mass audiences of simultaneous viewers. Forward Error Correction (FEC) is a mechanism that has demonstrated full recovery for up to 5% packet loss and interruptions up to 400 ms for multicast data streams in [EUMETSAT-TERRESTRIAL]. NACK-Oriented Reliable Multicast (NORM) [RFC5740] leverages FEC-based repair and other Reliable Multicast Transport (RMT) building blocks to provide end-to-end reliable transport over multicast networks.
従来のユニキャストベースのCDNは、TCP輸送を介してHTTPに依存することがよくあります。したがって、彼らは、信頼性、輻輳制御、および適応的なビットレートストリーミングのために、TCPベースのメカニズムの粒度を活用することができます。ただし、この粒度には、各視聴者に個別のデータストリームを送信するコストがかかります。マルチキャスト送信は通常、UDPを採用しています。これは、TCPの前述の利点の多くを本質的に欠いていますが、同時視聴者の大衆オーディエンスにとってはるかに優れた尺度を拡大することができます。フォワードエラー補正（FEC）は、[eumetsat-terrestrial]のマルチキャストデータストリームの最大5％のパケット損失と最大400ミリ秒の中断の完全な回復を実証したメカニズムです。NACK指向の信頼できるマルチキャスト（NORM）[RFC5740]は、FECベースの修理およびその他の信頼できるマルチキャストトランスポート（RMT）ビルディングブロックを活用して、マルチキャストネットワークをエンドツーエンドの信頼できる輸送を提供します。
QUIC [RFC9000] is another popular transport used by traditional unicast-based CDNs. While QUIC does use UDP, it does not currently support multicast. Multicast extensions to QUIC have been proposed in [QUIC-Multicast].
QUIC [RFC9000]は、従来のユニキャストベースのCDNで使用されるもう1つの一般的なトランスポートです。QUICはUDPを使用していますが、現在マルチキャストをサポートしていません。QUICへのマルチキャスト拡張は[Quic-Multicast]で提案されています。
Section 4.1 of [RFC8085] describes how a sender can distribute data across multiple multicast source-group channels so that each receiver can join the most appropriate channels for its own reception rate capability, thus providing adaptive bitrate capabilities for multicast streams. [DVB-MABR] and [MAUD] extensively describe an architecture that enables reliability and dynamic bitrate adaptation.
[RFC8085]のセクション4.1では、送信者が複数のマルチキャストソースグループチャネルにデータを配布する方法について説明し、各レシーバーが独自の受信レート機能に最も適切なチャネルに参加し、マルチキャストストリームに適応的なビットレート機能を提供します。[DVB-Mabr]および[Maud]は、信頼性と動的なビットレートの適応を可能にするアーキテクチャを広範囲に説明しています。
TreeDN deployments MUST follow the congestion control guidelines described in Section 4.1.4.2 of [RFC7450]. A multicast application that is 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. Section 3.1 of [RFC8777] describes a set of procedures for optimal relay selection.
Treednの展開は、[RFC7450]のセクション4.1.4.2で説明されている輻輳制御ガイドラインに従う必要があります。Treedn Deploymentsを介して配布されているマルチキャストアプリケーションは、[RFC8085]のセクション4.1で説明されているように、データ送信の輻輳制御を実装する必要があります。AMTゲートウェイは、トポロジカルに最も近いAMTリレーを使用する必要があります。[RFC8777]のセクション3.1では、最適なリレー選択のための一連の手順について説明します。
A multicast sender typically has little to no control or visibility about which end hosts may receive the data stream. Encryption can be used to ensure that only authorized receivers are able to access meaningful data. That is, even if unauthorized end hosts (e.g., non-paying end hosts) receive the data stream, without decryption keys, the data is useless. [GKM-IKEv2] describes an extension to the Internet Key Exchange Protocol Version 2 (IKEv2) for the purpose of group key management. [DVB-MABR] and [MAUD] extensively describe an architecture that includes encryption of multicast streams.
マルチキャスト送信者は通常、どのエンドホストがデータストリームを受信できるかについて、ほとんどまたはまったく制御または可視性を持っていません。暗号化を使用して、認定受信機のみが意味のあるデータにアクセスできるようにすることができます。つまり、不正なエンドホスト（たとえば、非支払いエンドホスト）が復号化キーなしでデータストリームを受け取ったとしても、データは役に立たない。[GKM-kikev2]は、グループキー管理を目的としたインターネットキーエクスチェンジプロトコルバージョン2（IKEV2）の拡張を説明しています。[DVB-Mabr]および[Maud]は、マルチキャストストリームの暗号化を含むアーキテクチャを広く説明しています。
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 purposes such as 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 and to end users on unicast-only networks via a global deployment of AMT relays. Details of the EUMETCast Terrestrial service over the GEANT TreeDN network are described in [EUMETCast-TERRESTRIAL-AMT]. Additional details on how this deployment uses encryption, authorization, reliability, and unicast feedback channels for end-to-end file delivery monitoring can be found in [EUMETSAT-TERRESTRIAL].
Eumetcast Terrestrialは、気象衛星データをエンドユーザーに提供する気象衛星データを、気候の運用監視や世界の気候変動の検出などの目的でエンドユーザーに提供する欧州衛生機関（EumetSAT）からのサービスです。EumetCast Terrestrialは、Geantネットワークに接続します。これにより、Treednサービスは、このリアルタイムデータをマルチキャスト対応ネットワークのエンドユーザーにネイティブに配信し、AMTリレーのグローバルな展開を介してユニキャストのみのネットワークでエンドユーザーにネイティブに配信します。Geant Treednネットワークを介したEumetCastの地上サービスの詳細については、[eumetcast-terrestrial-amt]で説明されています。この展開が暗号化、承認、信頼性、ユニキャストフィードバックチャネルを使用する方法に関する追加の詳細は、[eumetsat-terrestrial]で見つけることができます。
The Multicast Menu [Multicast-Menu] is a web-based portal that can list and launch active multicast streams that are available on a global TreeDN network of various research and education networks. Details of this TreeDN network, as well as the Multicast Menu, are described in [Offnet-Sourcing-Multicast-Menu].
マルチキャストメニュー[Multicast-Menu]は、さまざまな研究および教育ネットワークのグローバルなTreednネットワークで利用できるアクティブなマルチキャストストリームをリストおよび起動できるWebベースのポータルです。このTreednネットワークの詳細とマルチキャストメニューは、[Offnet-Sourcing-Multicast-Menu]で説明されています。
The RARE network is a global testbed interconnecting several National Research and Education Networks (NRENs) via routers running BIER. AMT relays are deployed to deliver multicast traffic from sources on the RARE network to receivers on unicast-only networks across the Internet. Details of the RARE network are described in [BIER-AMT-Deployment].
レアネットワークは、バイアーを実行するルーターを介していくつかの国家研究および教育ネットワーク（NRENS）を相互接続するグローバルなテストベッドです。AMTリレーは展開され、レアネットワーク上のソースからインターネット上のユニキャストのみのネットワーク上のレシーバーにマルチキャストトラフィックを配信します。レアネットワークの詳細については、[Bier-Amt Deployment]で説明されています。
TreeDN is essentially the synthesis of SSM plus overlay networking technologies like AMT. As such, any existing tools to manage, operate, and troubleshoot a PIM-SSM domain and an AMT deployment can be used to manage a TreeDN deployment. Protocol error handling for PIM-SSM can be found in [RFC4607] and in Section 4.8 of [RFC7761]; for AMT, it can be found in [RFC7450].
Treednは、本質的にSSMとAMTのようなオーバーレイネットワークテクノロジーの合成です。そのため、PIM-SSMドメインを管理、操作、およびトラブルシューティングするための既存のツールとAMT展開を使用して、Treedn展開を管理できます。PIM-SSMのプロトコルエラー処理は、[RFC4607]および[RFC7761]のセクション4.8に記載されています。AMTの場合、[RFC7450]にあります。
One potential operational benefit of a multicast-based approach like TreeDN over a traditional, unicast-based CDN is the visibility that multicast state provides in the routing infrastructure. That is, multicast routers maintain a forwarding cache of multicast flows that usually includes the source address, group address, incoming/outgoing interfaces, and forwarding rate. Generally speaking, such flow state information is not typically available in core networks for unicast, so additional tools outside the routing infrastructure are usually required for monitoring CDN performance and troubleshooting issues like packet loss location. Of course, this benefit comes at a cost of additional state being maintained in the routers for multicast.
従来のユニキャストベースのCDNに対するTreednのようなマルチキャストベースのアプローチの潜在的な運用上の利点の1つは、マルチキャスト状態がルーティングインフラストラクチャで提供する可視性です。つまり、マルチキャストルーターは、通常、ソースアドレス、グループアドレス、着信/発信インターフェイス、転送速度を含むマルチキャストフローの転送キャッシュを維持します。一般的に言えば、このようなフロー状態情報は通常、ユニキャスト用のコアネットワークでは利用できないため、通常、ルーティングインフラストラクチャ以外の追加ツールがCDNパフォーマンスを監視し、パケット損失の場所などの問題のトラブルシューティングに必要です。もちろん、この利点は、マルチキャストのルーターで追加の状態が維持されるというコストでもたらされます。
Additionally, since multicast leverages Reverse Path Forwarding (RPF), the source of the content can potentially have a greater influence over the path taken through the network from source to native receivers/AMT relays. That is, the BGP peer advertising the reachability of the source's subnet can do so in ways where a particular path through the network is preferred for multicast distribution; these methods are not as easy to accomplish with traditional, destination-based unicast routing.
さらに、マルチキャストレバレッジリバースパス転送（RPF）であるため、コンテンツのソースは、ソースからネイティブレシーバー/AMTリレーにネットワークを介したパスに大きな影響を与える可能性があります。つまり、ソースのサブネットの到達可能性を宣伝するBGPピアは、ネットワークを通る特定のパスがマルチキャスト配信に好まれる方法でそうすることができます。これらの方法は、従来の目的地ベースのユニキャストルーティングで達成するのは簡単ではありません。
Since TreeDN is essentially the synthesis of SSM plus overlay networking technologies like AMT, the TreeDN architecture introduces no new security threats that are not already documented in SSM and the overlay technologies that comprise it. In particular, Section 6 of [RFC7450] candidly notes that AMT, like UDP, IGMP, and MLD, provides no mechanisms for ensuring message delivery or integrity, nor does it provide confidentiality, since sources/groups joined through IGMP/MLD could be associated with the particular content being requested.
Treednは本質的にSSMとAMTのようなオーバーレイネットワーキングテクノロジーの統合であるため、Treednアーキテクチャは、SSMおよびそれを構成するオーバーレイテクノロジーでまだ文書化されていない新しいセキュリティの脅威を導入しません。特に、[RFC7450]のセクション6は、UDP、IGMP、MLDなどのAMTがメッセージの配信や完全性を確保するためのメカニズムを提供しないことも、IGMP/MLDを介して結合されたソース/グループに関連する可能性があるため、機密性も提供しないことを率直に指摘しています。特定のコンテンツが要求されています。
[RFC4609] and [RFC8815] describe the additional security benefits of using SSM instead of ASM.
[RFC4609]および[RFC8815]は、ASMの代わりにSSMを使用することの追加のセキュリティ利点を説明しています。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[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>.
[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>.
With inspiration from (and apologies to) Radia Perlman [Algorhyme] and Joyce Kilmer [Trees], the following poem is not intended to provide any normative or informative technical value on TreeDN beyond (mild) amusement for the reader who made it this far in the document:
Radia Perlman [Algorhyme]とJoyce Kilmer [Trees]からのインスピレーションを得て、次の詩は、これまでにそれを作った読者に（軽度の）娯楽を超えて、Treednの規範的または有益な技術的価値を提供することを意図していません。ドキュメント：
I think that I shall never see A CDN more lovely than a tree.
私は木よりも素敵なCDNを決して見ないと思います。
A tree whose crucial property Is efficient mass-audience delivery.
重要な特性が効率的な大量監査配信である木。
Using SSM for simplified operation Of native branches that eliminate duplication.
SSMを使用して、重複を排除するネイティブブランチの簡素化された動作。
A tree extended by AMT, Enabling unicast-only receivers full delivery.
AMTによって拡張されたツリー、ユニキャストのみのレシーバーが完全な配達を可能にします。
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.
私のような人々によってCDNが構築されますが、エンドユーザーのみがツリーを必要とするのに十分な需要を生成できます。
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.
ピート・モラスカ、ウィリアム・チャン、ローレン・デルウィッチ、ナタリー・ランズバーグ、ウェイン・ブラセム、ジェイク・ホランド、アンドリュー・ウィロ、ケイシー・ラッセル、ジャナス・ヴァルマーカーン、CSABAメイトなど、インターネット上の最初のTreednネットワークの構築と運用に貢献してくれた人々に感謝します。フレデリック・ルイ、マックス・フランケ、トドル・モスコフ、エリック・ヘルツ、ブラッドリー・カオ、ケイティ・メリル、カレル・ヘンドリチ、ハルナ・オセニ、イザベル・シオン。Treedn Architectureを説明するこの文書の執筆は、Dino FarinacciとMike McBrideとの会話に触発されました。ジェフ・ハース、ヴィノド・クマール、ロン・ボニャ、ジェフリー・チャン、エリック・ヴィンチにも、彼らの思慮深いレビューと提案、彼の詳細な羊飼いのレビューのためのクリス・レモンズ、マグナス・ウェスターランド、リース・エンガード、ジャーロス・シャンワルデー、カルロス・ピニャタロ、Kline、Gunter Van de Velde、Warren Kumari、Zaheduzzaman Sarkerの最後のコールレビュー。
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