[要約] RFC 8313は、異なるドメイン間のピアリングポイントでのマルチキャストの使用に関するガイドラインです。その目的は、異なるドメイン間でのマルチキャストトラフィックの効率的な配信を実現することです。
Internet Engineering Task Force (IETF) P. Tarapore, Ed.
Request for Comments: 8313 R. Sayko
BCP: 213 AT&T
Category: Best Current Practice G. Shepherd
ISSN: 2070-1721 Cisco
T. Eckert, Ed.
Huawei
R. Krishnan
SupportVectors
January 2018
Use of Multicast across Inter-domain Peering Points
ドメイン間ピアリングポイント間のマルチキャストの使用
Abstract
概要
This document examines the use of Source-Specific Multicast (SSM) across inter-domain peering points for a specified set of deployment scenarios. The objectives are to (1) describe the setup process for multicast-based delivery across administrative domains for these scenarios and (2) document supporting functionality to enable this process.
このドキュメントでは、指定された一連の展開シナリオについて、ドメイン間ピアリングポイント全体でのSource-Specific Multicast（SSM）の使用について検討します。目的は、（1）これらのシナリオの管理ドメイン全体でのマルチキャストベースの配信のセットアッププロセスを説明し、（2）このプロセスを有効にするサポート機能を文書化することです。
Status of This Memo
本文書の状態
This memo documents an Internet Best Current Practice.
このメモは、インターネットの現在のベストプラクティスを文書化したものです。
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). Further information on BCPs is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 BCPの詳細については、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/rfc8313.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8313で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
2. Overview of Inter-domain Multicast Application Transport ........6
3. Inter-domain Peering Point Requirements for Multicast ...........7
3.1. Native Multicast ...........................................8
3.2. Peering Point Enabled with GRE Tunnel .....................10
3.3. Peering Point Enabled with AMT - Both Domains
Multicast Enabled .........................................12
3.4. Peering Point Enabled with AMT - AD-2 Not
Multicast Enabled .........................................14
3.5. AD-2 Not Multicast Enabled - Multiple AMT Tunnels
through AD-2 ..............................................16
4. Functional Guidelines ..........................................18
4.1. Network Interconnection Transport Guidelines ..............18
4.1.1. Bandwidth Management ...............................19
4.2. Routing Aspects and Related Guidelines ....................20
4.2.1. Native Multicast Routing Aspects ...................21
4.2.2. GRE Tunnel over Interconnecting Peering Point ......22
4.2.3. Routing Aspects with AMT Tunnels ...................22
4.2.4. Public Peering Routing Aspects .....................24
4.3. Back-Office Functions - Provisioning and Logging
Guidelines ................................................26
4.3.1. Provisioning Guidelines ............................26
4.3.2. Inter-domain Authentication Guidelines .............28
4.3.3. Log-Management Guidelines ..........................28
4.4. Operations - Service Performance and Monitoring
Guidelines ................................................30
4.5. Client Reliability Models / Service Assurance Guidelines ..32
4.6. Application Accounting Guidelines .........................32
5. Troubleshooting and Diagnostics ................................32
6. Security Considerations ........................................33
6.1. DoS Attacks (against State and Bandwidth) .................33
6.2. Content Security ..........................................35
6.3. Peering Encryption ........................................37
6.4. Operational Aspects .......................................37
7. Privacy Considerations .........................................39
8. IANA Considerations ............................................40
9. References .....................................................40
9.1. Normative References ......................................40
9.2. Informative References ....................................42
Acknowledgments ...................................................43
Authors' Addresses ................................................44
Content and data from several types of applications (e.g., live video streaming, software downloads) are well suited for delivery via multicast means. The use of multicast for delivering such content or other data offers significant savings in terms of utilization of resources in any given administrative domain. End User (EU) demand for such content or other data is growing. Often, this requires transporting the content or other data across administrative domains via inter-domain peering points.
複数のタイプのアプリケーション（ライブビデオストリーミング、ソフトウェアダウンロードなど）のコンテンツとデータは、マルチキャスト手段による配信に適しています。このようなコンテンツやその他のデータを配信するためにマルチキャストを使用すると、特定の管理ドメインでのリソースの使用率を大幅に節約できます。このようなコンテンツやその他のデータに対するエンドユーザー（EU）の需要は高まっています。多くの場合、これにはドメイン間ピアリングポイントを介して管理ドメイン間でコンテンツやその他のデータを転送する必要があります。
The objectives of this document are twofold:
このドキュメントの目的は2つあります。
o Describe the technical process and establish guidelines for setting up multicast-based delivery of application content or other data across inter-domain peering points via a set of use cases (where "Use Case 3.1" corresponds to Section 3.1, "Use Case 3.2" corresponds to Section 3.2, etc.).
o 技術的なプロセスを説明し、一連のユースケースを介してドメイン間ピアリングポイント全体でアプリケーションコンテンツまたはその他のデータのマルチキャストベースの配信を設定するためのガイドラインを確立します（「ユースケース3.1」はセクション3.1、「ユースケース3.2」は対応します）セクション3.2など）。
o Catalog all required exchanges of information between the administrative domains to support multicast-based delivery. This enables operators to initiate necessary processes to support inter-domain peering with multicast.
o マルチキャストベースの配信をサポートするために、管理ドメイン間で必要なすべての情報交換をカタログ化します。これにより、オペレーターは必要なプロセスを開始して、マルチキャストによるドメイン間ピアリングをサポートできます。
The scope and assumptions for this document are as follows:
このドキュメントの範囲と前提条件は次のとおりです。
o Administrative Domain 1 (AD-1) sources content to one or more EUs in one or more Administrative Domain 2 (AD-2) entities. AD-1 and AD-2 want to use IP multicast to allow support for large and growing EU populations, with a minimum amount of duplicated traffic to send across network links.
o 管理ドメイン1（AD-1）は、1つ以上の管理ドメイン2（AD-2）エンティティの1つ以上のEUにコンテンツを提供します。 AD-1とAD-2は、IPマルチキャストを使用して、ネットワークリンクを介して送信する重複トラフィックの最小量で、大規模で増大するEU人口のサポートを可能にしたいと考えています。
* This document does not detail the case where EUs are originating content. To support that additional service, it is recommended that some method (outside the scope of this document) be used by which the content from EUs is transmitted to the application in AD-1 and AD-1 can send out the traffic as IP multicast. From that point on, the descriptions in this document apply, except that they are not complete because they do not cover the transport or operational aspects of the leg from the EU to AD-1.
* このドキュメントでは、EUがコンテンツを発信しているケースについては詳しく説明していません。その追加サービスをサポートするために、EUからのコンテンツがAD-1のアプリケーションに送信され、AD-1がトラフィックをIPマルチキャストとして送信できる何らかの方法（このドキュメントの範囲外）を使用することをお勧めします。その時点から、このドキュメントの説明が適用されます。ただし、EUからAD-1への脚の輸送または運用の側面をカバーしていないため、完全ではありません。
* This document does not detail the case where AD-1 and AD-2 are not directly connected to each other and are instead connected via one or more other ADs (as opposed to a peering point) that serve as transit providers. The cases described in this document where tunnels are used between AD-1 and AD-2 can be applied to such scenarios, but SLA ("Service Level Agreement") control, for example, would be different. Additional issues will likely exist as well in such scenarios. This topic is left for further study.
*このドキュメントでは、AD-1とAD-2が直接接続されておらず、代わりにトランジットプロバイダーとして機能する1つ以上の他のAD（ピアリングポイントではなく）を介して接続されているケースについては詳しく説明していません。このドキュメントで説明されているAD-1とAD-2の間でトンネルが使用されるケースは、このようなシナリオに適用できますが、たとえば、SLA（「サービスレベルアグリーメント」）の制御は異なります。このようなシナリオでも、追加の問題が発生する可能性があります。このトピックは、さらに調査するために残されています。
o For the purposes of this document, the term "peering point" refers to a network connection ("link") between two administrative network domains over which traffic is exchanged between them. This is also referred to as a Network-to-Network Interface (NNI). Unless otherwise noted, it is assumed that the peering point is a private peering point, where the network connection is a physically or virtually isolated network connection solely between AD-1 and AD-2. The other case is that of a broadcast peering point, which is a common option in public Internet Exchange Points (IXPs). See Section 4.2.4 for more details.
o このドキュメントでは、「ピアリングポイント」という用語は、2つの管理ネットワークドメイン間のトラフィックが交換される2つの管理ネットワークドメイン間のネットワーク接続（「リンク」）を指します。これは、ネットワーク間インターフェース（NNI）とも呼ばれます。特に明記しない限り、ピアリングポイントはプライベートピアリングポイントであり、ネットワーク接続はAD-1とAD-2の間の物理的または仮想的に分離されたネットワーク接続であると想定されます。もう1つのケースは、ブロードキャストピアリングポイントの場合です。これは、パブリックインターネットエクスチェンジポイント（IXP）の一般的なオプションです。詳細については、セクション4.2.4を参照してください。
o AD-1 is enabled with native multicast. A peering point exists between AD-1 and AD-2.
o AD-1はネイティブマルチキャストで有効になります。 AD-1とAD-2の間にピアリングポイントが存在します。
o It is understood that several protocols are available for this purpose, including Protocol-Independent Multicast - Sparse Mode (PIM-SM) and Protocol-Independent Multicast - Source-Specific Multicast (PIM-SSM) [RFC7761], the Internet Group Management Protocol (IGMP) [RFC3376], and Multicast Listener Discovery (MLD) [RFC3810].
o プロトコル非依存マルチキャスト-スパースモード（PIM-SM）およびプロトコル非依存マルチキャスト-ソース固有マルチキャスト（PIM-SSM）[RFC7761]、インターネットグループ管理プロトコル（ IGMP）[RFC3376]、およびマルチキャストリスナーディスカバリ（MLD）[RFC3810]。
o As described in Section 2, the source IP address of the (so-called "(S,G)") multicast stream in the originating AD (AD-1) is known. Under this condition, using PIM-SSM is beneficial, as it allows the receiver's upstream router to send a join message directly to the source without the need to invoke an intermediate Rendezvous Point (RP). The use of SSM also presents an improved threat mitigation profile against attack, as described in [RFC4609]. Hence, in the case of inter-domain peering, it is recommended that only SSM protocols be used; the setup of inter-domain peering for ASM (Any-Source Multicast) is out of scope for this document.
o セクション2で説明したように、元のAD（AD-1）内の（いわゆる「（S、G）」）マルチキャストストリームのソースIPアドレスは既知です。この状況では、PIM-SSMを使用すると、中間Rendezvous Point（RP）を呼び出さなくても、受信者の上流ルーターが参加メッセージをソースに直接送信できるため、有益です。 [RFC4609]で説明されているように、SSMを使用すると、攻撃に対する脅威軽減プロファイルが改善されます。したがって、ドメイン間ピアリングの場合は、SSMプロトコルのみを使用することをお勧めします。 ASM（Any-Source Multicast）のドメイン間ピアリングの設定は、このドキュメントの範囲外です。
o The rest of this document assumes that PIM-SSM and BGP are used across the peering point, plus Automatic Multicast Tunneling (AMT) [RFC7450] and/or Generic Routing Encapsulation (GRE), according to the scenario in question. The use of other protocols is beyond the scope of this document.
o このドキュメントの残りの部分では、問題のシナリオに従って、ピアリングポイント全体でPIM-SSMおよびBGPが使用され、さらに自動マルチキャストトンネリング（AMT）[RFC7450]および/またはGeneric Routing Encapsulation（GRE）が使用されることを前提としています。他のプロトコルの使用は、このドキュメントの範囲を超えています。
o AMT is set up at the peering point if either the peering point or AD-2 is not multicast enabled. It is assumed that an AMT relay will be available to a client for multicast delivery. The selection of an optimal AMT relay by a client is out of scope for this document. Note that using AMT is necessary only when native multicast is unavailable in the peering point (Use Case 3.3) or in the downstream administrative domain (Use Cases 3.4 and 3.5).
oピアリングポイントまたはAD-2のいずれかでマルチキャストが有効になっていない場合、AMTはピアリングポイントでセットアップされます。 AMTリレーは、マルチキャスト配信のためにクライアントで使用できると想定されています。クライアントによる最適なAMTリレーの選択は、このドキュメントの範囲外です。 AMTを使用する必要があるのは、ピアリングポイント（ユースケース3.3）またはダウンストリーム管理ドメイン（ユースケース3.4および3.5）でネイティブマルチキャストが利用できない場合のみです。
o It is assumed that the collection of billing data is done at the application level and is not considered to be a networking issue. The settlements process for EU billing and/or inter-provider billing is out of scope for this document.
o 課金データの収集はアプリケーションレベルで行われ、ネットワークの問題とは見なされないことを前提としています。 EUの請求および/またはプロバイダー間請求の決済プロセスは、このドキュメントの範囲外です。
o Inter-domain network connectivity troubleshooting is only considered within the context of a cooperative process between the two domains.
o ドメイン間ネットワーク接続のトラブルシューティングは、2つのドメイン間の協調プロセスのコンテキスト内でのみ考慮されます。
This document also attempts to identify ways by which the peering process can be improved. Development of new methods for improvement is beyond the scope of this document.
このドキュメントでは、ピアリングプロセスを改善する方法を特定することも試みています。改善のための新しい方法の開発は、このドキュメントの範囲を超えています。
A multicast-based application delivery scenario is as follows:
マルチキャストベースのアプリケーション配信シナリオは次のとおりです。
o Two independent administrative domains are interconnected via a peering point.
o 2つの独立した管理ドメインは、ピアリングポイントを介して相互接続されます。
o The peering point is either multicast enabled (end-to-end native multicast across the two domains) or connected by one of two possible tunnel types:
o ピアリングポイントは、マルチキャスト対応（2つのドメイン間でのエンドツーエンドのネイティブマルチキャスト）であるか、または次の2つのトンネルタイプのいずれかで接続されています。
* A GRE tunnel [RFC2784] allowing multicast tunneling across the peering point, or
* ピアリングポイント全体でマルチキャストトンネリングを許可するGREトンネル[RFC2784]、または
* AMT [RFC7450].
* AMT [RFC7450]。
o A service provider controls one or more application sources in AD-1 that will send multicast IP packets via one or more (S,G)s (multicast traffic flows; see Section 4.2.1 if you are unfamiliar with IP multicast). It is assumed that the service being provided is suitable for delivery via multicast (e.g., live video streaming of popular events, software downloads to many devices) and that the packet streams will be carried by a suitable multicast transport protocol.
o サービスプロバイダーは、1つ以上の（S、G）を介してマルチキャストIPパケットを送信するAD-1の1つ以上のアプリケーションソースを制御します（マルチキャストトラフィックフロー。IPマルチキャストに慣れていない場合は、セクション4.2.1を参照してください）。提供されているサービスは、マルチキャスト（たとえば、人気のイベントのライブビデオストリーミング、多くのデバイスへのソフトウェアダウンロード）による配信に適しており、パケットストリームは適切なマルチキャストトランスポートプロトコルによって伝送されると想定されています。
o An EU controls a device connected to AD-2, which runs an application client compatible with the service provider's application source.
o EUは、サービスプロバイダーのアプリケーションソースと互換性のあるアプリケーションクライアントを実行するAD-2に接続されたデバイスを制御します。
o The application client joins appropriate (S,G)s in order to receive the data necessary to provide the service to the EU. The mechanisms by which the application client learns the appropriate (S,G)s are an implementation detail of the application and are out of scope for this document.
o アプリケーションクライアントは、サービスをEUに提供するために必要なデータを受信するために、適切な（S、G）に参加します。アプリケーションクライアントが適切な（S、G）を学習するメカニズムは、アプリケーションの実装の詳細であり、このドキュメントの範囲外です。
The assumption here is that AD-1 has ultimate responsibility for delivering the multicast-based service on behalf of the content source(s). All relevant interactions between the two domains described in this document are based on this assumption.
ここでの想定は、AD-1がコンテンツソースに代わってマルチキャストベースのサービスを配信する最終的な責任を負うことです。このドキュメントで説明されている2つのドメイン間のすべての関連する相互作用は、この仮定に基づいています。
Note that AD-2 may be an independent network domain (e.g., a Tier 1 network operator domain). Alternately, AD-2 could also be an enterprise network domain operated by a single customer of AD-1. The peering point architecture and requirements may have some unique aspects associated with enterprise networks; see Section 3.
AD-2は独立したネットワークドメイン（Tier 1ネットワークオペレータードメインなど）である場合があります。または、AD-2は、AD-1の単一の顧客が運営するエンタープライズネットワークドメインにすることもできます。ピアリングポイントのアーキテクチャと要件には、エンタープライズネットワークに関連する独自の側面がいくつかある場合があります。セクション3を参照してください。
The use cases describing various architectural configurations for multicast distribution, along with associated requirements, are described in Section 3. Section 4 contains a comprehensive list of pertinent information that needs to be exchanged between the two domains in order to support functions to enable application transport.
マルチキャスト配信のさまざまなアーキテクチャ構成を説明するユースケースと関連する要件については、セクション3で説明します。セクション4には、アプリケーション転送を可能にする機能をサポートするために2つのドメイン間で交換する必要がある関連情報の包括的なリストが含まれています。
The transport of applications using multicast requires that the inter-domain peering point be enabled to support such a process. This section presents five use cases for consideration.
マルチキャストを使用してアプリケーションを転送するには、ドメイン間ピアリングポイントがそのようなプロセスをサポートできるようにする必要があります。このセクションでは、考慮すべき5つの使用例を示します。
This use case involves end-to-end native multicast between the two administrative domains, and the peering point is also native multicast enabled. See Figure 1.
この使用例には、2つの管理ドメイン間のエンドツーエンドのネイティブマルチキャストが含まれ、ピアリングポイントでもネイティブマルチキャストが有効になっています。図1を参照してください。
------------------- -------------------
/ AD-1 \ / AD-2 \
/ (Multicast Enabled) \ / (Multicast Enabled) \
/ \ / \
| +----+ | | |
| | | +------+ | | +------+ | +----+
| | AS |------>| BR |-|---------|->| BR |-------------|-->| EU |
| | | +------+ | I1 | +------+ |I2 +----+
\ +----+ / \ /
\ / \ /
\ / \ /
------------------- -------------------
AD = Administrative Domain (independent autonomous system) AS = multicast (e.g., content) Application Source BR = Border Router I1 = AD-1 and AD-2 multicast interconnection (e.g., MP-BGP) I2 = AD-2 and EU multicast connection
AD =管理ドメイン（独立した自律システム）AS =マルチキャスト（コンテンツなど）アプリケーションソースBR =ボーダールータI1 = AD-1およびAD-2マルチキャスト相互接続（MP-BGPなど）I2 = AD-2およびEUマルチキャスト接続
Figure 1: Content Distribution via End-to-End Native Multicast
図1：エンドツーエンドのネイティブマルチキャストによるコンテンツ配信
Advantages of this configuration:
この構成の利点：
o Most efficient use of bandwidth in both domains.
o 両方のドメインで帯域幅を最も効率的に使用します。
o Fewer devices in the path traversed by the multicast stream when compared to an AMT-enabled peering point.
o AMT対応のピアリングポイントと比較すると、マルチキャストストリームが通過するパス内のデバイスが少なくなります。
From the perspective of AD-1, the one disadvantage associated with native multicast to AD-2 instead of individual unicast to every EU in AD-2 is that it does not have the ability to count the number of EUs as well as the transmitted bytes delivered to them. This information is relevant from the perspective of customer billing and operational logs. It is assumed that such data will be collected by the application layer. The application-layer mechanisms for generating this information need to be robust enough so that all pertinent requirements for the source provider and the AD operator are satisfactorily met. The specifics of these methods are beyond the scope of this document.
AD-1の観点から見ると、AD-2のすべてのEUへの個別のユニキャストではなく、AD-2へのネイティブマルチキャストに関連する1つの欠点は、EUの数と送信されたバイト数をカウントできないことです。それらに配信されました。この情報は、顧客の請求および操作ログの観点から関連しています。このようなデータは、アプリケーション層によって収集されることが想定されています。この情報を生成するためのアプリケーション層メカニズムは、ソースプロバイダーとADオペレーターのすべての関連要件が十分に満たされるように、十分に堅牢である必要があります。これらのメソッドの詳細は、このドキュメントの範囲を超えています。
Architectural guidelines for this configuration are as follows:
この構成のアーキテクチャガイドラインは次のとおりです。
a. Dual homing for peering points between domains is recommended as a way to ensure reliability with full BGP table visibility.
a. BGPテーブルの完全な可視性で信頼性を確保する方法として、ドメイン間のピアリングポイントのデュアルホーミングをお勧めします。
b. If the peering point between AD-1 and AD-2 is a controlled network environment, then bandwidth can be allocated accordingly by the two domains to permit the transit of non-rate-adaptive multicast traffic. If this is not the case, then the multicast traffic must support congestion control via any of the mechanisms described in Section 4.1 of [BCP145].
b. AD-1とAD-2の間のピアリングポイントが制御されたネットワーク環境である場合、帯域幅は2つのドメインによって適宜割り当てられ、非レート適応型マルチキャストトラフィックの通過を許可します。そうでない場合、マルチキャストトラフィックは、[BCP145]のセクション4.1で説明されているメカニズムのいずれかによる輻輳制御をサポートする必要があります。
c. The sending and receiving of multicast traffic between two domains is typically determined by local policies associated with each domain. For example, if AD-1 is a service provider and AD-2 is an enterprise, then AD-1 may support local policies for traffic delivery to, but not traffic reception from, AD-2. Another example is the use of a policy by which AD-1 delivers specified content to AD-2 only if such delivery has been accepted by contract.
c. 2つのドメイン間のマルチキャストトラフィックの送受信は、通常、各ドメインに関連付けられたローカルポリシーによって決定されます。たとえば、AD-1がサービスプロバイダーで、AD-2がエンタープライズの場合、AD-1はAD-2へのトラフィック配信ではなく、AD-2からのトラフィック受信のローカルポリシーをサポートします。別の例は、AD-1がAD-2に指定のコンテンツを配信するポリシーの使用です（そのような配信が契約によって受け入れられた場合のみ）。
d. It is assumed that relevant information on multicast streams delivered to EUs in AD-2 is collected by available capabilities in the application layer. The precise nature and formats of the collected information will be determined by directives from the source owner and the domain operators.
d. AD-2のEUに配信されるマルチキャストストリームに関する関連情報は、アプリケーション層で利用可能な機能によって収集されると想定されています。収集された情報の正確な性質と形式は、ソースの所有者とドメインオペレーターからの指示によって決定されます。
The peering point is not native multicast enabled in this use case. There is a GRE tunnel provisioned over the peering point. See Figure 2.
このユースケースでは、ピアリングポイントはネイティブマルチキャスト対応ではありません。ピアリングポイントを介してプロビジョニングされたGREトンネルがあります。図2を参照してください。
------------------- -------------------
/ AD-1 \ / AD-2 \
/ (Multicast Enabled) \ / (Multicast Enabled) \
/ \ / \
| +----+ +---+ | (I1) | +---+ |
| | | +--+ |uBR|-|--------|-|uBR| +--+ | +----+
| | AS |-->|BR| +---+-| | +---+ |BR| -------->|-->| EU |
| | | +--+<........|........|........>+--+ |I2 +----+
\ +----+ / I1 \ /
\ / GRE \ /
\ / Tunnel \ /
------------------- -------------------
AD = Administrative Domain (independent autonomous system)
AS = multicast (e.g., content) Application Source
uBR = unicast Border Router - not necessarily multicast enabled;
may be the same router as BR
BR = Border Router - for multicast
I1 = AD-1 and AD-2 multicast interconnection (e.g., MP-BGP)
I2 = AD-2 and EU multicast connection
Figure 2: Content Distribution via GRE Tunnel
図2：GREトンネル経由のコンテンツ配信
In this case, interconnection I1 between AD-1 and AD-2 in Figure 2 is multicast enabled via a GRE tunnel [RFC2784] between the two BRs and encapsulating the multicast protocols across it.
この場合、図2のAD-1とAD-2間の相互接続I1は、2つのBR間のGREトンネル[RFC2784]を介してマルチキャストが有効になり、マルチキャストプロトコルをカプセル化します。
Normally, this approach is chosen if the uBR physically connected to the peering link cannot or should not be enabled for IP multicast. This approach may also be beneficial if the BR and uBR are the same device but the peering link is a broadcast domain (IXP); see Section 4.2.4.
通常、このアプローチは、ピアリングリンクに物理的に接続されているuBRがIPマルチキャストを有効にできないか、有効にする必要がない場合に選択されます。このアプローチは、BRとuBRが同じデバイスであるが、ピアリングリンクがブロードキャストドメイン（IXP）である場合にも有益です。セクション4.2.4を参照してください。
The routing configuration is basically unchanged: instead of running BGP (SAFI-2) ("SAFI" stands for "Subsequent Address Family Identifier") across the native IP multicast link between AD-1 and AD-2, BGP (SAFI-2) is now run across the GRE tunnel.
ルーティング設定は基本的に変更されていません。AD-1とAD-2の間のネイティブIPマルチキャストリンクを介してBGP（SAFI-2）を実行する代わりに（「SAFI」は「後続アドレスファミリ識別子」を表します）、BGP（SAFI-2）これで、GREトンネルを介して実行されます。
Advantages of this configuration:
この構成の利点：
o Highly efficient use of bandwidth in both domains, although not as efficient as the fully native multicast use case (Section 3.1).
o 完全にネイティブなマルチキャストの使用例（セクション3.1）ほど効率的ではありませんが、両方のドメインでの帯域幅の非常に効率的な使用。
o Fewer devices in the path traversed by the multicast stream when compared to an AMT-enabled peering point.
o AMT対応のピアリングポイントと比較すると、マルチキャストストリームが通過するパス内のデバイスが少なくなります。
o Ability to support partial and/or incremental IP multicast deployments in AD-1 and/or AD-2: only the path or paths between the AS/BR (AD-1) and the BR/EU (AD-2) need to be multicast enabled. The uBRs may not support IP multicast or enabling it could be seen as operationally risky on that important edge node, whereas dedicated BR nodes for IP multicast may (at least initially) be more acceptable. The BR can also be located such that only parts of the domain may need to support native IP multicast (e.g., only the core in AD-1 but not edge networks towards the uBR).
o AD-1またはAD-2、あるいはその両方での部分的および/または増分的なIPマルチキャスト展開をサポートする機能：AS / BR（AD-1）とBR / EU（AD-2）の間のパスのみが必要です。マルチキャストが有効。 uBRはIPマルチキャストをサポートしていないか、それを有効にすると、その重要なエッジノードで運用上リスクがあると見なされる可能性がありますが、IPマルチキャスト専用のBRノードは（少なくとも最初は）より受け入れやすい場合があります。 BRは、ドメインの一部のみがネイティブIPマルチキャストをサポートする必要があるように配置することもできます（たとえば、AD-1のコアのみで、uBRへのエッジネットワークはサポートしません）。
o GRE is an existing technology and is relatively simple to implement.
o GREは既存のテクノロジーであり、実装は比較的簡単です。
Disadvantages of this configuration:
この構成の欠点：
o Per Use Case 3.1, current router technology cannot count the number of EUs or the number of bytes transmitted.
o ユースケース3.1に従って、現在のルーターテクノロジーはEUの数や送信されたバイト数をカウントできません。
o The GRE tunnel requires manual configuration.
o GREトンネルには手動設定が必要です。
o The GRE tunnel must be established prior to starting the stream.
o ストリームを開始する前に、GREトンネルを確立する必要があります。
o The GRE tunnel is often left pinned up.
o 多くの場合、GREトンネルは固定されたままです。
Architectural guidelines for this configuration include the following:
この構成のアーキテクチャガイドラインは次のとおりです。
Guidelines (a) through (d) are the same as those described in Use Case 3.1. Two additional guidelines are as follows:
ガイドライン（a）〜（d）は、ユースケース3.1で説明したものと同じです。追加の2つのガイドラインは次のとおりです。
e. GRE tunnels are typically configured manually between peering points to support multicast delivery between domains.
e. GREトンネルは通常、ピアリングポイント間に手動で構成され、ドメイン間のマルチキャスト配信をサポートします。
f. It is recommended that the GRE tunnel (tunnel server) configuration in the source network be such that it only advertises the routes to the application sources and not to the entire network. This practice will prevent unauthorized delivery of applications through the tunnel (for example, if the application (e.g., content) is not part of an agreed-upon inter-domain partnership).
f。ソースネットワークのGREトンネル（トンネルサーバー）構成は、ネットワーク全体ではなく、アプリケーションソースへのルートのみをアドバタイズするようにすることをお勧めします。この方法により、トンネルを介したアプリケーションの不正な配信が防止されます（たとえば、アプリケーション（コンテンツなど）が合意済みのドメイン間パートナーシップの一部でない場合）。
It is assumed that both administrative domains in this use case are native multicast enabled here; however, the peering point is not.
この使用例では、両方の管理ドメインがネイティブマルチキャストが有効になっていると想定されています。ただし、ピアリングポイントはそうではありません。
The peering point is enabled with AMT. The basic configuration is depicted in Figure 3.
ピアリングポイントはAMTで有効になっています。基本構成を図3に示します。
------------------- -------------------
/ AD-1 \ / AD-2 \
/ (Multicast Enabled) \ / (Multicast Enabled) \
/ \ / \
| +----+ +---+ | I1 | +---+ |
| | | +--+ |uBR|-|--------|-|uBR| +--+ | +----+
| | AS |-->|AR| +---+-| | +---+ |AG| -------->|-->| EU |
| | | +--+<........|........|........>+--+ |I2 +----+
\ +----+ / AMT \ /
\ / Tunnel \ /
\ / \ /
------------------- -------------------
AD = Administrative Domain (independent autonomous system)
AS = multicast (e.g., content) Application Source
AR = AMT Relay
AG = AMT Gateway
uBR = unicast Border Router - not multicast enabled;
also, either AR = uBR (AD-1) or uBR = AG (AD-2)
I1 = AMT interconnection between AD-1 and AD-2
I2 = AD-2 and EU multicast connection
Figure 3: AMT Interconnection between AD-1 and AD-2
図3：AD-1とAD-2間のAMT相互接続
Advantages of this configuration:
この構成の利点：
o Highly efficient use of bandwidth in AD-1.
o AD-1での帯域幅の非常に効率的な使用。
o AMT is an existing technology and is relatively simple to implement. Attractive properties of AMT include the following:
o AMTは既存の技術であり、実装は比較的簡単です。 AMTの魅力的な特性は次のとおりです。
* Dynamic interconnection between the gateway-relay pair across the peering point.
* ピアリングポイント間のゲートウェイとリレーのペア間の動的相互接続。
* Ability to serve clients and servers with differing policies.
* 異なるポリシーでクライアントとサーバーにサービスを提供する機能。
Disadvantages of this configuration:
この構成の欠点：
o Per Use Case 3.1 (AD-2 is native multicast), current router technology cannot count the number of EUs or the number of bytes transmitted to all EUs.
o ユースケース3.1（AD-2はネイティブマルチキャスト）ごとに、現在のルーターテクノロジーはEUの数またはすべてのEUに送信されたバイト数をカウントできません。
o Additional devices (AMT gateway and relay pairs) may be introduced into the path if these services are not incorporated into the existing routing nodes.
o これらのサービスが既存のルーティングノードに組み込まれていない場合、追加のデバイス（AMTゲートウェイとリレーペア）がパスに導入される可能性があります。
o Currently undefined mechanisms for the AG to automatically select the optimal AR.
o AGが最適なARを自動的に選択するための現在未定義のメカニズム。
Architectural guidelines for this configuration are as follows:
この構成のアーキテクチャガイドラインは次のとおりです。
Guidelines (a) through (d) are the same as those described in Use Case 3.1. In addition,
ガイドライン（a）〜（d）は、ユースケース3.1で説明したものと同じです。加えて、
e. It is recommended that AMT relay and gateway pairs be configured at the peering points to support multicast delivery between domains. AMT tunnels will then configure dynamically across the peering points once the gateway in AD-2 receives the (S,G) information from the EU.
e. ドメイン間のマルチキャスト配信をサポートするには、AMTリレーとゲートウェイのペアをピアリングポイントで構成することをお勧めします。 AD-2のゲートウェイがEUから（S、G）情報を受信すると、AMTトンネルはピアリングポイント全体に動的に構成されます。
In this AMT use case, AD-2 is not multicast enabled. Hence, the interconnection between AD-2 and the EU is also not multicast enabled. This use case is depicted in Figure 4.
このAMTの使用例では、AD-2はマルチキャスト対応ではありません。したがって、AD-2とEU間の相互接続もマルチキャスト対応ではありません。この使用例を図4に示します。
------------------- -------------------
/ AD-1 \ / AD-2 \
/ (Multicast Enabled) \ / (Not Multicast \
/ \ / Enabled) \ N(large)
| +----+ +---+ | | +---+ | # EUs
| | | +--+ |uBR|-|--------|-|uBR| | +----+
| | AS |-->|AR| +---+-| | +---+ ................>|EU/G|
| | | +--+<........|........|........... |I2 +----+
\ +----+ / N x AMT\ /
\ / Tunnel \ /
\ / \ /
------------------- -------------------
AS = multicast (e.g., content) Application Source
uBR = unicast Border Router - not multicast enabled;
otherwise, AR = uBR (in AD-1)
AR = AMT Relay
EU/G = Gateway client embedded in EU device
I2 = AMT tunnel connecting EU/G to AR in AD-1 through
non-multicast-enabled AD-2
Figure 4: AMT Tunnel Connecting AD-1 AMT Relay and EU Gateway
図4：AD-1 AMTリレーとEUゲートウェイを接続するAMTトンネル
This use case is equivalent to having unicast distribution of the application through AD-2. The total number of AMT tunnels would be equal to the total number of EUs requesting the application. The peering point thus needs to accommodate the total number of AMT tunnels between the two domains. Each AMT tunnel can provide the data usage associated with each EU.
この使用例は、AD-2を介したアプリケーションのユニキャスト配布と同等です。 AMTトンネルの総数は、アプリケーションを要求するEUの総数と等しくなります。したがって、ピアリングポイントは、2つのドメイン間のAMTトンネルの総数に対応する必要があります。各AMTトンネルは、各EUに関連付けられたデータ使用を提供できます。
Advantages of this configuration:
この構成の利点：
o Efficient use of bandwidth in AD-1 (the closer the AR is to the uBR, the more efficient).
o AD-1での帯域幅の効率的な使用（ARがuBRに近いほど、効率的です）。
o Ability of AD-1 to introduce content delivery based on IP multicast, without any support by network devices in AD-2: only the application side in the EU device needs to perform AMT gateway library functionality to receive traffic from the AMT relay.
o AD-2のネットワークデバイスによるサポートなしでIPマルチキャストに基づくコンテンツ配信を導入するAD-1の機能：EUデバイスのアプリケーション側のみがAMTゲートウェイライブラリ機能を実行してAMTリレーからトラフィックを受信する必要があります。
o Allows AD-2 to "upgrade" to Use Case 3.5 (see Section 3.5) at a later time, without any change in AD-1 at that time.
o AD-1を変更せずに、AD-2が後でユースケース3.5（セクション3.5を参照）に「アップグレード」できるようにします。
o AMT is an existing technology and is relatively simple to implement. Attractive properties of AMT include the following:
o AMTは既存の技術であり、実装は比較的簡単です。 AMTの魅力的な特性は次のとおりです。
* Dynamic interconnection between the AMT gateway-relay pair across the peering point.
* ピアリングポイント間のAMTゲートウェイリレーペア間の動的相互接続。
* Ability to serve clients and servers with differing policies.
* 異なるポリシーでクライアントとサーバーにサービスを提供する機能。
o Each AMT tunnel serves as a count for each EU and is also able to track data usage (bytes) delivered to the EU.
o 各AMTトンネルは、各EUのカウントとして機能し、EUに配信されたデータ使用量（バイト）を追跡することもできます。
Disadvantages of this configuration:
この構成の欠点：
o Additional devices (AMT gateway and relay pairs) are introduced into the transport path.
o 追加のデバイス（AMTゲートウェイとリレーペア）がトランスポートパスに導入されます。
o Assuming multiple peering points between the domains, the EU gateway needs to be able to find the "correct" AMT relay in AD-1.
o ドメイン間の複数のピアリングポイントを想定して、EUゲートウェイはAD-1で「正しい」AMTリレーを見つけることができる必要があります。
Architectural guidelines for this configuration are as follows:
この構成のアーキテクチャガイドラインは次のとおりです。
Guidelines (a) through (c) are the same as those described in Use Case 3.1. In addition,
ガイドライン（a）〜（c）は、ユースケース3.1で説明したものと同じです。加えて、
d. It is necessary that proper procedures be implemented such that the AMT gateway at the EU device is able to find the correct AMT relay for each (S,G) content stream. Standard mechanisms for that selection are still subject to ongoing work. This includes the use of anycast gateway addresses, anycast DNS names, or explicit configuration that maps (S,G) to a relay address; or letting the application in the EU/G provide the relay address to the embedded AMT gateway function.
d. EUデバイスのAMTゲートウェイが（S、G）コンテンツストリームごとに正しいAMTリレーを見つけられるように、適切な手順を実装する必要があります。その選択のための標準的なメカニズムはまだ進行中の作業の対象となります。これには、エニーキャストゲートウェイアドレス、エニーキャストDNS名、または（S、G）をリレーアドレスにマップする明示的な構成の使用が含まれます。または、EU / Gのアプリケーションにリレーアドレスを組み込みAMTゲートウェイ機能に提供させる。
e. The AMT tunnel's capabilities are expected to be sufficient for the purpose of collecting relevant information on the multicast streams delivered to EUs in AD-2.
e. AMTトンネルの機能は、AD-2のEUに配信されるマルチキャストストリームに関する関連情報を収集する目的で十分であると期待されます。
Figure 5 illustrates a variation of Use Case 3.4:
図5は、ユースケース3.4のバリエーションを示しています。
------------------- -------------------
/ AD-1 \ / AD-2 \
/ (Multicast Enabled) \ / (Not Multicast \
/ +---+ \ (I1) / +---+ Enabled) \
| +----+ |uBR|-|--------|-|uBR| |
| | | +--+ +---+ | | +---+ +---+ | +----+
| | AS |-->|AR|<........|.... | +---+ |AG/|....>|EU/G|
| | | +--+ | ......|.|AG/|..........>|AR2| |I3 +----+
\ +----+ / I1 \ |AR1| I2 +---+ /
\ / Single \+---+ /
\ / AMT Tunnel \ /
------------------- -------------------
uBR = unicast Border Router - not multicast enabled;
also, either AR = uBR (AD-1) or uBR = AGAR1 (AD-2)
AS = multicast (e.g., content) Application Source
AR = AMT Relay in AD-1
AGAR1 = AMT Gateway/Relay node in AD-2 across peering point
I1 = AMT tunnel connecting AR in AD-1 to gateway in AGAR1 in AD-2
AGAR2 = AMT Gateway/Relay node at AD-2 network edge
I2 = AMT tunnel connecting relay in AGAR1 to gateway in AGAR2
EU/G = Gateway client embedded in EU device
I3 = AMT tunnel connecting EU/G to AR in AGAR2
Figure 5: AMT Tunnel Connecting AMT Gateways and Relays
図5：AMTゲートウェイとリレーを接続するAMTトンネル
Use Case 3.4 results in several long AMT tunnels crossing the entire network of AD-2 linking the EU device and the AMT relay in AD-1 through the peering point. Depending on the number of EUs, there is a likelihood of an unacceptably high amount of traffic due to the large number of AMT tunnels -- and unicast streams -- through the peering point. This situation can be alleviated as follows:
ユースケース3.4では、EUデバイスとAD-1のAMTリレーをピアリングポイント経由でリンクするAD-2のネットワーク全体を横断するいくつかの長いAMTトンネルが発生します。 EUの数によっては、ピアリングポイントを介した多数のAMTトンネル（およびユニキャストストリーム）が原因で、許容できないほど大量のトラフィックが発生する可能性があります。この状況は、次のようにして緩和できます。
o Provisioning of strategically located AMT nodes in AD-2. An AMT node comprises co-location of an AMT gateway and an AMT relay. No change is required by AD-1, as compared to Use Case 3.4. This can be done whenever AD-2 sees fit (e.g., too much traffic across the peering point).
o AD-2で戦略的に配置されたAMTノードのプロビジョニング。 AMTノードは、AMTゲートウェイとAMTリレーの同じ場所に配置されます。ユースケース3.4と比較して、AD-1では変更は必要ありません。これは、AD-2が適切であると見なす場合はいつでも実行できます（たとえば、ピアリングポイント全体のトラフィックが多すぎるなど）。
o One such node is on the AD-2 side of the peering point (AMT node AGAR1 in Figure 5).
o そのようなノードの1つは、ピアリングポイントのAD-2側にあります（図5のAMTノードAGAR1）。
o A single AMT tunnel established across the peering point linking the AMT relay in AD-1 to the AMT gateway in AMT node AGAR1 in AD-2.
o AD-1のAMTリレーをAD-2のAMTノードAGAR1のAMTゲートウェイにリンクするピアリングポイント全体で確立された単一のAMTトンネル。
o AMT tunnels linking AMT node AGAR1 at the peering point in AD-2 to other AMT nodes located at the edges of AD-2: e.g., AMT tunnel I2 linking the AMT relay in AGAR1 to the AMT gateway in AMT node AGAR2 (Figure 5).
o AD-2のピアリングポイントにあるAMTノードAGAR1をAD-2のエッジにある他のAMTノードにリンクするAMTトンネル：たとえば、AGAR1のAMTリレーをAMTノードAGAR2のAMTゲートウェイにリンクするAMTトンネルI2（図5） 。
o AMT tunnels linking an EU device (via a gateway client embedded in the device) and an AMT relay in an appropriate AMT node at the edge of AD-2: e.g., I3 linking the EU gateway in the device to the AMT relay in AMT node AGAR2.
o EUデバイスを（デバイスに組み込まれたゲートウェイクライアントを介して）リンクするAMTトンネルとAD-2のエッジにある適切なAMTノードのAMTリレー：たとえば、デバイスのEUゲートウェイをAMTノードのAMTリレーにリンクするI3 AGAR2。
o In the simplest option (not shown), AD-2 only deploys a single AGAR1 node and lets the EU/G build AMT tunnels directly to it. This setup already solves the problem of replicated traffic across the peering point. As soon as there is a need to support more AMT tunnels to the EU/G, then additional AGAR2 nodes can be deployed by AD-2.
o 最も単純なオプション（図には示されていません）では、AD-2は単一のAGAR1ノードのみを展開し、EU / Gがそれに直接AMTトンネルを構築できるようにします。この設定により、ピアリングポイント間でトラフィックが複製されるという問題がすでに解決されています。 EU / GへのAMTトンネルをさらにサポートする必要があるとすぐに、追加のAGAR2ノードをAD-2によって展開できます。
The advantage of such a chained set of AMT tunnels is that the total number of unicast streams across AD-2 is significantly reduced, thus freeing up bandwidth. Additionally, there will be a single unicast stream across the peering point instead of, possibly, an unacceptably large number of such streams per Use Case 3.4. However, this implies that several AMT tunnels will need to be dynamically configured by the various AMT gateways, based solely on the (S,G) information received from the application client at the EU device. A suitable mechanism for such dynamic configurations is therefore critical.
このようなAMTトンネルのチェーンセットの利点は、AD-2全体のユニキャストストリームの総数が大幅に削減され、帯域幅が解放されることです。さらに、ユースケース3.4ごとに許容できないほど多くのそのようなストリームではなく、ピアリングポイント全体に単一のユニキャストストリームが存在します。ただし、これは、EUデバイスでアプリケーションクライアントから受信した（S、G）情報のみに基づいて、さまざまなAMTゲートウェイによっていくつかのAMTトンネルを動的に構成する必要があることを意味します。したがって、このような動的構成に適したメカニズムは重要です。
Architectural guidelines for this configuration are as follows:
この構成のアーキテクチャガイドラインは次のとおりです。
Guidelines (a) through (c) are the same as those described in Use Case 3.1. In addition,
ガイドライン（a）〜（c）は、ユースケース3.1で説明したものと同じです。加えて、
d. It is necessary that proper procedures be implemented such that the various AMT gateways (at the EU devices and the AMT nodes in AD-2) are able to find the correct AMT relay in other AMT nodes as appropriate. Standard mechanisms for that selection are still subject to ongoing work. This includes the use of anycast gateway addresses, anycast DNS names, or explicit configuration that maps (S,G) to a relay address. On the EU/G, this mapping information may come from the application.
d. さまざまなAMTゲートウェイ（EUデバイスおよびAD-2のAMTノード）が他のAMTノードで適切なAMTリレーを適切に見つけられるように、適切な手順を実装する必要があります。その選択のための標準的なメカニズムはまだ進行中の作業の対象となります。これには、エニーキャストゲートウェイアドレス、エニーキャストDNS名、または（S、G）をリレーアドレスにマップする明示的な構成の使用が含まれます。 EU / Gでは、このマッピング情報はアプリケーションから取得される場合があります。
e. The AMT tunnel's capabilities are expected to be sufficient for the purpose of collecting relevant information on the multicast streams delivered to EUs in AD-2.
e. AMTトンネルの機能は、AD-2のEUに配信されるマルチキャストストリームに関する関連情報を収集する目的で十分であると期待されます。
Supporting functions and related interfaces over the peering point that enable the multicast transport of the application are listed in this section. Critical information parameters that need to be exchanged in support of these functions are enumerated, along with guidelines as appropriate. Specific interface functions for consideration are as follows.
このセクションでは、アプリケーションのマルチキャストトランスポートを可能にする、ピアリングポイントを介したサポート機能と関連インターフェイスを示します。これらの機能をサポートするために交換する必要がある重要な情報パラメーターが、必要に応じてガイドラインとともに列挙されています。考慮すべき具体的なインターフェース関数は以下の通りです。
The term "network interconnection transport" refers to the interconnection points between the two administrative domains. The following is a representative set of attributes that the two administrative domains will need to agree on to support multicast delivery.
「ネットワーク相互接続トランスポート」という用語は、2つの管理ドメイン間の相互接続ポイントを指します。以下は、2つの管理ドメインがマルチキャスト配信をサポートするために合意する必要がある属性の代表的なセットです。
o Number of peering points.
o ピアリングポイントの数。
o Peering point addresses and locations.
o ピアリングポイントのアドレスと場所。
o Connection type - Dedicated for multicast delivery or shared with other services.
o 接続タイプ-マルチキャスト配信専用または他のサービスと共有。
o Connection mode - Direct connectivity between the two ADs or via another ISP.
o 接続モード-2つのAD間の直接接続または別のISPを介した接続。
o Peering point protocol support - Multicast protocols that will be used for multicast delivery will need to be supported at these points. Examples of such protocols include External BGP (EBGP) [RFC4760] peering via MP-BGP (Multiprotocol BGP) SAFI-2 [RFC4760].
o ピアリングポイントプロトコルのサポート-マルチキャスト配信に使用されるマルチキャストプロトコルは、これらのポイントでサポートされる必要があります。このようなプロトコルの例には、外部BGP（EBGP）[RFC4760] MP-BGP（マルチプロトコルBGP）SAFI-2 [RFC4760]によるピアリングが含まれます。
o Bandwidth allocation - If shared with other services, then there needs to be a determination of the share of bandwidth reserved for multicast delivery. See Section 4.1.1 below for more details.
o 帯域幅の割り当て-他のサービスと共有する場合は、マルチキャスト配信用に予約されている帯域幅のシェアを決定する必要があります。詳細については、以下のセクション4.1.1を参照してください。
o QoS requirements - Delay and/or latency specifications that need to be specified in an SLA.
o QoS要件-SLAで指定する必要がある遅延および/または遅延の仕様。
o AD roles and responsibilities - The role played by each AD for provisioning and maintaining the set of peering points to support multicast delivery.
o ADの役割と責任-マルチキャスト配信をサポートする一連のピアリングポイントをプロビジョニングおよび維持するために各ADが果たす役割。
Like IP unicast traffic, IP multicast traffic carried across non-controlled networks must comply with congestion control principles as described in [BCP41] and as explained in detail for UDP IP multicast in [BCP145].
IPユニキャストトラフィックと同様に、非制御ネットワークを介して伝送されるIPマルチキャストトラフィックは、[BCP41]で説明され、[BCP145]でUDP IPマルチキャストについて詳細に説明されている、輻輳制御の原則に準拠する必要があります。
Non-controlled networks (such as the Internet) are networks where there is no policy for managing bandwidth other than best effort with a fair share of bandwidth under congestion. As a simplified rule of thumb, complying with congestion control principles means reducing bandwidth under congestion in a way that is fair to competing (typically TCP) flows ("rate adaptive").
制御されていないネットワーク（インターネットなど）は、輻輳下で帯域幅を公平に共有してベストエフォート以外の帯域幅を管理するポリシーがないネットワークです。単純化した経験則として、輻輳制御の原則に準拠することは、競合する（通常はTCP）フローに公平な方法（「レートアダプティブ」）で輻輳下の帯域幅を削減することを意味します。
In many instances, multicast content delivery evolves from intra-domain deployments where it is handled as a controlled network service and does not comply with congestion control principles. It was given a reserved amount of bandwidth and admitted to the network so that congestion never occurs. Therefore, the congestion control issue should be given specific attention when evolving to an inter-domain peering deployment.
多くの場合、マルチキャストコンテンツ配信は、制御されたネットワークサービスとして処理され、輻輳制御の原則に準拠していないドメイン内の展開から発展します。予約済みの帯域幅が割り当てられ、輻輳が発生しないようにネットワークに許可されました。したがって、輻輳制御の問題は、ドメイン間ピアリングの展開に発展するときに、特別な注意を払う必要があります。
In the case where end-to-end IP multicast traffic passes across the network of two ADs (and their subsidiaries/customers), both ADs must agree on a consistent traffic-management policy. If, for example, AD-1 sources non-congestion-aware IP multicast traffic and AD-2 carries it as best-effort traffic across links shared with other Internet traffic (subject to congestion), this will not work: under congestion, some amount of that traffic will be dropped, often rendering the remaining packets as undecodable garbage clogging up the network in AD-2; because this traffic is not congestion aware, the loss does not reduce this rate. Competing traffic will not get their fair share under congestion, and EUs will be frustrated by the extremely bad quality of both their IP multicast traffic and other (e.g., TCP) traffic. Note that this is not an IP multicast technology issue but is solely a transport-layer / application-layer issue: the problem would just as likely happen if AD-1 were to send non-rate-adaptive unicast traffic -- for example, legacy IPTV video-on-demand traffic, which is typically also non-congestion aware. Note that because rate adaptation in IP unicast video is commonplace today due to the availability of ABR (Adaptive Bitrate) video, it is very unlikely that this will happen in reality with IP unicast.
エンドツーエンドのIPマルチキャストトラフィックが2つのAD（およびその子会社/顧客）のネットワークを通過する場合、両方のADが一貫したトラフィック管理ポリシーに同意する必要があります。たとえば、AD-1が非輻輳認識IPマルチキャストトラフィックをソースし、AD-2がそれを他のインターネットトラフィックと共有されているリンク全体のベストエフォートトラフィックとして送信する場合（輻輳が発生する可能性があります）、これは機能しません。そのトラフィックの量はドロップされ、多くの場合、残りのパケットはAD-2でネットワークを詰まらせるデコードできないゴミとしてレンダリングされます。このトラフィックは輻輳に対応していないため、損失によってこの速度が低下することはありません。競合するトラフィックは、輻輳下で公平に配分されず、EUは、IPマルチキャストトラフィックと他の（TCPなど）トラフィックの両方の品質が非常に悪いことに不満を感じます。これはIPマルチキャストテクノロジーの問題ではなく、単にトランスポート層/アプリケーション層の問題であることに注意してください。AD-1が非レート適応型ユニキャストトラフィックを送信する場合、たとえばレガシーなどの問題が発生する可能性が高いです。 IPTVビデオオンデマンドトラフィック。通常、これも輻輳を認識しません。 ABR（Adaptive Bitrate）ビデオが利用できるため、IPユニキャストビデオでのレート調整は今日では一般的であるため、これがIPユニキャストで実際に発生することはほとんどありません。
While the rules for traffic management apply whether IP multicast is tunneled or not, the one feature that can make AMT tunnels more difficult is the unpredictability of bandwidth requirements across underlying links because of the way they can be used: with native IP multicast or GRE tunnels, the amount of bandwidth depends on the amount of content -- not the number of EUs -- and is therefore easier to plan for. AMT tunnels terminating in the EU/G, on the other hand, scale with the number of EUs. In the vicinity of the AMT relay, they can introduce a very large amount of replicated traffic, and it is not always feasible to provision enough bandwidth for all possible EUs to get the highest quality for all their content during peak utilization in such setups -- unless the AMT relays are very close to the EU edge. Therefore, it is also recommended that IP multicast rate adaptation be used, even inside controlled networks, when using AMT tunnels directly to the EU/G.
トラフィック管理のルールはIPマルチキャストがトンネリングされるかどうかに関係なく適用されますが、AMTトンネルをより困難にする可能性がある機能の1つは、ネイティブIPマルチキャストまたはGREトンネルを使用できるため、基になるリンク全体の帯域幅要件が予測できないことです。 、帯域幅の量は、EUの数ではなくコンテンツの量に依存するため、計画が容易です。一方、EU / Gで終端するAMTトンネルは、EUの数に応じて拡張されます。 AMTリレーの近くでは、非常に大量の複製されたトラフィックが発生する可能性があり、そのような設定でのピーク使用時に、すべての可能なEUがすべてのコンテンツに対して最高の品質を得るために十分な帯域幅をプロビジョニングすることは常に実現可能ではありません- AMTリレーがEUエッジに非常に近い場合を除きます。したがって、EU / Gに直接AMTトンネルを使用する場合は、制御されたネットワーク内であっても、IPマルチキャストレートアダプテーションを使用することをお勧めします。
Note that rate-adaptive IP multicast traffic in general does not mean that the sender is reducing the bitrate but rather that the EUs that experience congestion are joining to a lower-bitrate (S,G) stream of the content, similar to ABR streaming over TCP. Therefore, migration from a non-rate-adaptive bitrate to a rate-adaptive bitrate in IP multicast will also change the dynamic (S,G) join behavior in the network, resulting in potentially higher performance requirements for IP multicast protocols (IGMP/PIM), especially on the last hops where dynamic changes occur (including AMT gateways/relays): in non-rate-adaptive IP multicast, only "channel change" causes state change, but in rate-adaptive multicast, congestion also causes state change.
一般にレート適応型IPマルチキャストトラフィックは、送信者がビットレートを削減しているのではなく、輻輳が発生しているEUがコンテンツの低ビットレート（S、G）ストリームに参加していることを意味します。 TCP。したがって、IPマルチキャストの非レート適応型ビットレートからレート適応型ビットレートに移行すると、ネットワークの動的（S、G）結合動作も変更され、IPマルチキャストプロトコル（IGMP / PIM）のパフォーマンス要件が高くなる可能性があります。 ）、特に動的変更が発生する最後のホップ（AMTゲートウェイ/リレーを含む）では、非レート適応型IPマルチキャストでは、「チャネル変更」のみが状態変化を引き起こしますが、レート適応型マルチキャストでは、輻輳も状態変化を引き起こします。
Even though not fully specified in this document, peerings that rely on GRE/AMT tunnels may be across one or more transit ADs instead of an exclusive (non-shared, L1/L2) path. Unless those transit ADs are explicitly contracted to provide other than "best effort" transit for the tunneled traffic, the tunneled IP multicast traffic must be rate adaptive in order to not violate BCP 41 across those transit ADs.
このドキュメントでは完全に指定されていませんが、GRE / AMTトンネルに依存するピアリングは、排他的（非共有、L1 / L2）パスではなく、1つ以上の中継ADを通過する場合があります。これらのトランジットADがトンネルトラフィックに「ベストエフォート」以外のトランジットを提供するよう明示的に契約されていない限り、これらのトランジットAD全体でBCP 41に違反しないように、トンネルIPマルチキャストトラフィックはレートアダプティブである必要があります。
The main objective for multicast delivery routing is to ensure that the EU receives the multicast stream from the "most optimal" source [INF_ATIS_10], which typically:
マルチキャスト配信ルーティングの主な目的は、EUが「最も最適な」ソース[INF_ATIS_10]からマルチキャストストリームを受信できるようにすることです。
o Maximizes the multicast portion of the transport and minimizes any unicast portion of the delivery, and
o トランスポートのマルチキャスト部分を最大化し、配信のユニキャスト部分を最小化します。
o Minimizes the overall combined route distance of the network(s).
o ネットワークの総合ルート距離を最小化します。
This routing objective applies to both native multicast and AMT; the actual methodology of the solution will be different for each. Regardless, the routing solution is expected to:
このルーティングの目的は、ネイティブマルチキャストとAMTの両方に適用されます。ソリューションの実際の方法はそれぞれ異なります。いずれにせよ、ルーティングソリューションは次のことを期待されています。
o Be scalable,
o スケーラブルであること
o Avoid or minimize new protocol development or modifications, and
o 新しいプロトコルの開発または変更を回避または最小限に抑える。
o Be robust enough to achieve high reliability and to automatically adjust to changes and problems in the multicast infrastructure.
o 高い信頼性を実現し、マルチキャストインフラストラクチャの変更や問題に自動的に適応するのに十分な堅牢性があります。
For both native and AMT environments, having a source as close as possible to the EU network is most desirable; therefore, in some cases, an AD may prefer to have multiple sources near different peering points. However, that is entirely an implementation issue.
ネイティブ環境とAMT環境の両方で、EUネットワークにできるだけ近いソースを使用することが最も望ましいです。したがって、場合によっては、ADは異なるピアリングポイントの近くに複数のソースを持つことを好む場合があります。ただし、これは完全に実装上の問題です。
Native multicast simply requires that the administrative domains coordinate and advertise the correct source address(es) at their network interconnection peering points (i.e., BRs). An example of multicast delivery via a native multicast process across two administrative domains is as follows, assuming that the interconnecting peering points are also multicast enabled:
ネイティブマルチキャストでは、管理ドメインがネットワーク相互接続のピアリングポイント（つまり、BR）で正しい送信元アドレスを調整して通知する必要があります。 2つの管理ドメインにまたがるネイティブマルチキャストプロセスによるマルチキャスト配信の例は、相互接続するピアリングポイントでもマルチキャストが有効になっていると想定して、次のとおりです。
o Appropriate information is obtained by the EU client, who is a subscriber to AD-2 (see Use Case 3.1). This information is in the form of metadata, and it contains instructions directing the EU client to launch an appropriate application if necessary, as well as additional information for the application about the source location and the group (or stream) ID in the form of (S,G) data. The "S" portion provides the name or IP address of the source of the multicast stream. The metadata may also contain alternate delivery information, such as specifying the unicast address of the stream.
o AD-2のサブスクライバーであるEUクライアントが適切な情報を取得します（使用例3.1を参照）。この情報はメタデータの形式であり、必要に応じて適切なアプリケーションを起動するようにEUクライアントに指示する指示、および（の形式でのソースの場所とグループ（またはストリーム）IDに関するアプリケーションの追加情報が含まれます。 S、G）データ。 「S」部分は、マルチキャストストリームのソースの名前またはIPアドレスを提供します。メタデータには、ストリームのユニキャストアドレスの指定など、代替配信情報も含まれる場合があります。
o The client uses the join message with (S,G) to join the multicast stream [RFC4604]. To facilitate this process, the two ADs need to do the following:
o クライアントは、（S、G）のjoinメッセージを使用して、マルチキャストストリームに参加します[RFC4604]。このプロセスを容易にするために、2人のADは次のことを行う必要があります。
* Advertise the source ID(s) over the peering points.
* ピアリングポイントを介してソースIDをアドバタイズします。
* Exchange such relevant peering point information as capacity and utilization.
* 容量や使用率などの関連するピアリングポイント情報を交換します。
* Implement compatible multicast protocols to ensure proper multicast delivery across the peering points.
* 互換性のあるマルチキャストプロトコルを実装して、ピアリングポイント間でマルチキャストが適切に配信されるようにします。
If the interconnecting peering point is not multicast enabled and both ADs are multicast enabled, then a simple solution is to provision a GRE tunnel between the two ADs; see Use Case 3.2 (Section 3.2). The termination points of the tunnel will usually be a network engineering decision but generally will be between the BRs or even between the AD-2 BR and the AD-1 source (or source access router). The GRE tunnel would allow end-to-end native multicast or AMT multicast to traverse the interface. Coordination and advertisement of the source IP are still required.
相互接続するピアリングポイントがマルチキャスト対応ではなく、両方のADがマルチキャスト対応である場合、簡単な解決策は、2つのAD間にGREトンネルをプロビジョニングすることです。ユースケース3.2（セクション3.2）を参照してください。トンネルの終端ポイントは、通常、ネットワークエンジニアリングの決定ですが、一般的にはBR間、またはAD-2 BRとAD-1ソース（またはソースアクセスルータ）の間でもあります。 GREトンネルは、エンドツーエンドのネイティブマルチキャストまたはAMTマルチキャストがインターフェイスを通過できるようにします。ソースIPの調整と通知は引き続き必要です。
The two ADs need to follow the same process as the process described in Section 4.2.1 to facilitate multicast delivery across the peering points.
2つのADは、ピアリングポイント間のマルチキャスト配信を容易にするために、セクション4.2.1で説明されているプロセスと同じプロセスに従う必要があります。
Unlike native multicast (with or without GRE), an AMT multicast environment is more complex. It presents a two-layered problem in that there are two criteria that should be simultaneously met:
ネイティブマルチキャスト（GREの有無にかかわらず）とは異なり、AMTマルチキャスト環境はより複雑です。同時に満たすべき2つの基準があるという点で、2層の問題が発生します。
o Find the closest AMT relay to the EU that also has multicast connectivity to the content source, and
o コンテンツソースへのマルチキャスト接続も持つ、EUに最も近いAMTリレーを見つけます。
o Minimize the AMT unicast tunnel distance.
o AMTユニキャストトンネル距離を最小化します。
There are essentially two components in the AMT specification:
AMT仕様には基本的に2つのコンポーネントがあります。
AMT relays: These serve the purpose of tunneling UDP multicast traffic to the receivers (i.e., endpoints). The AMT relay will receive the traffic natively from the multicast media source and will replicate the stream on behalf of the downstream AMT gateways, encapsulating the multicast packets into unicast packets and sending them over the tunnel toward the AMT gateways. In addition, the AMT relay may collect various usage and activity statistics. This results in moving the replication point closer to the EU and cuts down on traffic across the network. Thus, the linear costs of adding unicast subscribers can be avoided. However, unicast replication is still required for each requesting endpoint within the unicast-only network.
AMTリレー：UDPマルチキャストトラフィックを受信者（エンドポイント）にトンネリングする目的で使用されます。 AMTリレーは、マルチキャストメディアソースからネイティブにトラフィックを受信し、ダウンストリームAMTゲートウェイに代わってストリームを複製し、マルチキャストパケットをユニキャストパケットにカプセル化し、トンネルを介してAMTゲートウェイに送信します。さらに、AMTリレーは、さまざまな使用状況とアクティビティの統計を収集する場合があります。これにより、レプリケーションポイントがEUの近くに移動し、ネットワーク全体のトラフィックが削減されます。したがって、ユニキャストサブスクライバを追加することによる線形コストを回避できます。ただし、ユニキャスト専用ネットワーク内の要求側の各エンドポイントには、依然としてユニキャスト複製が必要です。
AMT gateway: The gateway will reside on an endpoint; this could be any type of IP host, such as a Personal Computer (PC), mobile phone, Set-Top Box (STB), or appliances. The AMT gateway receives join and leave requests from the application via an Application Programming Interface (API). In this manner, the gateway allows the endpoint to conduct itself as a true multicast endpoint. The AMT gateway will encapsulate AMT messages into UDP packets and send them through a tunnel (across the unicast-only infrastructure) to the AMT relay.
AMTゲートウェイ：ゲートウェイはエンドポイントに常駐します。これは、パーソナルコンピュータ（PC）、携帯電話、セットトップボックス（STB）、アプライアンスなど、あらゆるタイプのIPホストです。 AMTゲートウェイは、アプリケーションプログラミングインターフェイス（API）を介してアプリケーションから参加要求と脱退要求を受信します。このようにして、ゲートウェイにより、エンドポイントはそれ自体を真のマルチキャストエンドポイントとして実行できます。 AMTゲートウェイは、AMTメッセージをUDPパケットにカプセル化し、（ユニキャストのみのインフラストラクチャ全体の）トンネルを介してAMTリレーに送信します。
The simplest AMT use case (Section 3.3) involves peering points that are not multicast enabled between two multicast-enabled ADs. An AMT tunnel is deployed between an AMT relay on the AD-1 side of the peering point and an AMT gateway on the AD-2 side of the peering point. One advantage of this arrangement is that the tunnel is established on an as-needed basis and need not be a provisioned element. The two ADs can coordinate and advertise special AMT relay anycast addresses with, and to, each other. Alternately, they may decide to simply provision relay addresses, though this would not be an optimal solution in terms of scalability.
最も単純なAMTの使用例（セクション3.3）には、マルチキャストが有効な2つのAD間でマルチキャストが有効になっていないピアリングポイントが含まれます。 AMTトンネルは、ピアリングポイントのAD-1側のAMTリレーとピアリングポイントのAD-2側のAMTゲートウェイの間に配置されます。この配置の1つの利点は、トンネルが必要に応じて確立され、プロビジョニングされた要素である必要がないことです。 2つのADは、特別なAMTリレーエニーキャストアドレスを調整し、互いにアドバタイズできます。または、単にリレーアドレスをプロビジョニングすることもできますが、これはスケーラビリティの点で最適なソリューションではありません。
Use Cases 3.4 and 3.5 describe AMT situations that are more complicated, as AD-2 is not multicast enabled in these two cases. For these cases, the EU device needs to be able to set up an AMT tunnel in the most optimal manner. There are many methods by which relay selection can be done, including the use of DNS-based queries and static lookup tables [RFC7450]. The choice of the method is implementation dependent and is up to the network operators. Comparison of various methods is out of scope for this document and is left for further study.
ユースケース3.4および3.5は、AD-2がこれら2つのケースでマルチキャスト対応ではないため、より複雑なAMT状況を説明しています。これらの場合、EUデバイスはAMTトンネルを最適な方法でセットアップできる必要があります。 DNSベースのクエリや静的ルックアップテーブルの使用[RFC7450]を含む、リレー選択を行うことができる多くの方法があります。方法の選択は実装に依存し、ネットワークオペレーター次第です。さまざまな方法の比較はこのドキュメントの範囲外であり、今後の検討に残します。
An illustrative example of a relay selection based on DNS queries as part of an anycast IP address process is described here for Use Cases 3.4 and 3.5 (Sections 3.4 and 3.5). Using an anycast IP address for AMT relays allows all AMT gateways to find the "closest" AMT relay -- the nearest edge of the multicast topology of the source. Note that this is strictly illustrative; the choice of the method is up to the network operators. The basic process is as follows:
エニーキャストIPアドレスプロセスの一部としてのDNSクエリに基づくリレー選択の例を、ユースケース3.4および3.5（セクション3.4および3.5）で説明します。 AMTリレーにエニーキャストIPアドレスを使用すると、すべてのAMTゲートウェイが「最も近い」AMTリレー（ソースのマルチキャストトポロジの最も近いエッジ）を見つけることができます。これは厳密に例示するものであることに注意してください。方法の選択はネットワーク事業者次第です。基本的なプロセスは次のとおりです。
o Appropriate metadata is obtained by the EU client application. The metadata contains instructions directing the EU client to an ordered list of particular destinations to seek the requested stream and, for multicast, specifies the source location and the group (or stream) ID in the form of (S,G) data. The "S" portion provides the URI (name or IP address) of the source of the multicast stream, and the "G" identifies the particular stream originated by that source. The metadata may also contain alternate delivery information such as the address of the unicast form of the content to be used -- for example, if the multicast stream becomes unavailable.
o 適切なメタデータは、EUクライアントアプリケーションによって取得されます。メタデータには、要求されたストリームをシークするために特定の宛先の順序付きリストにEUクライアントを誘導する指示が含まれており、マルチキャストの場合、ソースの場所とグループ（またはストリーム）IDを（S、G）データの形式で指定します。 「S」の部分は、マルチキャストストリームのソースのURI（名前またはIPアドレス）を提供し、「G」は、そのソースから発信された特定のストリームを識別します。メタデータには、使用するコンテンツのユニキャスト形式のアドレスなどの代替配信情報も含まれている場合があります。たとえば、マルチキャストストリームが利用できなくなった場合などです。
o Using the information from the metadata and, possibly, information provisioned directly in the EU client, a DNS query is initiated in order to connect the EU client / AMT gateway to an AMT relay.
o メタデータからの情報と、場合によってはEUクライアントで直接プロビジョニングされた情報を使用して、DNSクエリが開始され、EUクライアント/ AMTゲートウェイをAMTリレーに接続します。
o Query results are obtained and may return an anycast address or a specific unicast address of a relay. Multiple relays will typically exist. The anycast address is a routable "pseudo-address" shared among the relays that can gain multicast access to the source.
o クエリ結果が取得され、リレーのエニーキャストアドレスまたは特定のユニキャストアドレスが返される場合があります。通常、複数のリレーが存在します。エニーキャストアドレスは、ソースへのマルチキャストアクセスを取得できるリレー間で共有されるルーティング可能な「疑似アドレス」です。
o If a specific IP address unique to a relay was not obtained, the AMT gateway then sends a message (e.g., the discovery message) to the anycast address such that the network is making the routing choice of a particular relay, e.g., the relay that is closest to the EU. Details are outside the scope of this document. See [RFC4786].
o リレーに固有の特定のIPアドレスが取得されなかった場合、AMTゲートウェイはメッセージ（たとえば、ディスカバリーメッセージ）をエニーキャストアドレスに送信し、ネットワークが特定のリレー（たとえば、 EUに最も近い。詳細はこのドキュメントの範囲外です。 [RFC4786]を参照してください。
o The contacted AMT relay then returns its specific unicast IP address (after which the anycast address is no longer required). Variations may exist as well.
o 接続されたAMTリレーは、その特定のユニキャストIPアドレスを返します（その後、エニーキャストアドレスは不要になります）。バリエーションも存在する可能性があります。
o The AMT gateway uses that unicast IP address to initiate a three-way handshake with the AMT relay.
o AMTゲートウェイは、そのユニキャストIPアドレスを使用して、AMTリレーとの3ウェイハンドシェイクを開始します。
o The AMT gateway provides the (S,G) information to the AMT relay (embedded in AMT protocol messages).
o AMTゲートウェイは、（S、G）情報をAMTリレーに提供します（AMTプロトコルメッセージに埋め込まれています）。
o The AMT relay receives the (S,G) information and uses it to join the appropriate multicast stream, if it has not already subscribed to that stream.
o AMTリレーは（S、G）情報を受信し、それを使用して適切なマルチキャストストリームに参加します（まだそのストリームにサブスクライブしていない場合）。
o The AMT relay encapsulates the multicast stream into the tunnel between the relay and the gateway, providing the requested content to the EU.
o AMTリレーは、リレーとゲートウェイの間のトンネルにマルチキャストストリームをカプセル化し、要求されたコンテンツをEUに提供します。
Figure 6 shows an example of a broadcast peering point.
図6に、ブロードキャストピアリングポイントの例を示します。
AD-1a AD-1b
BR BR
| |
--+-+---------------+-+-- broadcast peering point LAN
| |
BR BR
AD-2a AD-2b
Figure 6: Broadcast Peering Point
図6：ブロードキャストピアリングポイント
A broadcast peering point is an L2 subnet connecting three or more ADs. It is common in IXPs and usually consists of Ethernet switch(es) operated by the IXP connecting to BRs operated by the ADs.
ブロードキャストピアリングポイントは、3つ以上のADを接続するL2サブネットです。これはIXPで一般的であり、通常は、ADによって運用されるBRに接続するIXPによって運用されるイーサネットスイッチで構成されます。
In an example setup domain, AD-2a peers with AD-1a and wants to receive IP multicast from it. Likewise, AD-2b peers with AD-1b and wants to receive IP multicast from it.
セットアップドメインの例では、AD-2aはAD-1aとピアリングしており、そこからIPマルチキャストを受信する必要があります。同様に、AD-2bはAD-1bとピアリングし、そこからIPマルチキャストを受信したいと考えています。
Assume that one or more IP multicast (S,G) traffic streams can be served by both AD-1a and AD-1b -- for example, because both AD-1a and AD-1b contact this content from the same content source.
たとえば、AD-1aとAD-1bの両方が同じコンテンツソースからこのコンテンツにアクセスするため、1つ以上のIPマルチキャスト（S、G）トラフィックストリームをAD-1aとAD-1bの両方で処理できると仮定します。
In this case, AD-2a and AD-2b can no longer control which upstream domain -- AD-1a or AD-1b -- will forward this (S,G) into the LAN. The AD-2a BR requests the (S,G) from the AD-1a BR, and the AD-2b BR requests the same (S,G) from the AD-1b BR. To avoid duplicate packets, an (S,G) can be forwarded by only one router onto the LAN; PIM-SM / PIM-SSM detects requests for duplicate transmissions and resolves them via the so-called "assert" protocol operation, which results in only one BR forwarding the traffic. Assume that this is the AD-1a BR. AD-2b will then receive unexpected multicast traffic from a provider with whom it does not have a mutual agreement for that traffic. Quality issues in EUs behind AD-2b caused by AD-1a will cause a lot of issues related to responsibility and troubleshooting.
この場合、AD-2aとAD-2bは、どのアップストリームドメイン（AD-1aまたはAD-1b）がこれ（S、G）をLANに転送するかを制御できなくなります。 AD-2a BRはAD-1a BRに（S、G）を要求し、AD-2b BRはAD-1b BRに同じ（S、G）を要求します。パケットの重複を回避するために、（S、G）は1つのルーターのみからLANに転送できます。 PIM-SM / PIM-SSMは重複した送信の要求を検出し、いわゆる「アサート」プロトコル操作を介してそれらを解決します。これにより、1つのBRだけがトラフィックを転送します。これがAD-1a BRであると想定します。 AD-2bは、そのトラフィックについて相互に合意していないプロバイダーから予期しないマルチキャストトラフィックを受信します。 AD-1aによって引き起こされたAD-2bの背後にあるEUの品質問題は、責任とトラブルシューティングに関連する多くの問題を引き起こします。
In light of these technical issues, we describe, via the following options, how IP multicast can be carried across broadcast peering point LANs:
これらの技術的な問題に照らして、ブロードキャストピアリングポイントLAN間でIPマルチキャストを伝送する方法について、次のオプションを使用して説明します。
1. IP multicast is tunneled across the LAN. Any of the GRE/AMT tunneling solutions mentioned in this document are applicable. This is the one case where a GRE tunnel between the upstream BR (e.g., AD-1a) and downstream BR (e.g., AD-2a) is specifically recommended, as opposed to tunneling across uBRs (which are not the actual BRs).
1. IPマルチキャストは、LANを介してトンネリングされます。このドキュメントで説明されているGRE / AMTトンネリングソリューションはすべて適用可能です。これは、uBR（実際のBRではない）を介したトンネリングとは対照的に、アップストリームBR（AD-1aなど）とダウンストリームBR（AD-2aなど）の間のGREトンネルが特に推奨される1つのケースです。
2. The LAN has only one upstream AD that is sourcing IP multicast, and native IP multicast is used. This is an efficient way to distribute the same IP multicast content to multiple downstream ADs. Misbehaving downstream BRs can still disrupt the delivery of IP multicast from the upstream BR to other downstream BRs; therefore, strict rules must be followed to prohibit such a case. The downstream BRs must ensure that they will always consider only the upstream BR as a source for multicast traffic: e.g., no BGP SAFI-2 peerings between the downstream ADs across the peering point LAN, so that the upstream BR is the only possible next hop reachable across this LAN. Also, routing policies can be configured to avoid falling back to using SAFI-1 (unicast) routes for IP multicast if unicast BGP peering is not limited in the same way.
2. LANには、IPマルチキャストを発信するアップストリームADが1つだけあり、ネイティブIPマルチキャストが使用されます。これは、同じIPマルチキャストコンテンツを複数のダウンストリームADに配信する効率的な方法です。ダウンストリームBRの誤動作は、アップストリームBRから他のダウンストリームBRへのIPマルチキャストの配信を中断させる可能性があります。したがって、そのような場合を禁止するために厳格なルールに従う必要があります。ダウンストリームBRは、常にアップストリームBRだけをマルチキャストトラフィックの送信元と見なすことを確認する必要があります。たとえば、ピアリングポイントLANを介したダウンストリームAD間のBGP SAFI-2ピアリングがないため、アップストリームBRが唯一の可能なネクストホップになります。このLANを介して到達可能。また、ユニキャストBGPピアリングが同じように制限されていない場合は、ルーティングポリシーを構成して、IPマルチキャストにSAFI-1（ユニキャスト）ルートを使用することを回避できます。
3. The LAN has multiple upstream ADs, but they are federated and agree on a consistent policy for IP multicast traffic across the LAN. One policy is that each possible source is only announced by one upstream BR. Another policy is that sources are redundantly announced (the problematic case mentioned in the example in Figure 6 above), but the upstream domains also provide mutual operational insight to help with troubleshooting (outside the scope of this document).
3. LANには複数のアップストリームADがありますが、それらは統合され、LAN全体のIPマルチキャストトラフィックの一貫したポリシーに同意します。 1つのポリシーは、可能な各ソースが1つのアップストリームBRによってのみアナウンスされることです。もう1つのポリシーは、ソースが重複してアナウンスされる（上記の図6の例で言及されている問題のあるケース）が、上流ドメインも相互運用の洞察を提供し、トラブルシューティングに役立ちます（このドキュメントの範囲外）。
"Back office" refers to the following:
「バックオフィス」とは以下を指します。
o Servers and content-management systems that support the delivery of applications via multicast and interactions between ADs.
o マルチキャストおよびAD間の相互作用を介したアプリケーションの配信をサポートするサーバーおよびコンテンツ管理システム。
o Functionality associated with logging, reporting, ordering, provisioning, maintenance, service assurance, settlement, etc.
o ロギング、レポート、注文、プロビジョニング、メンテナンス、サービス保証、決済などに関連する機能。
Resources for basic connectivity between ADs' providers need to be provisioned as follows:
ADのプロバイダー間の基本的な接続に関するリソースは、次のようにプロビジョニングする必要があります。
o Sufficient capacity must be provisioned to support multicast-based delivery across ADs.
o AD全体でマルチキャストベースの配信をサポートするには、十分な容量をプロビジョニングする必要があります。
o Sufficient capacity must be provisioned for connectivity between all supporting back offices of the ADs as appropriate. This includes activating proper security treatment for these back-office connections (gateways, firewalls, etc.) as appropriate.
o 必要に応じて、ADのすべてのサポートバックオフィス間の接続に十分な容量をプロビジョニングする必要があります。これには、これらのバックオフィス接続（ゲートウェイ、ファイアウォールなど）の適切なセキュリティ処理を適切にアクティブ化することが含まれます。
Provisioning aspects related to multicast-based inter-domain delivery are as follows.
マルチキャストベースのドメイン間配信に関連するプロビジョニングの側面は次のとおりです。
The ability to receive a requested application via multicast is triggered via receipt of the necessary metadata. Hence, this metadata must be provided to the EU regarding the multicast URL -- and unicast fallback if applicable. AD-2 must enable the delivery of this metadata to the EU and provision appropriate resources for this purpose.
要求されたアプリケーションをマルチキャストで受信する機能は、必要なメタデータを受信することでトリガーされます。したがって、このメタデータは、マルチキャストURLおよび該当する場合はユニキャストフォールバックに関してEUに提供する必要があります。 AD-2は、このメタデータをEUに配信できるようにし、この目的のために適切なリソースをプロビジョニングする必要があります。
It is assumed that native multicast functionality is available across many ISP backbones, peering points, and access networks. If, however, native multicast is not an option (Use Cases 3.4 and 3.5), then:
ネイティブマルチキャスト機能は、多くのISPバックボーン、ピアリングポイント、およびアクセスネットワークで利用可能であると想定されています。ただし、ネイティブマルチキャストがオプションでない場合（ユースケース3.4および3.5）、次のようになります。
o The EU must have a multicast client to use AMT multicast obtained from either (1) the application source (per agreement with AD-1) or (2) AD-1 or AD-2 (if delegated by the application source).
o EUには、（1）アプリケーションソース（AD-1との合意に基づく）または（2）AD-1またはAD-2（アプリケーションソースによって委任されている場合）から取得したAMTマルチキャストを使用するためのマルチキャストクライアントが必要です。
o If provided by AD-1 or AD-2, then the EU could be redirected to a client download site. (Note: This could be an application source site.) If provided by the application source, then this source would have to coordinate with AD-1 to ensure that the proper client is provided (assuming multiple possible clients).
o AD-1またはAD-2によって提供された場合、EUはクライアントダウンロードサイトにリダイレクトされます。 （注：これはアプリケーションソースサイトである可能性があります。）アプリケーションソースによって提供される場合、このソースはAD-1と調整して、適切なクライアントが提供されることを保証する必要があります（複数のクライアントが想定されます）。
o Where AMT gateways support different application sets, all AD-2 AMT relays need to be provisioned with all source and group addresses for streams it is allowed to join.
o AMTゲートウェイがさまざまなアプリケーションセットをサポートしている場合、すべてのAD-2 AMTリレーは、参加を許可されているストリームのすべてのソースアドレスとグループアドレスを使用してプロビジョニングする必要があります。
o DNS across each AD must be provisioned to enable a client gateway to locate the optimal AMT relay (i.e., longest multicast path and shortest unicast tunnel) with connectivity to the content's multicast source.
o クライアントゲートウェイがコンテンツのマルチキャストソースへの接続を備えた最適なAMTリレー（つまり、最長のマルチキャストパスと最短のユニキャストトンネル）を見つけられるように、各AD全体のDNSをプロビジョニングする必要があります。
Provisioning aspects related to operations and customer care are as follows.
運用とカスタマーケアに関連するプロビジョニングの側面は次のとおりです。
It is assumed that each AD provider will provision operations and customer care access to their own systems.
各ADプロバイダーは、独自のシステムへの運用とカスタマーケアアクセスをプロビジョニングすることを前提としています。
AD-1's operations and customer care functions must be able to see enough of what is happening in AD-2's network or in the service provided by AD-2 to verify their mutual goals and operations, e.g., to know how the EUs are being served. This can be done in two ways:
AD-1の運用およびカスタマーケア機能は、AD-2のネットワークまたはAD-2によって提供されるサービスで何が起こっているのかを十分に確認して、相互の目標と運用を検証する必要があります。 。これは2つの方法で実行できます。
o Automated interfaces are built between AD-1 and AD-2 such that operations and customer care continue using their own systems. This requires coordination between the two ADs, with appropriate provisioning of necessary resources.
o 自動化されたインターフェースはAD-1とAD-2の間に構築され、運用とカスタマーケアは引き続き独自のシステムを使用します。これには、2つのAD間の調整と、必要なリソースの適切なプロビジョニングが必要です。
o AD-1's operations and customer care personnel are provided direct access to AD-2's systems. In this scenario, additional provisioning in these systems will be needed to provide necessary access. The two ADs must agree on additional provisioning to support this option.
o AD-1の運用およびカスタマーケア担当者は、AD-2のシステムに直接アクセスできます。このシナリオでは、必要なアクセスを提供するために、これらのシステムに追加のプロビジョニングが必要になります。このオプションをサポートするには、2人のADが追加のプロビジョニングに同意する必要があります。
All interactions between pairs of ADs can be discovered and/or associated with the account(s) utilized for delivered applications. Supporting guidelines are as follows:
ADのペア間のすべての相互作用を検出したり、配信されたアプリケーションに使用されるアカウントに関連付けることができます。サポートガイドラインは次のとおりです。
o A unique identifier is recommended to designate each master account.
o 各マスターアカウントを指定するには、一意の識別子をお勧めします。
o AD-2 is expected to set up "accounts" (a logical facility generally protected by credentials such as login passwords) for use by AD-1. Multiple accounts, and multiple types or partitions of accounts, can apply, e.g., customer accounts, security accounts.
o AD-2は、AD-1が使用する「アカウント」（ログインパスワードなどの資格情報によって一般的に保護される論理機能）をセットアップすることが期待されています。複数のアカウント、およびアカウントの複数のタイプまたはパーティションを適用できます（例：顧客アカウント、セキュリティアカウント）。
The reason to specifically mention the need for AD-1 to initiate interactions with AD-2 (and use some account for that), as opposed to the opposite, is based on the recommended workflow initiated by customers (see Section 4.4): the customer contacts the content source, which is part of AD-1. Consequently, if AD-1 sees the need to escalate the issue to AD-2, it will interact with AD-2 using the aforementioned guidelines.
AD-1がAD-2とのやり取りを開始する（そしてそのためにいくつかのアカウントを使用する）必要性を明確に述べる理由は、反対ではなく、顧客が開始する推奨ワークフロー（セクション4.4を参照）に基づいています。 AD-1の一部であるコンテンツソースに接続します。したがって、AD-1が問題をAD-2にエスカレーションする必要があると判断した場合、AD-1は前述のガイドラインを使用してAD-2と対話します。
Successful delivery (in terms of user experience) of applications or content via multicast between pairs of interconnecting ADs can be improved through the ability to exchange appropriate logs for various workflows -- troubleshooting, accounting and billing, optimization of traffic and content transmission, optimization of content and application development, and so on.
相互接続するADのペア間でマルチキャストを介してアプリケーションまたはコンテンツを（ユーザーエクスペリエンスの観点から）正常に配信するには、トラブルシューティング、アカウンティングと請求、トラフィックの最適化、コンテンツの送信、コンテンツの送信、コンテンツやアプリケーション開発など。
Specifically, AD-1 take over primary responsibility for customer experience on behalf of the content source, with support from AD-2 as needed. The application/content owner is the only participant who has, and needs, full insight into the application level and can map the customer application experience to the network traffic flows -- which, with the help of AD-2 or logs from AD-2, it can then analyze and interpret.
具体的には、AD-1はコンテンツソースに代わってカスタマーエクスペリエンスの主な責任を引き継ぎ、必要に応じてAD-2からのサポートを受けます。アプリケーション/コンテンツの所有者は、アプリケーションレベルを完全に把握し、必要とする唯一の参加者であり、AD-2またはAD-2のログを使用して、顧客のアプリケーションエクスペリエンスをネットワークトラフィックフローにマッピングできます。 、それを分析して解釈することができます。
The main difference between unicast delivery and multicast delivery is that the content source can infer a lot more about downstream network problems from a unicast stream than from a multicast stream: the multicast stream is not per EU, except after the last replication, which is in most cases not in AD-1. Logs from the application, including the receiver side at the EU, can provide insight but cannot help to fully isolate network problems because of the IP multicast per-application operational state built across AD-1 and AD-2 (aka the (S,G) state and any other operational-state features, such as Diffserv QoS).
ユニキャスト配信とマルチキャスト配信の主な違いは、コンテンツソースがダウンストリームネットワークの問題について、マルチキャストストリームからよりもユニキャストストリームからより多くを推測できることです。マルチキャストストリームは、最後のレプリケーション後を除いて、EUごとではありません。ほとんどの場合、AD-1にはありません。 EUの受信側を含むアプリケーションからのログは、洞察を提供できますが、AD-1とAD-2（別名（S、G ）状態と、Diffserv QoSなどの他の動作状態機能）。
See Section 7 for more discussion regarding the privacy considerations of the model described here.
ここで説明するモデルのプライバシーに関する考慮事項については、セクション7を参照してください。
Different types of logs are known to help support operations in AD-1 when provided by AD-2. This could be done as part of AD-1/AD-2 contracts. Note that except for implied multicast-specific elements, the options listed here are not unique or novel for IP multicast, but they are more important for services novel to the operators than for operationally well-established services (such as unicast). We therefore detail them as follows:
AD-2によって提供される場合、AD-1での操作をサポートするのに役立つさまざまなタイプのログが知られています。これは、AD-1 / AD-2契約の一部として行うことができます。暗黙のマルチキャスト固有の要素を除いて、ここにリストされているオプションはIPマルチキャストに固有または新規ではありませんが、運用上十分に確立されたサービス（ユニキャストなど）よりも、オペレーターにとって新規のサービスにとって重要です。したがって、次のように詳細を示します。
o Usage information logs at an aggregate level.
o 集約レベルでの使用状況情報ログ。
o Usage failure instances at an aggregate level.
o 集計レベルでの使用失敗インスタンス。
o Grouped or sequenced application access: performance, behavior, and failure at an aggregate level to support potential application-provider-driven strategies. Examples of aggregate levels include grouped video clips, web pages, and software-download sets.
o グループ化またはシーケンス化されたアプリケーションアクセス：潜在的なアプリケーションプロバイダー主導の戦略をサポートする集約レベルでのパフォーマンス、動作、および障害。集約レベルの例には、グループ化されたビデオクリップ、Webページ、ソフトウェアダウンロードセットなどがあります。
o Security logs, aggregated or summarized according to agreement (with additional detail potentially provided during security events, by agreement).
o 合意に従って集計または要約されたセキュリティログ（追加の詳細は、合意によってセキュリティイベント中に提供される可能性があります）。
o Access logs (EU), when needed for troubleshooting.
o トラブルシューティングに必要な場合は、アクセスログ（EU）。
o Application logs ("What is the application doing?"), when needed for shared troubleshooting.
o 共有トラブルシューティングに必要な場合のアプリケーションログ（「アプリケーションは何をしていますか？」）
o Syslogs (network management), when needed for shared troubleshooting.
o Syslogs（ネットワーク管理）、共有トラブルシューティングに必要な場合。
The two ADs may supply additional security logs to each other, as agreed upon in contract(s). Examples include the following:
2つのADは、契約で合意されているように、追加のセキュリティログを互いに提供します。例は次のとおりです。
o Information related to general security-relevant activity, which may be of use from a protection or response perspective: types and counts of attacks detected, related source information, related target information, etc.
o 保護または応答の観点から役立つ可能性がある、一般的なセキュリティ関連のアクティビティに関連する情報：検出された攻撃のタイプと数、関連するソース情報、関連するターゲット情報など。
o Aggregated or summarized logs according to agreement (with additional detail potentially provided during security events, by agreement).
o 合意に従ってログを集計または要約します（合意により、セキュリティイベント中に追加の詳細が提供される可能性があります）。
"Service performance" refers to monitoring metrics related to multicast delivery via probes. The focus is on the service provided by AD-2 to AD-1 on behalf of all multicast application sources (metrics may be specified for SLA use or otherwise). Associated guidelines are as follows:
「サービスパフォーマンス」とは、プローブを介したマルチキャスト配信に関連するモニタリング指標を指します。焦点は、すべてのマルチキャストアプリケーションソースに代わってAD-2からAD-1に提供されるサービスにあります（メトリックはSLAの使用などのために指定できます）。関連するガイドラインは次のとおりです。
o Both ADs are expected to monitor, collect, and analyze service performance metrics for multicast applications. AD-2 provides relevant performance information to AD-1; this enables AD-1 to create an end-to-end performance view on behalf of the multicast application source.
o 両方のADは、マルチキャストアプリケーションのサービスパフォーマンスメトリックを監視、収集、および分析することが期待されています。 AD-2はAD-1に関連するパフォーマンス情報を提供します。これにより、AD-1は、マルチキャストアプリケーションソースに代わってエンドツーエンドのパフォーマンスビューを作成できます。
o Both ADs are expected to agree on the types of probes to be used to monitor multicast delivery performance. For example, AD-2 may permit AD-1's probes to be utilized in the AD-2 multicast service footprint. Alternately, AD-2 may deploy its own probes and relay performance information back to AD-1.
o 両方のADは、マルチキャスト配信パフォーマンスを監視するために使用されるプローブのタイプについて合意することが期待されています。たとえば、AD-2では、AD-1のプローブをAD-2マルチキャストサービスフットプリントで使用することができます。代わりに、AD-2は独自のプローブを展開し、パフォーマンス情報をAD-1に中継します。
"Service monitoring" generally refers to a service (as a whole) provided on behalf of a particular multicast application source provider. It thus involves complaints from EUs when service problems occur. EUs direct their complaints to the source provider; the source provider in turn submits these complaints to AD-1. The responsibility for service delivery lies with AD-1; as such, AD-1 will need to determine where the service problem is occurring -- in its own network or in AD-2. It is expected that each AD will have tools to monitor multicast service status in its own network.
「サービスモニタリング」は一般に、特定のマルチキャストアプリケーションソースプロバイダーに代わって提供されるサービス（全体として）を指します。したがって、サービスの問題が発生したときのEUからの苦情が含まれます。 EUは苦情をソースプロバイダーに送信します。ソースプロバイダーは、これらの苦情をAD-1に送信します。サービス提供の責任はAD-1にあります。そのため、AD-1は、サービスの問題が発生している場所（独自のネットワークまたはAD-2）を特定する必要があります。各ADには、独自のネットワークでマルチキャストサービスのステータスを監視するツールがあることが期待されます。
o Both ADs will determine how best to deploy multicast service monitoring tools. Typically, each AD will deploy its own set of monitoring tools, in which case both ADs are expected to inform each other when multicast delivery problems are detected.
o どちらのADも、マルチキャストサービス監視ツールを展開する最適な方法を決定します。通常、各ADは独自の監視ツールのセットを展開します。その場合、マルチキャスト配信の問題が検出されたときに、両方のADが互いに通知することが期待されます。
o AD-2 may experience some problems in its network. For example, for the AMT use cases (Sections 3.3, 3.4, and 3.5), one or more AMT relays may be experiencing difficulties. AD-2 may be able to fix the problem by rerouting the multicast streams via alternate AMT relays. If the fix is not successful and multicast service delivery degrades, then AD-2 needs to report the issue to AD-1.
o AD-2のネットワークで問題が発生する可能性があります。たとえば、AMTの使用例（セクション3.3、3.4、および3.5）では、1つ以上のAMTリレーで問題が発生している可能性があります。 AD-2は、代替AMTリレーを介してマルチキャストストリームを再ルーティングすることで問題を解決できる場合があります。修正が成功せず、マルチキャストサービス配信が低下した場合、AD-2は問題をAD-1に報告する必要があります。
o When a problem notification is received from a multicast application source, AD-1 determines whether the cause of the problem is within its own network or within AD-2. If the cause is within AD-2, then AD-1 supplies all necessary information to AD-2. Examples of supporting information include the following:
o マルチキャストアプリケーションソースから問題の通知を受信すると、AD-1は問題の原因が自身のネットワーク内にあるのか、AD-2内にあるのかを判断します。原因がAD-2内にある場合、AD-1は必要なすべての情報をAD-2に提供します。サポート情報の例には次のものがあります。
* Kind(s) of problem(s).
* 問題の種類）。
* Starting point and duration of problem(s).
* 問題の開始点と期間。
* Conditions in which one or more problems occur.
* 1つ以上の問題が発生する状態。
* IP address blocks of affected users.
* 影響を受けるユーザーのIPアドレスブロック。
* ISPs of affected users.
* 影響を受けるユーザーのISP。
* Type of access, e.g., mobile versus desktop.
* アクセスのタイプ（モバイルとデスクトップなど）。
* Network locations of affected EUs.
* 影響を受けるEUのネットワークの場所。
o Both ADs conduct some form of root-cause analysis for multicast service delivery problems. Examples of various factors for consideration include:
o 両方のADは、マルチキャストサービス配信の問題について、何らかの原因の分析を行います。考慮すべきさまざまな要因の例には、
* Verification that the service configuration matches the product features.
* サービス構成が製品機能と一致していることの確認。
* Correlation and consolidation of the various customer problems and resource troubles into a single root-service problem.
* さまざまな顧客の問題とリソースの問題を単一のルートサービスの問題に関連付け、統合します。
* Prioritization of currently open service problems, giving consideration to problem impacts, SLAs, etc.
* 現在影響を受けているサービスの問題の優先順位付け、問題の影響、SLAなどを考慮
* Conducting service tests, including tests performed once or a series of tests over a period of time.
* 一度に実行されたテストまたは一定期間にわたる一連のテストを含む、サービステストの実施。
* Analysis of test results.
* テスト結果の分析。
* Analysis of relevant network fault or performance data.
* 関連するネットワーク障害またはパフォーマンスデータの分析。
* Analysis of the problem information provided by the customer.
* お客様から提供された問題情報の分析。
o Once the cause of the problem has been determined and the problem has been fixed, both ADs need to work jointly to verify and validate the success of the fix.
o 問題の原因が特定され、問題が修正されたら、両方のADが連携して修正の成功を検証および検証する必要があります。
There are multiple options for instituting reliability architectures. Most are at the application level. Both ADs should work these options out per their contract or agreement and also with the multicast application source providers.
信頼性アーキテクチャを導入するための複数のオプションがあります。ほとんどはアプリケーションレベルです。両方のADは、契約または合意に従って、またマルチキャストアプリケーションソースプロバイダーとこれらのオプションを機能させる必要があります。
Network reliability can also be enhanced by the two ADs if they provision alternate delivery mechanisms via unicast means.
2つのADがユニキャスト手段を介して代替配信メカニズムをプロビジョニングする場合、ネットワークの信頼性も2つのADによって強化できます。
Application-level accounting needs to be handled differently in the application than in IP unicast, because the source side does not directly deliver packets to individual receivers. Instead, this needs to be signaled back by the receiver to the source.
アプリケーション側のアカウンティングは、アプリケーションではIPユニキャストとは異なる方法で処理する必要があります。これは、ソース側が個々の受信者にパケットを直接配信しないためです。代わりに、これはレシーバーからソースに信号で送られる必要があります。
For network transport diagnostics, AD-1 and AD-2 should have mechanisms in place to ensure proper accounting for the volume of bytes delivered through the peering point and, separately, the number of bytes delivered to EUs.
ネットワークトランスポート診断の場合、AD-1とAD-2には、ピアリングポイントを介して配信されるバイトの量と、個別にEUに配信されるバイト数を適切に計算するメカニズムが必要です。
Any service provider supporting multicast delivery of content should be able to collect diagnostics as part of multicast troubleshooting practices and resolve network issues accordingly. Issues may become apparent or identifiable through either (1) network monitoring functions or (2) problems reported by customers, as described in Section 4.4.
コンテンツのマルチキャスト配信をサポートするサービスプロバイダーは、マルチキャストトラブルシューティングの一環として診断を収集し、それに応じてネットワークの問題を解決できる必要があります。問題は、セクション4.4で説明されているように、（1）ネットワークモニタリング機能または（2）お客様から報告された問題のいずれかにより、明らかになるか、特定可能になる場合があります。
It is recommended that multicast diagnostics be performed, leveraging established operational practices such as those documented in [MDH-05]. However, given that inter-domain multicast creates a significant interdependence of proper networking functionality between providers, there exists a need for providers to be able to signal (or otherwise alert) each other if there are any issues noted by either one.
[MDH-05]に記載されているような確立された運用慣行を活用して、マルチキャスト診断を実行することをお勧めします。ただし、ドメイン間マルチキャストにより、プロバイダー間の適切なネットワーク機能の相互依存性が大幅に増加するため、プロバイダーのいずれかに問題が発生した場合、プロバイダーは互いに信号を送る（または警告する）ことができる必要があります。
For troubleshooting purposes, service providers may also wish to allow limited read-only administrative access to their routers to their AD peers. Access to active troubleshooting tools -- especially [Traceroute] and the tools discussed in [Mtrace-v2] -- is of specific interest.
トラブルシューティングの目的で、サービスプロバイダーは、ADピアへのルーターへの制限付きの読み取り専用管理アクセスを許可することもできます。アクティブなトラブルシューティングツール、特に[Traceroute]と[Mtrace-v2]で説明されているツールへのアクセスは、特に重要です。
Another option is to include this functionality in the IP multicast receiver application on the EU device and allow these diagnostics to be remotely used by support operations. Note, though, that AMT does not allow the passing of traceroute or mtrace requests; therefore, troubleshooting in the presence of AMT does not work as well end to end as it can with native (or even GRE-encapsulated) IP multicast, especially with regard to traceroute and mtrace. Instead, troubleshooting directly on the actual network devices is then more likely necessary.
もう1つのオプションは、EUデバイスのIPマルチキャストレシーバーアプリケーションにこの機能を含め、これらの診断をサポートオペレーションでリモートで使用できるようにすることです。ただし、AMTではtracerouteまたはmtrace要求を渡すことができないことに注意してください。したがって、AMTが存在する場合のトラブルシューティングは、特にtracerouteとmtraceに関して、ネイティブ（またはGREカプセル化）のIPマルチキャストの場合と同様に、エンドツーエンドで機能しません。代わりに、実際のネットワークデバイスで直接トラブルシューティングを行う必要が生じる可能性が高くなります。
The specifics of notifications and alerts are beyond the scope of this document, but general guidelines are similar to those described in Section 4.4. Some general communications issues are as follows.
通知とアラートの詳細はこのドキュメントの範囲外ですが、一般的なガイドラインはセクション4.4で説明されているものと同様です。いくつかの一般的な通信の問題は次のとおりです。
o Appropriate communications channels will be established between the customer service and operations groups from both ADs to facilitate information-sharing related to diagnostic troubleshooting.
o 診断トラブルシューティングに関連する情報共有を容易にするために、両方のADのカスタマーサービスグループと運用グループの間に適切な通信チャネルが確立されます。
o A default resolution period may be considered to resolve open issues. Alternately, mutually acceptable resolution periods could be established, depending on the severity of the identified trouble.
o デフォルトの解決期間は、未解決の問題を解決するために考慮される場合があります。あるいは、特定された問題の重大度に応じて、相互に受け入れ可能な解決期間を設定することもできます。
Reliable IP multicast operations require some basic protection against DoS (Denial of Service) attacks.
信頼性の高いIPマルチキャスト操作には、DoS（サービス拒否）攻撃に対する基本的な保護が必要です。
SSM IP multicast is self-protecting against attacks from illicit sources; such traffic will not be forwarded beyond the first-hop router, because that would require (S,G) membership reports from the receiver. Only valid traffic from sources will be forwarded, because RPF ("Reverse Path Forwarding") is part of the protocols. One can say that protection against spoofed source traffic performed in the style of [BCP38] is therefore built into PIM-SM / PIM-SSM.
SSM IPマルチキャストは、不正なソースからの攻撃に対して自己保護します。このようなトラフィックは、最初のホップのルーターを越えて転送されません。これは、レシーバーからの（S、G）メンバーシップレポートが必要になるためです。 RPF（ "Reverse Path Forwarding"）はプロトコルの一部であるため、ソースからの有効なトラフィックのみが転送されます。したがって、[BCP38]のスタイルで実行されるスプーフィングされたソーストラフィックに対する保護は、PIM-SM / PIM-SSMに組み込まれていると言えます。
Receivers can attack SSM IP multicast by originating such (S,G) membership reports. This can result in a DoS attack against state through the creation of a large number of (S,G) states that create high control-plane load or even inhibit the later creation of a valid (S,G). In conjunction with collaborating illicit sources, it can also result in the forwarding of traffic from illicit sources.
受信者は、このような（S、G）メンバーシップレポートを作成することにより、SSM IPマルチキャストを攻撃できます。これにより、多数の（S、G）状態が作成されて状態に対するDoS攻撃が発生し、高いコントロールプレーン負荷が発生したり、後で有効な（S、G）が作成されなくなったりする可能性があります。不正なソースとの連携により、不正なソースからのトラフィックが転送される可能性もあります。
Today, these types of attacks are usually mitigated by explicitly defining the set of permissible (S,G) on, for example, the last-hop routers in replicating IP multicast to EUs (e.g., via (S,G) access control lists applied to IGMP/MLD membership state creation). Each AD (say, "ADi") is expected to know what sources located in ADi are permitted to send and what their valid (S,G)s are. ADi can therefore also filter invalid (S,G)s for any "S" located inside ADi, but not sources located in another AD.
今日、これらのタイプの攻撃は通常、たとえば、適用される（S、G）アクセス制御リストを介してEUにIPマルチキャストを複製する際のラストホップルータなどで、許可される（S、G）のセットを明示的に定義することで軽減されます。 IGMP / MLDメンバーシップ状態の作成）。各AD（たとえば、「ADi」）は、ADiにあるソースが送信を許可され、それらの有効な（S、G）が何かを知っていることが期待されます。したがって、ADiは、ADi内にある「S」の無効な（S、G）もフィルタリングできますが、別のADにあるソースはフィルタリングできません。
In the peering case, without further information, AD-2 is not aware of the set of valid (S,G) from AD-1, so this set needs to be communicated via operational procedures from AD-1 to AD-2 to provide protection against this type of DoS attack. Future work could signal this information in an automated way: BGP extensions, DNS resource records, or backend automation between AD-1 and AD-2. Backend automation is, in the short term, the most viable solution: unlike BGP extensions or DNS resource records, backend automation does not require router software extensions. Observation of traffic flowing via (S,G) state could also be used to automate the recognition of invalid (S,G) state created by receivers in the absence of explicit information from AD-1.
ピアリングの場合、詳細情報がないと、AD-2はAD-1からの有効な（S、G）のセットを認識しません。そのため、このセットは、AD-1からAD-2への操作手順を介して通信する必要があります。このタイプのDoS攻撃に対する保護。今後の作業では、BGP拡張、DNSリソースレコード、またはAD-1とAD-2の間のバックエンド自動化などの自動化された方法でこの情報を伝えることができます。バックエンド自動化は、短期的には、最も実行可能なソリューションです。BGP拡張やDNSリソースレコードとは異なり、バックエンド自動化はルーターソフトウェア拡張を必要としません。 （S、G）状態を介して流れるトラフィックの観察は、AD-1からの明示的な情報がない場合に受信者によって作成された無効な（S、G）状態の認識を自動化するためにも使用できます。
The second type of DoS attack through (S,G) membership reports exists when the attacking receiver creates too much valid (S,G) state and the traffic carried by these (S,G)s congests bandwidth on links shared with other EUs. Consider the uplink to a last-hop router connecting to 100 EUs. If one EU joins to more multicast content than what fits into this link, then this would also impact the quality of the same content for the other 99 EUs. If traffic is not rate adaptive, the effects are even worse.
（S、G）メンバーシップレポートを介した2番目のタイプのDoS攻撃は、攻撃している受信者が有効な（S、G）状態を作成しすぎ、これらの（S、G）によって伝送されるトラフィックが他のEUと共有されているリンクの帯域幅を輻輳させている場合に発生します。 100 EUに接続するラストホップルータへのアップリンクを検討してください。 1つのEUがこのリンクに適合するものよりも多くのマルチキャストコンテンツに参加すると、他の99のEUの同じコンテンツの品質にも影響します。トラフィックがレートアダプティブでない場合、効果はさらに悪化します。
The mitigation technique is the same as what is often employed for unicast: policing of the per-EU total amount of traffic. Unlike unicast, though, this cannot be done anywhere along the path (e.g., on an arbitrary bottleneck link); it has to happen at the point of last replication to the different EU. Simple solutions such as limiting the maximum number of joined (S,G)s per EU are readily available; solutions that take consumed bandwidth into account are available as vendor-specific features in routers. Note that this is primarily a non-peering issue in AD-2; it only becomes a peering issue if the peering link itself is not big enough to carry all possible content from AD-1 or, as in Use Case 3.4, when the AMT relay in AD-1 is that last replication point.
軽減手法は、ユニキャストでよく使用される手法と同じです。つまり、EUごとの総トラフィック量のポリシングです。ただし、ユニキャストとは異なり、これはパスに沿った任意の場所（たとえば、任意のボトルネックリンク）では実行できません。異なるEUへの最後の複製の時点で発生する必要があります。 EUあたりの結合（S、G）の最大数を制限するなどの簡単なソリューションがすぐに利用できます。消費帯域幅を考慮したソリューションは、ルーターのベンダー固有の機能として利用できます。これは主にAD-2のピアリング以外の問題であることに注意してください。ピアリングリンク自体がAD-1からすべての可能なコンテンツを伝送するのに十分な大きさでない場合、またはユースケース3.4のように、AD-1のAMTリレーがその最後のレプリケーションポイントである場合にのみ、ピアリングの問題になります。
Limiting the amount of (S,G) state per EU is also a good first measure to prohibit too much undesired "empty" state from being built (state not carrying traffic), but it would not suffice in the case of DDoS attacks, e.g., viruses that impact a large number of EU devices.
EUあたりの（S、G）状態の量を制限することも、不要な「空」の状態の作成（トラフィックを運ばない状態）を禁止するための優れた最初の手段ですが、DDoS攻撃の場合は十分ではありません。 、多数のEUデバイスに影響を与えるウイルス。
Content confidentiality, DRM (Digital Rights Management), authentication, and authorization are optional, based on the content delivered. For content that is "FTA" (Free To Air), the following considerations can be ignored, and content can be sent unencrypted and without EU authentication and authorization. Note, though, that the mechanisms described here may also be desirable for the application source to better track users even if the content itself would not require it.
コンテンツの機密性、DRM（Digital Rights Management）、認証、および許可は、配信されたコンテンツに基づいてオプションです。 「FTA」（Free To Air）のコンテンツの場合、以下の考慮事項は無視でき、コンテンツは暗号化されずに、EU認証および承認なしで送信できます。ただし、ここで説明するメカニズムは、コンテンツ自体が必要としない場合でも、アプリケーションソースがユーザーをより適切に追跡するためにも望ましい場合があります。
For inter-domain content, there are at least two models for content confidentiality, including (1) DRM authentication and authorization and (2) EU authentication and authorization:
ドメイン間コンテンツの場合、（1）DRM認証および承認と（2）EU認証および承認を含む、コンテンツの機密性に関する少なくとも2つのモデルがあります。
o In the classical (IP)TV model, responsibility is per domain, and content is and can be passed on unencrypted. AD-1 delivers content to AD-2; AD-2 can further process the content, including features like ad insertion, and AD-2 is the sole point of contact regarding the contact for its EUs. In this document, we do not consider this case because it typically involves service aspects operated by AD-2 that are higher than the network layer; this document focuses on the network-layer AD-1/AD-2 peering case but not the application-layer peering case. Nevertheless, this model can be derived through additional work beyond what is described here.
o 従来の（IP）TVモデルでは、責任はドメインごとにあり、コンテンツは暗号化されずに渡されます。 AD-1はAD-2にコンテンツを配信します。 AD-2は、広告挿入などの機能を含むコンテンツをさらに処理できます。AD-2は、EUの連絡先に関する唯一の連絡先です。このドキュメントでは、このケースについては考慮していません。通常、ネットワークレイヤーより上位のAD-2によって運用されるサービスの側面が関係しているためです。このドキュメントでは、ネットワーク層のAD-1 / AD-2ピアリングの事例に焦点を当てていますが、アプリケーション層のピアリングの事例には焦点を当てていません。それにもかかわらず、このモデルは、ここで説明されているもの以外の追加の作業を通じて導出できます。
o The other model is the one in which content confidentiality, DRM, EU authentication, and EU authorization are end to end: responsibilities of the multicast application source provider and receiver application. This is the model assumed here. It is also the model used in Internet "Over the Top" (OTT) video delivery. Below, we discuss the threats incurred in this model due to the use of IP multicast in AD-1 or AD-2 and across the peering point.
o もう1つのモデルは、コンテンツの機密性、DRM、EU認証、およびEU承認がエンドツーエンドであるモデルです。マルチキャストアプリケーションのソースプロバイダーとレシーバーアプリケーションの責任です。これは、ここで想定されているモデルです。また、インターネットの「Over the Top」（OTT）ビデオ配信で使用されるモデルでもあります。以下では、AD-1またはAD-2およびピアリングポイント全体でIPマルチキャストを使用することにより、このモデルで発生する脅威について説明します。
End-to-end encryption enables end-to-end EU authentication and authorization: the EU may be able to join (via IGMP/MLD) and receive the content, but it can only decrypt it when it receives the decryption key from the content source in AD-1. The key is the authorization. Keeping that key to itself and prohibiting playout of the decrypted content to non-copy-protected interfaces are typical DRM features in that receiver application or EU device operating system.
エンドツーエンドの暗号化により、エンドツーエンドのEU認証と承認が可能になります。EUは（IGMP / MLD経由で）参加してコンテンツを受信できますが、コンテンツから復号化キーを受信したときにのみ復号化できます。 AD-1のソース。キーは承認です。それ自体のキーを保持し、コピー保護されていないインターフェイスへの復号化されたコンテンツの再生を禁止することは、そのレシーバーアプリケーションまたはEUデバイスオペレーティングシステムの典型的なDRM機能です。
End-to-end encryption is continuously attacked. Keys may be subject to brute-force attacks so that content can potentially be decrypted later, or keys are extracted from the EU application/device and shared with other unauthenticated receivers. One important class of content is where the value is in live consumption, such as sports or other event (e.g., concert) streaming. Extraction of keying material from compromised authenticated EUs and sharing with unauthenticated EUs are not sufficient. It is also necessary for those unauthenticated EUs to get a streaming copy of the content itself. In unicast streaming, they cannot get such a copy from the content source (because they cannot authenticate), and, because of asymmetric bandwidths, it is often impossible to get the content from compromised EUs to a large number of unauthenticated EUs. EUs behind classical "16 Mbps down, 1 Mbps up" ADSL links are the best example. With increasing broadband access speeds, unicast peer-to-peer copying of content becomes easier, but it likely will always be easily detectable by the ADs because of its traffic patterns and volume.
エンドツーエンドの暗号化が継続的に攻撃されています。キーはブルートフォース攻撃を受ける可能性があるため、コンテンツを後で解読できる可能性があります。または、キーがEUアプリケーション/デバイスから抽出され、他の認証されていない受信者と共有されます。コンテンツの重要なクラスの1つは、スポーツやその他のイベント（コンサートなど）のストリーミングなど、生の消費に価値がある場所です。侵害された認証済みEUからキー情報を抽出し、認証されていないEUと共有するだけでは不十分です。また、認証されていないEUがコンテンツ自体のストリーミングコピーを取得することも必要です。ユニキャストストリーミングでは、コンテンツソースからこのようなコピーを取得できません（認証できないため）。また、帯域幅が非対称であるため、侵害されたEUから認証されていない多数のEUにコンテンツを取得することはしばしば不可能です。古典的な「16 Mbpsダウン、1 Mbpsアップ」ADSLリンクの背後にあるEUは、最も良い例です。ブロードバンドアクセス速度が上がると、コンテンツのユニキャストピアツーピアコピーが容易になりますが、そのトラフィックパターンとボリュームにより、ADは常に簡単に検出できるようになります。
When IP multicast is being used without additional security, AD-2 is not aware of which EU is authenticated for which content. Any unauthenticated EU in AD-2 could therefore get a copy of the encrypted content without triggering suspicion on the part of AD-2 or AD-1 and then either (1) live-decode it, in the presence of the compromised authenticated EU and key-sharing or (2) decrypt it later, in the presence of federated brute-force key-cracking.
追加のセキュリティなしでIPマルチキャストが使用されている場合、AD-2はどのEUがどのコンテンツに対して認証されているかを認識しません。したがって、AD-2の認証されていないEUは、AD-2またはAD-1の側で疑いを引き起こさずに暗号化されたコンテンツのコピーを取得し、（1）侵害された認証済みEUの存在下でそれをライブデコードすることができます。キー共有、または（2）連合ブルートフォースキークラッキングが存在する場合、後でそれを復号化します。
To mitigate this issue, the last replication point that is creating (S,G) copies to EUs would need to permit those copies only after authentication of the EUs. This would establish the same authenticated "EU only" copy that is used in unicast.
この問題を軽減するには、EUへの（S、G）コピーを作成している最後のレプリケーションポイントが、EUの認証後にのみそれらのコピーを許可する必要があります。これにより、ユニキャストで使用されるのと同じ認証済み「EUのみ」のコピーが確立されます。
Schemes for per-EU IP multicast authentication/authorization (and, as a result, non-delivery or copying of per-content IP multicast traffic) have been built in the past and are deployed in service providers for intra-domain IPTV services, but no standards exist for this. For example, there is no standardized RADIUS attribute for authenticating the IGMP/MLD filter set, but such implementations exist. The authors of this document are specifically also not aware of schemes where the same authentication credentials used to get the encryption key from the content source could also be used to authenticate and authorize the network-layer IP multicast replication for the content. Such schemes are technically not difficult to build and would avoid creating and maintaining a separate network traffic-forwarding authentication/authorization scheme decoupled from the end-to-end authentication/authorization system of the application.
EU単位のIPマルチキャスト認証/許可のスキーム（およびその結果、コンテンツ単位のIPマルチキャストトラフィックの非配信またはコピー）は過去に構築されており、ドメイン内IPTVサービスのサービスプロバイダーに導入されていますが、このための基準はありません。たとえば、IGMP / MLDフィルターセットを認証するための標準化されたRADIUS属性はありませんが、そのような実装は存在します。このドキュメントの作成者は、コンテンツソースから暗号化キーを取得するために使用されたものと同じ認証資格情報を使用して、コンテンツのネットワーク層IPマルチキャストレプリケーションを認証および承認できるスキームについても特に認識していません。このようなスキームを構築することは技術的に難しくなく、アプリケーションのエンドツーエンドの認証/承認システムから切り離された個別のネットワークトラフィック転送認証/承認スキームの作成と維持を回避します。
If delivery of such high-value content in conjunction with the peering described here is desired, the short-term recommendations are for sources to clearly isolate the source and group addresses used for different content bundles, communicate those (S,G) patterns from AD-1 to AD-2, and let AD-2 leverage existing per-EU authentication/ authorization mechanisms in network devices to establish filters for (S,G) sets to each EU.
このような高価値のコンテンツをここで説明するピアリングと組み合わせて配信する必要がある場合、短期的な推奨事項は、ソースがさまざまなコンテンツバンドルに使用されるソースとグループのアドレスを明確に分離し、それらの（S、G）パターンをADから伝えることです-1からAD-2まで、AD-2がネットワークデバイスの既存のEU単位の認証/承認メカニズムを利用して、各EUへの（S、G）セットのフィルターを確立できるようにします。
Encryption at peering points for multicast delivery may be used per agreement between AD-1 and AD-2.
マルチキャスト配信のピアリングポイントでの暗号化は、AD-1とAD-2の間の合意に従って使用できます。
In the case of a private peering link, IP multicast does not have attack vectors on a peering link different from those of IP unicast, but the content owner may have defined strict constraints against unauthenticated copying of even the end-to-end encrypted content; in this case, AD-1 and AD-2 can agree on additional transport encryption across that peering link. In the case of a broadcast peering connection (e.g., IXP), transport encryption is again the easiest way to prohibit unauthenticated copies by other ADs on the same peering point.
プライベートピアリングリンクの場合、IPマルチキャストは、IPユニキャストのピアリングリンクとは異なる攻撃ベクトルを持ちませんが、コンテンツ所有者は、エンドツーエンドの暗号化されたコンテンツの認証されていないコピーに対しても厳しい制約を定義している可能性があります。この場合、AD-1とAD-2は、そのピアリングリンクでの追加のトランスポート暗号化について合意できます。ブロードキャストピアリング接続（例：IXP）の場合、トランスポート暗号化は、同じピアリングポイント上の他のADによる認証されていないコピーを禁止する最も簡単な方法です。
If peering is across a tunnel that spans intermittent transit ADs (not discussed in detail in this document), then encryption of that tunnel traffic is recommended. It not only prohibits possible "leakage" of content but also protects the information regarding what content is being consumed in AD-2 (aggregated privacy protection).
ピアリングが断続的なトランジットAD（このドキュメントでは詳細に説明されていません）にまたがるトンネルを介している場合は、そのトンネルトラフィックの暗号化をお勧めします。コンテンツの「漏えい」の可能性を禁止するだけでなく、AD-2で消費されているコンテンツに関する情報も保護します（集約プライバシー保護）。
See Section 6.4 for reasons why the peering point may also need to be encrypted for operational reasons.
操作上の理由でピアリングポイントも暗号化する必要がある理由については、セクション6.4を参照してください。
Section 4.3.3 discusses the exchange of log information, and Section 7 discusses the exchange of program information. All these operational pieces of data should by default be exchanged via authenticated and encrypted peer-to-peer communication protocols between AD-1 and AD-2 so that only the intended recipients in the peers' AD have access to it. Even exposure of the least sensitive information to third parties opens up attack vectors. Putting valid (S,G) information, for example, into DNS (as opposed to passing it via secured channels from AD-1 to AD-2) to allow easier filtering of invalid (S,G) information would also allow attackers to more easily identify valid (S,G) information and change their attack vector.
セクション4.3.3ではログ情報の交換について説明し、セクション7ではプログラム情報の交換について説明します。これらのすべての運用データは、デフォルトで、AD-1とAD-2の間で認証および暗号化されたピアツーピア通信プロトコルを介して交換されるため、ピアのAD内の意図された受信者のみがアクセスできます。最も機密性の低い情報が第三者にさらされることでさえ、攻撃ベクトルが開かれます。有効な（S、G）情報をDNSに（AD-1からAD-2へのセキュリティで保護されたチャネル経由で渡すのではなく）入れて、無効な（S、G）情報のフィルタリングを容易にすることで、攻撃者は有効な（S、G）情報を簡単に識別し、攻撃ベクトルを変更します。
From the perspective of the ADs, security is most critical for log information, as it provides operational insight into the originating AD but also contains sensitive user data.
ADの観点から見ると、セキュリティはログ情報にとって最も重要です。セキュリティには、元のADに対する運用上の洞察が提供されるだけでなく、機密のユーザーデータも含まれるためです。
Sensitive user data exported from AD-2 to AD-1 as part of logs could be as much as the equivalent of 5-tuple unicast traffic flow accounting (but not more, e.g., no application-level information). As mentioned in Section 7, in unicast, AD-1 could capture these traffic statistics itself because this is all about traffic flows (originated by AD-1) to EU receivers in AD-2, and operationally passing it from AD-2 to AD-1 may be necessary when IP multicast is used because of the replication taking place in AD-2.
ログの一部としてAD-2からAD-1にエクスポートされた機密性の高いユーザーデータは、5タプルのユニキャストトラフィックフローアカウンティングに相当するものです（ただし、アプリケーションレベルの情報がないなど）。セクション7で述べたように、ユニキャストでは、AD-2のEUレシーバーへのトラフィックフロー（AD-1によって発信されたもの）とAD-2からADに運用的に渡すことがすべてであるため、AD-1はこれらのトラフィック統計自体をキャプチャできます。 AD-2で複製が行われるため、IPマルチキャストを使用する場合は-1が必要になる場合があります。
Nevertheless, passing such traffic statistics inside AD-1 from a capturing router to a backend system is likely less subject to third-party attacks than passing it "inter-domain" from AD-2 to AD-1, so more diligence needs to be applied to secure it.
それにもかかわらず、キャプチャルーターからバックエンドシステムにAD-1内でこのようなトラフィック統計情報を渡すことは、AD-2からAD-1に「ドメイン間」で渡すよりもサードパーティの攻撃を受けにくいため、より注意深く行う必要があります。それを保護するために適用されました。
If any protocols used for the operational exchange of information are not easily secured at the transport layer or higher (because of the use of legacy products or protocols in the network), then AD-1 and AD-2 can also consider ensuring that all operational data exchanges go across the same peering point as the traffic and use network-layer encryption of the peering point (as discussed previously) to protect it.
運用上の情報交換に使用されるプロトコルがトランスポート層以上で容易に保護されない場合（ネットワークでレガシー製品またはプロトコルを使用しているため）、AD-1およびAD-2は、すべての運用が可能であることを確認することも検討できます。データ交換は、トラフィックと同じピアリングポイントを通過し、ピアリングポイントのネットワーク層暗号化を使用して（前述のように）保護します。
End-to-end authentication and authorization of EUs may involve some kind of token authentication and are done at the application layer, independently of the two ADs. If there are problems related to the failure of token authentication when EUs are supported by AD-2, then some means of validating proper operation of the token authentication process (e.g., validating that backend servers querying the multicast application source provider's token authentication server are communicating properly) should be considered. Implementation details are beyond the scope of this document.
EUのエンドツーエンドの認証と承認には、ある種のトークン認証が含まれる場合があり、2つのADとは関係なく、アプリケーション層で行われます。 EUがAD-2でサポートされているときにトークン認証の失敗に関連する問題がある場合は、トークン認証プロセスの適切な操作を検証するいくつかの手段（たとえば、マルチキャストアプリケーションソースプロバイダーのトークン認証サーバーにクエリを送信しているバックエンドサーバーが通信していることの検証）正しく）検討する必要があります。実装の詳細は、このドキュメントの範囲を超えています。
In the event of a security breach, the two ADs are expected to have a mitigation plan for shutting down the peering point and directing multicast traffic over alternative peering points. It is also expected that appropriate information will be shared for the purpose of securing the identified breach.
セキュリティ違反が発生した場合、2つのADには、ピアリングポイントをシャットダウンし、マルチキャストトラフィックを代替のピアリングポイント経由で転送するための緩和策があることが期待されます。また、特定された違反を保護するために、適切な情報が共有されることも期待されます。
The described flow of information about content and EUs as described in this document aims to maintain privacy:
このドキュメントで説明されているコンテンツとEUに関する説明されている情報の流れは、プライバシーを維持することを目的としています。
AD-1 is operating on behalf of (or owns) the content source and is therefore part of the content-consumption relationship with the EU. The privacy considerations between the EU and AD-1 are therefore generally the same (with one exception; see below) as they would be if no IP multicast was used, especially because end-to-end encryption can and should be used for any privacy-conscious content.
AD-1はコンテンツソースの代理として（または所有して）いるため、EUとのコンテンツ消費関係の一部です。したがって、EUとAD-1の間のプライバシーに関する考慮事項は、IPマルチキャストが使用されなかった場合と同じです（特に、エンドツーエンドの暗号化はすべてのプライバシーに使用でき、使用する必要があるため）を意識したコンテンツ。
Information related to inter-domain multicast transport service is provided to AD-1 by the AD-2 operators. AD-2 is not required to gain additional insight into the user's behavior through this process other than what it would already have without service collaboration with AD-1, unless AD-1 and AD-2 agree on it and get approval from the EU.
ドメイン間マルチキャストトランスポートサービスに関連する情報は、AD-2オペレーターによってAD-1に提供されます。 AD-1とAD-2が同意し、EUから承認を得ない限り、AD-2は、AD-1とのサービスコラボレーションがない場合とは異なり、このプロセスを通じてユーザーの行動をさらに洞察する必要はありません。
For example, if it is deemed beneficial for the EU to get support directly from AD-2, then it would generally be necessary for AD-2 to be aware of the mapping between content and network (S,G) state so that AD-2 knows which (S,G) to troubleshoot when the EU complains about problems with specific content. The degree to which this dissemination is done by AD-1 explicitly to meet privacy expectations of EUs is typically easy to assess by AD-1. Two simple examples are as follows:
たとえば、EUがAD-2から直接サポートを受けることが有益であると見なされる場合、AD-2がコンテンツとネットワーク（S、G）状態の間のマッピングを認識して、AD- 2は、EUが特定のコンテンツの問題について不平を言ったときにトラブルシューティングする（S、G）を知っています。この普及がAD-1によって明示的に行われ、EUのプライバシーの期待に応えられる程度は、通常、AD-1によって簡単に評価できます。 2つの簡単な例を次に示します。
o For a sports content bundle, every EU will happily click on the "I approve that the content program information is shared with your service provider" button, to ensure best service reliability, because service-conscious AD-2 would likely also try to ensure that high-value content, such as the (S,G) for the Super Bowl, would be the first to receive care in the case of network issues.
o スポーツコンテンツバンドルの場合、すべてのEUが「コンテンツプログラム情報がサービスプロバイダーと共有されることを承認します」ボタンを喜んでクリックし、最高のサービス信頼性を確保します。スーパーボウルの（S、G）などの価値の高いコンテンツは、ネットワークの問題が発生した場合に最初に対応します。
o If the content in question was content for which the EU expected more privacy, the EU should prefer a content bundle that included this content in a large variety of other content, have all content end-to-end encrypted, and not share programming information with AD-2, to maximize privacy. Nevertheless, the privacy of the EU against AD-2 observing traffic would still be lower than in the equivalent setup using unicast, because in unicast, AD-2 could not correlate which EUs are watching the same content and use that to deduce the content. Note that even the setup in Section 3.4, where AD-2 is not involved in IP multicast at all, does not provide privacy against this level of analysis by AD-2, because there is no transport-layer encryption in AMT; therefore, AD-2 can correlate by on-path traffic analysis who is consuming the same content from an AMT relay from both the (S,G) join messages in AMT and the identical content segments (that were replicated at the AMT relay).
o問題のコンテンツが、EUがよりプライバシーを期待するコンテンツである場合、EUは、このコンテンツを他のさまざまなコンテンツに含め、すべてのコンテンツをエンドツーエンドで暗号化し、プログラミング情報を共有しないコンテンツバンドルを優先する必要があります。 AD-2では、プライバシーを最大化します。それでも、AD-2はトラフィックを監視するAD-2に対するEUのプライバシーは、ユニキャストを使用する同等の設定よりも低くなります。これは、ユニキャストでは、AD-2がどのEUが同じコンテンツを監視しているかを関連付け、それを使用してコンテンツを推定できないためです。 AD-2がIPマルチキャストにまったく関与していないセクション3.4のセットアップでも、AD-2によるこのレベルの分析に対してプライバシーを提供しないことに注意してください。これは、AMTにはトランスポート層の暗号化がないためです。したがって、AD-2は、AMTの（S、G）結合メッセージと同一のコンテンツセグメント（AMTリレーで複製されたもの）の両方からAMTリレーから同じコンテンツを消費しているオンパストラフィック分析によって相関できます。
In summary, because only content to be consumed by multiple EUs is carried via IP multicast here and all of that content can be end-to-end encrypted, the only privacy consideration specific to IP multicast is for AD-2 to know or reconstruct what content an EU is consuming. For content for which this is undesirable, some form of protections as explained above are possible, but ideally, the model described in Section 3.4 could be used in conjunction with future work, e.g., adding Datagram Transport Layer Security (DTLS) encryption [RFC6347] between the AMT relay and the EU.
要約すると、ここでは複数のEUで消費されるコンテンツのみがIPマルチキャストを介して伝送され、そのコンテンツはすべてエンドツーエンドで暗号化できるため、IPマルチキャストに固有のプライバシーに関する考慮事項は、AD-2が何を認識または再構築するかのみです。 EUが消費しているコンテンツ。これが望ましくないコンテンツの場合、上記で説明したような何らかの形の保護が可能ですが、理想的には、セクション3.4で説明されているモデルを将来の作業、たとえばデータグラムトランスポート層セキュリティ（DTLS）暗号化[RFC6347]の追加と組み合わせて使用できます。 AMTリレーとEUの間。
Note that IP multicast by nature would permit the EU's privacy against the content source operator because, unlike unicast, the content source does not natively know which EU is consuming which content: in all cases where AD-2 provides replication, only AD-2 knows this directly. This document does not attempt to describe a model that maintains such a level of privacy against the content source; rather, we describe a model that only protects against exposure to intermediate parties -- in this case, AD-2.
ユニキャストとは異なり、コンテンツソースはどのEUがどのコンテンツを消費しているかをネイティブに知らないため、本質的にIPマルチキャストはコンテンツソースオペレーターに対するEUのプライバシーを許可することに注意してください。AD-2がレプリケーションを提供するすべての場合において、AD-2のみが知っています。これを直接。このドキュメントでは、コンテンツソースに対してこのようなレベルのプライバシーを維持するモデルについては説明しません。むしろ、中間当事者（この場合はAD-2）への暴露に対してのみ保護するモデルについて説明します。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, March 2000, <https://www.rfc-editor.org/info/rfc2784>.
[RFC2784] Farinacci、D.、Li、T。、ハンクス、S.、Meyer、D。、およびP. Traina、「Generic Routing Encapsulation（GRE）」、RFC 2784、DOI 10.17487 / RFC2784、2000年3月、<https ：//www.rfc-editor.org/info/rfc2784>。
[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>.
[RFC3376] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、DOI 10.17487 / RFC3376、2002年10月、< 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>.
[RFC3810] Vida、R。、編、およびL. Costa、編、「IPv6のマルチキャストリスナーディスカバリバージョン2（MLDv2）」、RFC 3810、DOI 10.17487 / RFC3810、2004年6月、<https：// www。 rfc-editor.org/info/rfc3810>。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <https://www.rfc-editor.org/info/rfc4760>.
[RFC4760]ベイツ、T。、チャンドラ、R。、カッツ、D。、およびY.レクター、「BGP-4のマルチプロトコル拡張機能」、RFC 4760、DOI 10.17487 / RFC4760、2007年1月、<https：// www。 rfc-editor.org/info/rfc4760>。
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, August 2006, <https://www.rfc-editor.org/info/rfc4604>.
[RFC4604] Holbrook、H.、Cain、B。、およびB. Haberman、「Source-Specific MulticastでのInternet Group Management Protocolバージョン3（IGMPv3）およびMulticast Listener Discovery Protocolバージョン2（MLDv2）の使用」、RFC 4604、DOI 10.17487 / RFC4604、2006年8月、<https://www.rfc-editor.org/info/rfc4604>。
[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>.
[RFC4609] Savola、P.、Lehtonen、R。、およびD. Meyer、「Protocol Independent Multicast-Sparse Mode（PIM-SM）Multicast Routing Security Issues and Enhancements」、RFC 4609、DOI 10.17487 / RFC4609、2006年10月、< https://www.rfc-editor.org/info/rfc4609>。
[RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, DOI 10.17487/RFC7450, February 2015, <https://www.rfc-editor.org/info/rfc7450>.
[RFC7450] Bumgardner、G。、「Automatic Multicast Tunneling」、RFC 7450、DOI 10.17487 / RFC7450、2015年2月、<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>.
[RFC7761] Fenner、B.、Handley、M.、Holbrook、H.、Kouvelas、I.、Parekh、R.、Zhang、Z。、およびL. Zheng、「プロトコル独立マルチキャスト-スパースモード（PIM-SM） ：プロトコル仕様（改訂）」、STD 83、RFC 7761、DOI 10.17487 / RFC7761、2016年3月、<https://www.rfc-editor.org/info/rfc7761>。
[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[BCP38]ファーガソン、P。およびD.セニー、「ネットワーク入力フィルタリング：IP送信元アドレスのスプーフィングを使用するサービス拒否攻撃の阻止」、BCP 38、RFC 2827、2000年5月、<https：//www.rfc-editor。 org / info / rfc2827>。
[BCP41] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000, <https://www.rfc-editor.org/info/rfc2914>.
[BCP41]フロイド、S。、「輻輳制御原則」、BCP 41、RFC 2914、2000年9月、<https://www.rfc-editor.org/info/rfc2914>。
[BCP145] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[BCP145] Eggert、L.、Fairhurst、G。、およびG. Shepherd、「UDP使用ガイドライン」、BCP 145、RFC 8085、2017年3月、<https://www.rfc-editor.org/info/rfc8085> 。
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, December 2006, <https://www.rfc-editor.org/info/rfc4786>.
[RFC4786] Abley、J。およびK. Lindqvist、「Operation of Anycast Services」、BCP 126、RFC 4786、DOI 10.17487 / RFC4786、2006年12月、<https://www.rfc-editor.org/info/rfc4786> 。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<https://www.rfc-editor.org/info/rfc6347>。
[INF_ATIS_10] "CDN Interconnection Use Cases and Requirements in a Multi-Party Federation Environment", ATIS Standard A-0200010, December 2012.
[INF_ATIS_10]「マルチパーティフェデレーション環境でのCDN相互接続の使用例と要件」、ATIS標準A-0200010、2012年12月。
[MDH-05] Thaler, D. and B. Aboba, "Multicast Debugging Handbook", Work in Progress, draft-ietf-mboned-mdh-05, November 2000.
[MDH-05]ターラー、D。およびB.アボバ、「マルチキャストデバッグハンドブック」、作業中、draft-ietf-mboned-mdh-05、2000年11月。
[Traceroute] "traceroute.org", <http://traceroute.org/#source%20code>.
[Traceroute] "traceroute.org"、<http://traceroute.org/#source%20code>。
[Mtrace-v2] Asaeda, H., Meyer, K., and W. Lee, Ed., "Mtrace Version 2: Traceroute Facility for IP Multicast", Work in Progress, draft-ietf-mboned-mtrace-v2-22, December 2017.
[Mtrace-v2] Asaeda、H.、Meyer、K。、およびW. Lee、編、「Mtraceバージョン2：IPマルチキャスト用Tracerouteファシリティ」、作業中、draft-ietf-mboned-mtrace-v2-22 、2017年12月。
Acknowledgments
謝辞
The authors would like to thank the following individuals for their suggestions, comments, and corrections:
著者は、以下の個人からの提案、コメント、および訂正に感謝します。
Mikael Abrahamsson
ミカエル・アブラハムソン
Hitoshi Asaeda
ひとし あさえだ
Dale Carder
デール・カーダー
Tim Chown
ティム・チョウン
Leonard Giuliano
レナード・ジュリアーノ
Jake Holland
ジェイクホーランド
Joel Jaeggli
ジョエル・ジャグリ
Henrik Levkowetz
ヘンリック・レフコウェッツ
Albert Manfredi
アルバート・マンフレディ
Stig Venaas
スティグ・ヴェナス
Authors' Addresses
著者のアドレス
Percy S. Tarapore (editor) AT&T
パーシーS.タラポア（編集者）AT＆T
Phone: 1-732-420-4172 Email: tarapore@att.com
電話：1-732-420-4172メール：tarapore@att.com
Robert Sayko AT&T
ロバート・サイコAT＆T
Phone: 1-732-420-3292 Email: rs1983@att.com
電話：1-732-420-3292メール：rs1983@att.com
Greg Shepherd Cisco
グレッグシェパードシスコ
Email: shep@cisco.com
Toerless Eckert (editor) Huawei USA - Futurewei Technologies Inc.
Toerless Eckert（editor）Huawei USA-Futurewei Technologies Inc.
Email: tte+ietf@cs.fau.de, toerless.eckert@huawei.com
Ram Krishnan SupportVectors
RamクリシュナンSupportVectors
Email: ramkri123@gmail.com