RFC 6707 - Content Distribution Network Interconnection (CDNI) Problem Statement 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc6707
タイトル : RFC 6707 - コンテンツ配布ネットワーク相互接続（CDNI）問題ステートメント
翻訳編集 : 自動生成

[要約] RFC 6707は、CDN間の相互接続に関する問題を明確にするためのものであり、CDNIの問題を定義しています。その目的は、異なるCDN間でのコンテンツの効率的な配信を実現するためのガイドラインを提供することです。

Internet Engineering Task Force (IETF)                  B. Niven-Jenkins
Request for Comments: 6707                      Velocix (Alcatel-Lucent)
Category: Informational                                   F. Le Faucheur
ISSN: 2070-1721                                                    Cisco
                                                                N. Bitar
                                                                 Verizon
                                                          September 2012

Content Distribution Network Interconnection (CDNI) Problem Statement

コンテンツ配布ネットワーク相互接続（CDNI）問題ステートメント

Abstract

概要

Content Delivery Networks (CDNs) provide numerous benefits for cacheable content: reduced delivery cost, improved quality of experience for End Users, and increased robustness of delivery. For these reasons, they are frequently used for large-scale content delivery. As a result, existing CDN Providers are scaling up their infrastructure, and many Network Service Providers (NSPs) are deploying their own CDNs. It is generally desirable that a given content item can be delivered to an End User regardless of that End User's location or attachment network. This is the motivation for interconnecting standalone CDNs so they can interoperate as an open content delivery infrastructure for the end-to-end delivery of content from Content Service Providers (CSPs) to End Users. However, no standards or open specifications currently exist to facilitate such CDN Interconnection.

コンテンツ配信ネットワーク（CDN）は、キャッシュ可能なコンテンツに多くの利点を提供します：配信コストの削減、エンドユーザーのエクスペリエンス品質の向上、配信の堅牢性の向上。これらの理由により、これらは大規模なコンテンツ配信に頻繁に使用されます。その結果、既存のCDNプロバイダーがインフラストラクチャを拡大し、多くのネットワークサービスプロバイダー（NSP）が独自のCDNを展開しています。エンドユーザーの場所や接続ネットワークに関係なく、特定のコンテンツアイテムをエンドユーザーに配信できることが一般に望ましい。これは、スタンドアロンCDNを相互接続する動機であり、コンテンツサービスプロバイダー（CSP）からエンドユーザーへのコンテンツのエンドツーエンド配信のためのオープンコンテンツ配信インフラストラクチャとして相互運用できます。ただし、このようなCDN相互接続を容易にする標準やオープンな仕様は現在ありません。

The goal of this document is to outline the problem area of CDN Interconnection for the IETF CDNI (CDN Interconnection) working group.

このドキュメントの目的は、IETF CDNI（CDN相互接続）ワーキンググループのCDN相互接続の問題領域の概要を説明することです。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6707.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6707で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1. Introduction ....................................................3
      1.1. Terminology ................................................4
      1.2. CDN Background .............................................9
   2. CDN Interconnection Use Cases ...................................9
   3. CDN Interconnection Model and Problem Area for IETF ............11
   4. Scoping the CDNI Problem .......................................15
      4.1. CDNI Control Interface ....................................16
      4.2. CDNI Request Routing Interface ............................16
      4.3. CDNI Metadata Interface ...................................17
      4.4. CDNI Logging Interface ....................................17
   5. Security Considerations ........................................17
      5.1. Security of the CDNI Control Interface ....................18
      5.2. Security of the CDNI Request Routing Interface ............18
      5.3. Security of the CDNI Metadata Interface ...................19
      5.4. Security of the CDNI Logging Interface ....................19
   6. Acknowledgements ...............................................19
   7. Informative References .........................................20
   Appendix A. Design Considerations for Realizing the CDNI
               Interfaces ............................................22
     A.1. CDNI Control Interface .....................................22
     A.2. CDNI Request Routing Interface .............................23
     A.3. CDNI Metadata Interface ....................................25
     A.4. CDNI Logging Interface .....................................26
   Appendix B. Additional Material ...................................27
     B.1. Non-Goals for IETF .........................................27
     B.2. Relationship to Relevant IETF Working Groups and IRTF
          Research Groups ............................................29
       B.2.1. ALTO WG ................................................29
       B.2.2. DECADE WG ..............................................29
       B.2.3. PPSP WG ................................................31
       B.2.4. IRTF P2P Research Group ................................31

1. Introduction

1. はじめに

The volume of video and multimedia content delivered over the Internet is rapidly increasing and expected to continue doing so in the future. In the face of this growth, Content Delivery Networks (CDNs) provide numerous benefits for cacheable content: reduced delivery cost, improved quality of experience for End Users (EUs), and increased robustness of delivery. For these reasons, CDNs are frequently used for large-scale content delivery. As a result, existing CDN Providers are scaling up their infrastructure, and many Network Service Providers (NSPs) are deploying their own CDNs.

インターネット経由で配信されるビデオおよびマルチメディアコンテンツの量は急速に増加しており、今後も継続すると予想されます。この成長に直面して、コンテンツ配信ネットワーク（CDN）は、キャッシュ可能なコンテンツに多くの利点を提供します：配信コストの削減、エンドユーザー（EU）のエクスペリエンス品質の向上、配信の堅牢性の向上。これらの理由により、CDNは大規模なコンテンツ配信に頻繁に使用されます。その結果、既存のCDNプロバイダーがインフラストラクチャを拡大し、多くのネットワークサービスプロバイダー（NSP）が独自のCDNを展開しています。

It is generally desirable that a given content item can be delivered to an EU regardless of that EU's location or the network they are attached to. However, a given CDN in charge of delivering a given content may not have a footprint that expands close enough to the EU's current location or attachment network, or may not have the necessary resources, to realize the user experience and cost benefit that a more distributed CDN infrastructure would allow. This is the motivation for interconnecting standalone CDNs so that their collective CDN footprint and resources can be leveraged for the end-to-end delivery of content from Content Service Providers (CSPs) to EUs. As an example, a CSP could contract with an "authoritative" CDN Provider for the delivery of content, and that Authoritative CDN Provider could contract with one or more downstream CDN Providers to distribute and deliver some or all of the content on behalf of the Authoritative CDN Provider.

一般に、特定のコンテンツアイテムは、そのEUの場所や接続されているネットワークに関係なく、EUに配信できることが望ましいです。ただし、特定のコンテンツの配信を担当する特定のCDNには、EUの現在の場所または接続ネットワークに十分に拡大するフットプリントがないか、必要なリソースがないため、より分散されたユーザーエクスペリエンスとコストメリットを実現できませんCDNインフラストラクチャでは可能です。これは、スタンドアロンCDNを相互接続する動機であり、それらの集合CDNフットプリントとリソースを利用して、コンテンツサービスプロバイダー（CSP）からEUへのコンテンツのエンドツーエンド配信を実現できます。例として、CSPはコンテンツの配信について「権威のある」CDNプロバイダーと契約し、その権威のあるCDNプロバイダーは1つ以上の下流のCDNプロバイダーと契約して、権威の代わりにコンテンツの一部またはすべてを配布および配信できます。 CDNプロバイダー。

A typical end-to-end content delivery scenario would then involve the following business arrangements:

典型的なエンドツーエンドのコンテンツ配信シナリオには、次のビジネス上の取り決めが含まれます。

o A business arrangement between the EU and his CSP, authorizing access by the EU to content items controlled by the CSP.

o EUとCSPの間のビジネス上の取り決め。CSPによって制御されるコンテンツアイテムへのEUによるアクセスを許可します。

o A business arrangement between the CSP and an "authoritative" CDN Provider where the CSP mandates that the CDN Provider perform the content delivery on behalf of the CSP.

o CSPとCDNプロバイダーがCSPに代わってコンテンツ配信を実行することをCSPに要求する「権限のある」CDNプロバイダー間のビジネス上の取り決め。

o A business arrangement between the Authoritative CDN Provider and another (or other) CDN(s) where the Authoritative CDN may delegate the actual serving of some of the content delivery requests to the other CDN(s). A particular case is where this other CDN Provider happens to also be the Network Service Provider providing network access to the EU, in which case there is also a separate and independent business relationship between the EU and the NSP for the corresponding network access.

o 権威あるCDNプロバイダーと別の（または他の）CDNの間のビジネス上の取り決め。権威あるCDNは、一部のコンテンツ配信要求の実際の提供を他のCDNに委任する場合があります。特定の他のケースは、この他のCDNプロバイダーが偶然にもEUへのネットワークアクセスを提供するネットワークサービスプロバイダーである場合です。この場合、対応するネットワークアクセスについて、EUとNSPの間にも別個の独立したビジネス関係があります。

The formation and details of any business relationships between a CSP and a CDN Provider as well as between one CDN Provider and another CDN Provider are out of scope of this document. However, this document concerns itself with the fact that no standards or open specifications currently exist to facilitate such CDN Interconnection from a technical perspective.

CSPとCDNプロバイダーの間、および1つのCDNプロバイダーと別のCDNプロバイダーの間のビジネス関係の形成と詳細は、このドキュメントの範囲外です。ただし、このドキュメントは、技術的な観点からこのようなCDN相互接続を容易にする標準またはオープンな仕様が現在存在しないという事実に関係しています。

One possible flow for performing an end-to-end content delivery across a CDN Interconnection is described below:

CDN相互接続を介してエンドツーエンドのコンテンツ配信を実行するための1つの可能なフローを以下に説明します。

o The initial content request from an EU's User Agent is first received by the authoritative (upstream) CDN, which is the CDN with a business arrangement with the CSP.

o EUのユーザーエージェントからの最初のコンテンツ要求は、最初に、権威ある（上流）CDNによって受信されます。これは、CSPとのビジネス契約を持つCDNです。

o The authoritative (upstream) CDN may serve the request itself, or it may elect to use CDN Interconnection to redirect the request to a Downstream CDN that is in a better position to do so (e.g., a Downstream CDN that is "closer" to the EU).

o 信頼できる（アップストリーム）CDNは、リクエスト自体を処理するか、またはCDN相互接続を使用して、リクエストをリダイレクトするのにより適切な位置にあるダウンストリームCDNにリダイレクトすることを選択できます（たとえば、 EU）。

o The EU's User Agent will "follow" the redirect returned by the Authoritative CDN and request the content from the Downstream CDN. If required, the Downstream CDN will acquire the requested content from the authoritative (upstream) CDN, and if necessary the Authoritative CDN will acquire the requested content from the Content Service Provider.

o EUのユーザーエージェントは、権威あるCDNから返されたリダイレクトを「追跡」し、コンテンツをダウンストリームCDNに要求します。必要に応じて、ダウンストリームCDNは要求されたコンテンツを権威ある（アップストリーム）CDNから取得し、必要な場合は権威CDNが要求されたコンテンツをコンテンツサービスプロバイダーから取得します。

The goal of this document is to outline the problem area of CDN Interconnection. Section 2 discusses the use cases for CDN Interconnection. Section 3 presents the CDNI model and problem area being considered by the IETF. Section 4 describes each CDNI interface individually and highlights example candidate protocols that could be considered for reuse or leveraging to implement the CDNI interfaces. Appendix B.2 describes the relationships between the CDNI problem space and other relevant IETF working groups and IRTF research groups.

このドキュメントの目的は、CDN相互接続の問題領域の概要を説明することです。セクション2では、CDN相互接続の使用例について説明します。セクション3では、IETFが検討しているCDNIモデルと問題領域について説明します。セクション4では、各CDNIインターフェースを個別に説明し、CDNIインターフェースを実装するために再利用または活用することを検討できる候補プロトコルの例を強調します。付録B.2は、CDNI問題空間と他の関連するIETFワーキンググループおよびIRTF研究グループとの関係を説明しています。

1.1. Terminology

1.1. 用語

This document uses the following terms:

このドキュメントでは、次の用語を使用します。

Authoritative CDN: A CDN that has a direct relationship with a CSP for the distribution and delivery of that CSP's content by the Authoritative CDN or by Downstream CDNs of the Authoritative CDN.

Authoritative CDN：Authoritative CDNまたはAuthoritative CDNのダウンストリームCDNによるCSPのコンテンツの配布および配信のために、CSPと直接的な関係があるCDN。

CDN Interconnection (CDNI): A relationship between a pair of CDNs that enables one CDN to provide content delivery services on behalf of another CDN. A CDN Interconnection may be wholly or partially realized through a set of interfaces over which a pair of CDNs communicate with each other in order to achieve the delivery of content to User Agents by Surrogates in one CDN (the Downstream CDN) on behalf of another CDN (the Upstream CDN).

CDN相互接続（CDNI）：1つのCDNが別のCDNに代わってコンテンツ配信サービスを提供できるようにする、CDNのペア間の関係。 CDN相互接続は、別のCDNに代わって1つのCDN（ダウンストリームCDN）のサロゲートによるユーザーエージェントへのコンテンツの配信を実現するために、CDNのペアが互いに通信する一連のインターフェイスを通じて完全または部分的に実現できます（アップストリームCDN）。

CDN Provider: The service provider who operates a CDN and offers a service of content delivery, typically used by a Content Service Provider or another CDN Provider. Note that a given entity may operate in more than one role. For example, a company may simultaneously operate as a Content Service Provider, a Network Service Provider, and a CDN Provider.

CDNプロバイダー：CDNを運用し、コンテンツ配信サービスを提供するサービスプロバイダー。通常、コンテンツサービスプロバイダーまたは別のCDNプロバイダーによって使用されます。特定のエンティティが複数の役割で機能する場合があることに注意してください。たとえば、企業はコンテンツサービスプロバイダー、ネットワークサービスプロバイダー、およびCDNプロバイダーとして同時に動作する場合があります。

CDNI Metadata: The subset of Content Distribution Metadata that has an inter-CDN scope. For example, CDNI Metadata may include geo-blocking information (i.e., information defining geographical areas where the content is to be made available or blocked), availability windows (i.e., information defining time windows during which the content is to be made available or blocked) and access control mechanisms to be enforced (e.g., URI signature validation). CDNI Metadata may also include information about desired distribution policy (e.g., pre-positioned vs dynamic acquisition) and about where/ how a CDN can acquire the content.

CDNIメタデータ：CDN間スコープを持つコンテンツ配信メタデータのサブセット。たとえば、CDNIメタデータには、ジオブロッキング情報（つまり、コンテンツを利用可能またはブロックする地理的領域を定義する情報）、可用性ウィンドウ（つまり、コンテンツを利用可能またはブロックする時間ウィンドウを定義する情報）を含めることができます。）および適用されるアクセス制御メカニズム（URI署名の検証など）。 CDNIメタデータには、望ましい配信ポリシー（事前配信と動的取得など）に関する情報や、CDNがコンテンツを取得できる場所/方法に関する情報も含まれます。

Content: Any form of digital data. One important form of Content with additional constraints on distribution and delivery is continuous media (i.e., where there is a timing relationship between source and sink).

コンテンツ：あらゆる形式のデジタルデータ。配信と配信に追加の制約があるコンテンツの1つの重要な形式は、継続的なメディアです（つまり、ソースとシンクの間にタイミング関係がある場合）。

Content Distribution Metadata: The subset of Content Metadata that is relevant to the distribution of the content. This is the metadata required by a CDN in order to enable and control content distribution and delivery by the CDN. In a CDN Interconnection environment, some of the Content Distribution Metadata may have an intra-CDN scope (and therefore need not be communicated between CDNs), while some of the Content Distribution Metadata may have an inter-CDN scope (and therefore needs to be communicated between CDNs).

コンテンツ配布メタデータ：コンテンツの配布に関連するコンテンツメタデータのサブセット。これは、CDNによるコンテンツの配信と配信を有効にして制御するためにCDNが必要とするメタデータです。 CDN相互接続環境では、一部のコンテンツ配布メタデータにCDN内スコープがある（したがって、CDN間で通信する必要がない）ことがありますが、一部のコンテンツ配布メタデータには、CDN間スコープがある（したがって、 CDN間で通信されます）。

Content Distribution Network (CDN) / Content Delivery Network (CDN): Network infrastructure in which the network elements cooperate at Layers 4 through 7 for more effective delivery of Content to User Agents. Typically, a CDN consists of a Request Routing system, a Distribution system (that includes a set of Surrogates), a Logging system, and a CDN Control system.

コンテンツ配信ネットワーク（CDN）/コンテンツ配信ネットワーク（CDN）：ユーザーエージェントへのコンテンツの配信をより効果的にするために、ネットワーク要素がレイヤー4〜7で連携するネットワークインフラストラクチャ。通常、CDNは、要求ルーティングシステム、配布システム（サロゲートのセットを含む）、ロギングシステム、およびCDN制御システムで構成されます。

Content Metadata: This is metadata about Content. Content Metadata comprises:

コンテンツメタデータ：コンテンツに関するメタデータです。コンテンツメタデータは以下で構成されます。

1. Metadata that is relevant to the distribution of the content (and therefore relevant to a CDN involved in the delivery of that content). We refer to this type of metadata as "Content Distribution Metadata". See also the definition of Content Distribution Metadata.

1. コンテンツの配布に関連する（したがって、そのコンテンツの配信に関与するCDNに関連する）メタデータ。このタイプのメタデータを「コンテンツ配信メタデータ」と呼びます。コンテンツ配信メタデータの定義もご覧ください。

2. Metadata that is associated with the actual Content or content representation, and not directly relevant to the distribution of that Content. For example, such metadata may include information pertaining to the Content's genre, cast, rating, etc. as well as information pertaining to the Content representation's resolution, aspect ratio, etc.

2. 実際のコンテンツまたはコンテンツ表現に関連付けられており、そのコンテンツの配布に直接関連しないメタデータ。たとえば、このようなメタデータには、コンテンツのジャンル、キャスト、評価などに関する情報や、コンテンツ表現の解像度、アスペクト比などに関する情報が含まれます。

Content Service: The service offered by a Content Service Provider. The Content Service encompasses the complete service, which may be wider than just providing access to items of Content; e.g., the Content Service also includes any middleware, key distribution, program guide, etc. that may not require any direct interaction with the CDN, or CDNs, involved in the distribution and delivery of the content.

コンテンツサービス：コンテンツサービスプロバイダーによって提供されるサービス。コンテンツサービスには完全なサービスが含まれ、コンテンツのアイテムへのアクセスを提供するだけではありません。たとえば、コンテンツサービスには、コンテンツの配布と配信に関与する1つまたは複数のCDNとの直接の対話を必要としないミドルウェア、キー配布、プログラムガイドなども含まれます。

Content Service Provider (CSP): Provides a Content Service to End Users (which they access via a User Agent). A CSP may own the Content made available as part of the Content Service, or may license content rights from another party.

コンテンツサービスプロバイダー（CSP）：エンドユーザー（ユーザーエージェントを介してアクセスする）にコンテンツサービスを提供します。 CSPは、コンテンツサービスの一部として利用可能にされたコンテンツを所有するか、または他の当事者からコンテンツの権利をライセンスすることができます。

Control system: The function within a CDN responsible for bootstrapping and controlling the other components of the CDN as well as for handling interactions with external systems (e.g., handling delivery service creation/update/removal requests, or specific service provisioning requests).

制御システム：CDNの他のコンポーネントのブートストラップと制御、および外部システムとの相互作用の処理（配信サービスの作成/更新/削除要求、または特定のサービスプロビジョニング要求の処理など）を担当するCDN内の機能。

Delivery: The function within CDN Surrogates responsible for delivering a piece of content to the User Agent. For example, delivery may be based on HTTP progressive download or HTTP adaptive streaming.

配信：コンテンツの一部をユーザーエージェントに配信するCDNサロゲート内の機能。たとえば、配信はHTTPプログレッシブダウンロードまたはHTTPアダプティブストリーミングに基づく場合があります。

Distribution system: The function within a CDN responsible for distributing Content Distribution Metadata as well as the Content itself inside the CDN (e.g., down to the Surrogates).

配信システム：コンテンツ配信メタデータとCDN内のコンテンツ自体（サロゲートまで）の配信を担当するCDN内の機能。

Downstream CDN: For a given End User request, the CDN (within a pair of directly interconnected CDNs) to which the request is redirected by the other CDN (the Upstream CDN). Note that in the case of successive redirections (e.g., CDN1-->CDN2-->CDN3), a given CDN (e.g., CDN2) may act as the Downstream CDN for a redirection (e.g., CDN1-->CDN2) and as the Upstream CDN for the subsequent redirection of the same request (e.g., CDN2-->CDN3).

ダウンストリームCDN：特定のエンドユーザーリクエストに対して、リクエストが他のCDN（アップストリームCDN）によってリダイレクトされる先のCDN（直接相互接続されたCDNのペア内）。連続したリダイレクト（例：CDN1-> CDN2-> CDN3）の場合、特定のCDN（例：CDN2）は、リダイレクトのダウンストリームCDN（例：CDN1-> CDN2）および同じ要求の後続のリダイレクトのためのアップストリームCDN（たとえば、CDN2-> CDN3）。

Dynamic CDNI Metadata acquisition: In the context of CDN Interconnection, dynamic CDNI Metadata acquisition means that a Downstream CDN acquires CDNI Metadata for content from the Upstream CDN at some point in time after a request for that content is delegated to the Downstream CDN by an Upstream CDN (and that specific CDNI Metadata is not yet available in the Downstream CDN). See also the definitions for Downstream CDN and Upstream CDN.

動的CDNIメタデータ取得：CDN相互接続のコンテキストでは、動的CDNIメタデータ取得とは、ダウンストリームCDNが、コンテンツのリクエストがアップストリームによってダウンストリームCDNに委任された後のある時点で、アップストリームCDNからコンテンツのCDNIメタデータを取得することを意味しますCDN（およびその特定のCDNIメタデータは、まだダウンストリームCDNで利用できません）。ダウンストリームCDNおよびアップストリームCDNの定義も参照してください。

Dynamic content acquisition: Dynamic content acquisition is where a CDN acquires content from the content source in response to an End User requesting that content from the CDN. In the context of CDN Interconnection, dynamic acquisition means that a Downstream CDN acquires the content from content sources (including Upstream CDNs) at some point in time after a request for that content is delegated to the Downstream CDN by an Upstream CDN (and that specific content is not yet available in the Downstream CDN).

動的コンテンツ取得：動的コンテンツ取得では、CDNからコンテンツを要求するエンドユーザーに応答して、CDNがコンテンツソースからコンテンツを取得します。 CDN相互接続のコンテキストでは、動的取得とは、ダウンストリームCDNがコンテンツソース（アップストリームCDNを含む）からコンテンツを取得することを意味します。コンテンツはまだダウンストリームCDNで利用できません）。

End User (EU): The 'real' user of the system, typically a human but maybe some combination of hardware and/or software emulating a human (e.g., for automated quality monitoring etc.).

エンドユーザー（EU）：システムの「実際の」ユーザー。通常は人間ですが、人間をエミュレートするハードウェアやソフトウェアの組み合わせ（たとえば、自動品質監視など）です。

Logging system: The function within a CDN responsible for collecting the measurement and recording of distribution and delivery activities. The information recorded by the Logging system may be used for various purposes, including charging (e.g., of the CSP), analytics, and monitoring.

ロギングシステム：CDN内の機能で、配信と配信のアクティビティの測定と記録を収集します。ロギングシステムによって記録された情報は、課金（CSPなど）、分析、監視など、さまざまな目的に使用できます。

Metadata: Metadata in general is data about data.

メタデータ：一般にメタデータはデータに関するデータです。

Network Service Provider (NSP): Provides network-based connectivity/ services to End Users.

ネットワークサービスプロバイダー（NSP）：エンドユーザーにネットワークベースの接続/サービスを提供します。

Over-the-top (OTT): A service, e.g., content delivery using a CDN, operated by a different operator than the NSP to which the users of that service are attached.

Over-the-top（OTT）：CDNを使用したコンテンツ配信など、サービスのユーザーが接続しているNSPとは異なる事業者が運営するサービス。

Pre-positioned CDNI Metadata acquisition: In the context of CDN Interconnection, CDNI Metadata pre-positioning is where the Downstream CDN acquires CDNI Metadata for content prior to, or independently of, any End User requesting that content from the Downstream CDN.

事前配信されたCDNIメタデータの取得：CDN相互接続のコンテキストでは、CDNIメタデータの事前配信は、ダウンストリームCDNからコンテンツを要求するエンドユーザーの前に、または独立して、ダウンストリームCDNがコンテンツのCDNIメタデータを取得する場所です。

Pre-positioned content acquisition: Content pre-positioning is where a CDN acquires content from the content source prior to, or independently of, any End User requesting that content from the CDN. In the context of CDN Interconnection, the Upstream CDN instructs the Downstream CDN to acquire the content from content sources (including Upstream CDNs) in advance of, or independently of, any End User requesting it.

事前配信コンテンツの取得：コンテンツの事前配信では、エンドユーザーがCDNにコンテンツを要求する前に、または独立して、CDNがコンテンツソースからコンテンツを取得します。 CDN相互接続のコンテキストでは、アップストリームCDNはダウンストリームCDNに、エンドユーザーが要求する前に、または独立して、コンテンツソース（アップストリームCDNを含む）からコンテンツを取得するように指示します。

Quality of Experience (QoE): As defined in Section 2.4 of [RFC6390].

Quality of Experience（QoE）：[RFC6390]のセクション2.4で定義されています。

Request Routing system: The function within a CDN responsible for receiving a Content Request from a User Agent, obtaining and maintaining necessary information about a set of candidate Surrogates or candidate CDNs, and for selecting and redirecting the user to the appropriate Surrogate or CDN. To enable CDN Interconnection, the Request Routing system must also be capable of handling User Agent Content Requests passed to it by another CDN.

リクエストルーティングシステム：ユーザーエージェントからコンテンツリクエストを受け取り、サロゲート候補またはCDN候補のセットに関する必要な情報を取得および維持し、ユーザーを選択して適切なサロゲートまたはCDNにリダイレクトするCDN内の機能。 CDN相互接続を有効にするには、要求ルーティングシステムが、別のCDNによって渡されたユーザーエージェントコンテンツ要求を処理できる必要があります。

Surrogate: A device/function (often called a cache) that interacts with other elements of the CDN for the control and distribution of Content within the CDN and interacts with User Agents for the delivery of the Content. Typically, Surrogates will cache requested content so that they can directly deliver the same content in response to requests from multiple User Agents (and their End Users), avoiding the need for the content to transit multiple times through the network core (i.e., from the content origin to the Surrogate).

サロゲート：CDN内のコンテンツの制御と配信のためにCDNの他の要素と相互作用し、コンテンツの配信のためにユーザーエージェントと相互作用するデバイス/機能（しばしばキャッシュと呼ばれる）。通常、サロゲートは要求されたコンテンツをキャッシュして、複数のユーザーエージェント（およびそのエンドユーザー）からの要求に応じて同じコンテンツを直接配信できるようにします。これにより、コンテンツがネットワークコアを介して複数回（つまり、コンテンツのサロゲートの起源）。

Upstream CDN: For a given End User request, the CDN (within a pair of directly interconnected CDNs) that redirects the request to the other CDN.

アップストリームCDN：特定のエンドユーザーリクエストに対して、リクエストを他のCDNにリダイレクトするCDN（直接相互接続されたCDNのペア内）。

User Agent (UA): Software (or a combination of hardware and software) through which the End User interacts with a Content Service. The User Agent will communicate with a Content Service for the selection of content and one or more CDNs for the delivery of the Content. Such communication is not restricted to HTTP and may be via a variety of protocols. Examples of User Agents (non-exhaustive) are browsers, Set Top Boxes (STBs), dedicated content applications (e.g., media players), etc.

ユーザーエージェント（UA）：エンドユーザーがコンテンツサービスとやり取りするためのソフトウェア（またはハードウェアとソフトウェアの組み合わせ）。ユーザーエージェントは、コンテンツの選択のためにコンテンツサービスと通信し、コンテンツの配信のために1つ以上のCDNと通信します。このような通信はHTTPに限定されず、さまざまなプロトコルを介して行われます。ユーザーエージェント（完全ではない）の例としては、ブラウザ、セットトップボックス（STB）、専用コンテンツアプリケーション（メディアプレーヤーなど）などがあります。

1.2. CDN Background

1.2. CDNの背景

Readers are assumed to be familiar with the architecture, features, and operation of CDNs. For readers less familiar with the operation of CDNs, the following resources may be useful:

読者は、CDNのアーキテクチャ、機能、および操作に精通していることを前提としています。 CDNの操作にあまり詳しくない読者には、次のリソースが役立つ場合があります。

o RFC 3040 [RFC3040] describes many of the component technologies that are used in the construction of a CDN.

o RFC 3040 [RFC3040]は、CDNの構築に使用されるコンポーネントテクノロジーの多くについて説明しています。

o Taxonomy [TAXONOMY] compares the architecture of a number of CDNs.

o 分類[TAXONOMY]は、多数のCDNのアーキテクチャを比較します。

o RFC 3466 [RFC3466] and RFC 3570 [RFC3570] are the output of the IETF Content Distribution Internetworking (CDI) working group, which was closed in 2003.

o RFC 3466 [RFC3466]およびRFC 3570 [RFC3570]は、2003年に終了したIETFコンテンツ配布インターネットワーキング（CDI）ワーキンググループの出力です。

Note: Some of the terms used in this document are similar to terms used in the above referenced documents. When reading this document, terms should be interpreted as having the definitions provided in Section 1.1.

注：このドキュメントで使用されている用語の一部は、上記の参照ドキュメントで使用されている用語と類似しています。このドキュメントを読むとき、用語はセクション1.1で提供された定義を持つものとして解釈されるべきです。

2. CDN Interconnection Use Cases

2. CDN相互接続のユースケース

An increasing number of NSPs are deploying CDNs in order to deal cost-effectively with the growing usage of on-demand video services and other content delivery applications.

オンデマンドビデオサービスやその他のコンテンツ配信アプリケーションの使用量の増加にコスト効率よく対処するために、CDNを展開するNSPの数が増えています。

CDNs allow caching of content closer to the edge of a network so that a given item of content can be delivered by a CDN Surrogate (i.e., a cache) to multiple User Agents (and their End Users) without transiting multiple times through the network core (i.e., from the content origin to the Surrogate). This contributes to bandwidth cost reductions for the NSP and to improved quality of experience for the End Users. CDNs also enable replication of popular content across many Surrogates, which enables content to be served to large numbers of User Agents concurrently. This also helps in dealing with situations such as flash crowds and denial-of-service attacks.

CDNを使用すると、ネットワークのエッジに近いコンテンツをキャッシュできるため、コンテンツの特定のアイテムをCDNサロゲート（キャッシュ）から複数のユーザーエージェント（およびそのエンドユーザー）に、ネットワークコアを何度も通過することなく配信できます。（つまり、コンテンツの起点からサロゲートまで）。これにより、NSPの帯域幅コストが削減され、エンドユーザーのエクスペリエンス品質が向上します。 CDNを使用すると、多くのサロゲート間で人気のあるコンテンツを複製できるため、コンテンツを多数のユーザーエージェントに同時に提供できます。これは、フラッシュクラウドやサービス拒否攻撃などの状況への対処にも役立ちます。

The CDNs deployed by NSPs are not just restricted to the delivery of content to support the Network Service Provider's own 'walled garden' services, such as IP delivery of television services to Set Top Boxes, but are also used for delivery of content to other devices, including PCs, tablets, mobile phones, etc.

NSPによって展開されるCDNは、セットトップボックスへのテレビサービスのIP配信など、ネットワークサービスプロバイダー独自の「ウォールドガーデン」サービスをサポートするコンテンツの配信だけでなく、他のデバイスへのコンテンツの配信にも使用されます。、PC、タブレット、携帯電話などを含みます。

Some service providers operate over multiple geographies and federate multiple affiliate NSPs. These NSPs typically operate independent CDNs. As they evolve their services (e.g., for seamless support of content services to nomadic users across affiliate NSPs), there is a need for interconnection of these CDNs; this represents a first use case for CDNI. However, there are no open specifications, nor common best practices, defining how to achieve such CDN Interconnection.

一部のサービスプロバイダーは、複数の地域で運用し、複数のアフィリエイトNSPを統合しています。これらのNSPは通常、独立したCDNを操作します。彼らがサービスを進化させるにつれて（たとえば、アフィリエイトNSP全体の遊牧ユーザーへのコンテンツサービスのシームレスなサポートのため）、これらのCDNの相互接続が必要になります。これは、CDNIの最初の使用例です。ただし、そのようなCDN相互接続を実現する方法を定義するオープンな仕様や一般的なベストプラクティスはありません。

CSPs have a desire to be able to get (some of) their content to very large numbers of End Users, who are often distributed across a number of geographies, while maintaining a high quality of experience, all without having to maintain direct business relationships with many different CDN Providers (or having to extend their own CDN to a large number of locations). Some NSPs are considering interconnecting their respective CDNs (as well as possibly over-the-top CDNs) so that this collective infrastructure can address the requirements of CSPs in a cost-effective manner. This represents a second use case for CDNI. In particular, this would enable the CSPs to benefit from on-net delivery (i.e., within the Network Service Provider's own network/CDN footprint) whenever possible and off-net delivery otherwise, without requiring the CSPs to maintain direct business relationships with all the CDNs involved in the delivery. Again, CDN Providers (NSPs or over-the-top CDN operators) are faced with a lack of open specifications and best practices.

CSPは、コンテンツの一部を非常に多数のエンドユーザーに提供したいと望んでいます。エンドユーザーは、多くの地域に分散していることが多く、高品質のエクスペリエンスを維持しながら、すべて直接のビジネス関係を維持する必要はありません。多くの異なるCDNプロバイダー（または独自のCDNを多数の場所に拡張する必要がある）。一部のNSPは、この集合的なインフラストラクチャがCSPの要件に費用対効果の高い方法で対処できるように、それぞれのCDN（および場合によってはオーバーザトップCDN）の相互接続を検討しています。これは、CDNIの2番目の使用例です。特に、これにより、CSPは、可能な限りオンネット配信（つまり、ネットワークサービスプロバイダーの独自のネットワーク/ CDNフットプリント内）から恩恵を受け、そうでない場合はオフネット配信から恩恵を受けることができます。配信に関係するCDN。繰り返しになりますが、CDNプロバイダー（NSPまたはオーバーザトップCDNオペレーター）は、オープンな仕様とベストプラクティスの欠如に直面しています。

NSPs have often deployed CDNs as specialized cost-reduction projects within the context of a particular service or environment. Some NSPs operate separate CDNs for separate services. For example, there may be a CDN for managed IPTV service delivery, a CDN for web-TV delivery, and a CDN for video delivery to mobile terminals. As NSPs integrate their service portfolio, there is a need for interconnecting these CDNs, representing a third use case for CDNI. Again, NSPs face the problem of lack of open interfaces for CDN Interconnection.

NSPは、特定のサービスまたは環境のコンテキスト内で、CDNを特殊なコスト削減プロジェクトとして展開することがよくあります。一部のNSPは、個別のサービスに対して個別のCDNを操作します。たとえば、管理されたIPTVサービス配信用のCDN、Web-TV配信用のCDN、およびモバイル端末へのビデオ配信用のCDNが存在する場合があります。 NSPはサービスポートフォリオを統合しているため、これらのCDNを相互接続する必要があります。これは、CDNIの3番目の使用例です。ここでも、NSPはCDN相互接続用のオープンインターフェイスがないという問題に直面しています。

For operational reasons (e.g., disaster, flash crowd) or commercial reasons, an over-the-top CDN may elect to make use of another CDN (e.g., an NSP CDN with on-net Surrogates for a given footprint) for serving a subset of the user requests (e.g., requests from users attached to that NSP), which results in a fourth use case for CDNI because CDN Providers (over-the-top CDN Providers or NSPs) are faced with a lack of open specifications and best practices.

運用上の理由（例：災害、フラッシュクラウド）または商業上の理由により、オーバーザトップCDNは、サブセットを提供するために別のCDN（例：特定のフットプリントのオンネットサロゲートを持つNSP CDN）を利用することを選択する場合があります。ユーザーの要求（たとえば、そのNSPに接続されているユーザーからの要求）の結果、CDNプロバイダー（オーバーザトップCDNプロバイダーまたはNSP）はオープンな仕様とベストプラクティスの欠如に直面しているため、CDNIの4番目のユースケースになります。。

Use cases for CDN Interconnection are further discussed in [CDNI-USE-CASES].

CDN相互接続の使用例については、[CDNI-USE-CASES]でさらに説明します。

3. CDN Interconnection Model and Problem Area for IETF

3. IETFのCDN相互接続モデルと問題領域

This section discusses the problem area for the IETF work on CDN Interconnection.

このセクションでは、CDN相互接続に関するIETF作業の問題領域について説明します。

Interconnecting CDNs involves interactions among multiple different functions and components that form each CDN. Only some of those require additional specification by the IETF.

CDNの相互接続には、各CDNを形成する複数の異なる機能およびコンポーネント間の相互作用が含まれます。 IETFによる追加の指定が必要なのは、それらの一部のみです。

Some NSPs have started to perform experiments to explore whether their CDN use cases can already be addressed with existing CDN implementations. One set of such experiments is documented in [CDNI-EXPERIMENTS]. The conclusions of those experiments are that while some basic limited CDN Interconnection functionality can be achieved with existing CDN technology, the current lack of any standardized CDNI interfaces with the necessary level of functionality such as those discussed in this document is preventing the deployment of CDN Interconnection.

一部のNSPは、CDNの使用例が既存のCDN実装ですでに対処できるかどうかを調査するための実験を開始しました。そのような実験の1つのセットは、[CDNI-EXPERIMENTS]に文書化されています。これらの実験の結論は、いくつかの基本的な制限付きCDN相互接続機能は既存のCDNテクノロジーで実現できる一方で、このドキュメントで説明されているような必要なレベルの機能を備えた標準化されたCDNIインターフェースの現在の欠如が、CDN相互接続の導入を妨げているということです。。

Listed below are the four interfaces required to interconnect a pair of CDNs and that constitute the problem space of CDN Interconnection along with the required functionality of each interface for which standards do not currently exist. As part of the development of the CDNI interfaces, it will also be necessary to agree on common mechanisms for how to identify and name the data objects that are to be interchanged between interconnected CDNs.

以下は、CDNのペアを相互接続するために必要な4つのインターフェースであり、CDN相互接続の問題空間を構成しています。また、現在標準が存在しない各インターフェースに必要な機能も含まれています。 CDNIインターフェースの開発の一環として、相互接続されたCDN間で交換されるデータオブジェクトを識別して名前を付ける方法に関する共通のメカニズムについても合意する必要があります。

The use of the term "interface" is meant to encompass the protocol over which CDNI data representations (e.g., CDNI Metadata objects) are exchanged as well as the specification of the data representations themselves (i.e., what properties/fields each object contains, its structure, etc.).

「インターフェース」という用語の使用は、CDNIデータ表現（CDNIメタデータオブジェクトなど）が交換されるプロトコル、およびデータ表現自体の仕様（つまり、各オブジェクトに含まれるプロパティ/フィールド、その構造など）。

o CDNI Control interface: This interface allows the "CDNI Control" system in interconnected CDNs to communicate. This interface may support the following:

o CDNI制御インターフェース：このインターフェースにより、相互接続されたCDN内の「CDNI制御」システムが通信できるようになります。このインターフェースは、以下をサポートする場合があります。

* Allow bootstrapping of the other CDNI interfaces (e.g., interface address/URL discovery and establishment of security associations).

* 他のCDNIインターフェイスのブートストラップを許可します（たとえば、インターフェイスアドレス/ URLの検出とセキュリティアソシエーションの確立）。

* Allow configuration of the other CDNI interfaces (e.g., Upstream CDN specifies information to be reported through the CDNI Logging interface).

* 他のCDNIインターフェイスの構成を許可します（たとえば、アップストリームCDNは、CDNIログインターフェイスを介して報告される情報を指定します）。

* Allow the Downstream CDN to communicate static (or fairly static) information about its delivery capabilities and policies.

* ダウンストリームCDNがその配信機能とポリシーに関する静的（またはかなり静的）情報を通信できるようにします。

* Allow bootstrapping of the interface between CDNs for content acquisition (even if that interface itself is outside the scope of the CDNI work).

* コンテンツを取得するためにCDN間のインターフェースのブートストラップを許可します（そのインターフェース自体がCDNI作業の範囲外であっても）。

* Allow an Upstream CDN to initiate or request specific actions to be undertaken in the Downstream CDN. For example, to allow an Upstream CDN to initiate content or CDNI Metadata acquisition (pre-positioning) or to request the invalidation or purging of content files and/or CDNI Metadata in a Downstream CDN.

* アップストリームCDNがダウンストリームCDNで実行される特定のアクションを開始または要求できるようにします。たとえば、アップストリームCDNがコンテンツまたはCDNIメタデータの取得（事前配信）を開始したり、ダウンストリームCDNのコンテンツファイルやCDNIメタデータの無効化または削除を要求したりすることができます。

o CDNI Request Routing interface: This interface allows the Request Routing systems in interconnected CDNs to communicate to ensure that an End User request can be (re)directed from an Upstream CDN to a Surrogate in the Downstream CDN, in particular where selection responsibilities may be split across CDNs (for example, the Upstream CDN may be responsible for selecting the Downstream CDN, while the Downstream CDN may be responsible for selecting the actual Surrogate within that Downstream CDN). In particular, the functions of the CDN Request Routing interface may be divided as follows:

o CDNI要求ルーティングインターフェイス：このインターフェイスを使用すると、相互接続されたCDN内の要求ルーティングシステムが通信して、エンドユーザーの要求を上流CDNから下流CDNのサロゲートに（再）リダイレクトできるようにします。 CDN全体（たとえば、アップストリームCDNがダウンストリームCDNの選択を担当し、ダウンストリームCDNがそのダウンストリームCDN内の実際のサロゲートを選択する場合があります）。特に、CDN要求ルーティングインターフェイスの機能は、次のように分割できます。

* A CDNI Request Routing Redirection interface, which allows the Upstream CDN to query the Downstream CDN at request routing time before redirecting the request to the Downstream CDN.

* 要求をダウンストリームCDNにリダイレクトする前に、要求ルーティング時にアップストリームCDNがダウンストリームCDNを照会できるようにするCDNI要求ルーティングリダイレクトインターフェイス。

* A CDNI Footprint & Capabilities advertisement interface, which allows the Downstream CDN to provide to the Upstream CDN (static or dynamic) information (e.g., resources, footprint, load) to facilitate selection of the Downstream CDN by the Upstream CDN Request Routing system when processing subsequent Content Requests from User Agents.

* ダウンストリームCDNがアップストリームCDN（静的または動的）情報（リソース、フットプリント、ロードなど）に提供して、処理時にアップストリームCDNリクエストルーティングシステムによるダウンストリームCDNの選択を容易にするCDNI Footprint＆Capabilities広告インターフェイスユーザーエージェントからの後続のコンテンツリクエスト。

o CDNI Metadata interface: This interface allows the Distribution system in interconnected CDNs to communicate to ensure that CDNI Metadata can be exchanged across CDNs. See Section 1.1 for the definition and examples of CDNI Metadata.

o CDNIメタデータインターフェース：このインターフェースにより、相互接続されたCDN内の配布システムが通信して、CDN間でCDNIメタデータを確実に交換できるようになります。 CDNIメタデータの定義と例については、セクション1.1を参照してください。

o CDNI Logging interface: This interface allows the Logging system in interconnected CDNs to communicate the relevant activity logs in order to allow log-consuming applications to operate in a multi-CDN environment. For example, an Upstream CDN may collect delivery logs from a Downstream CDN in order to perform consolidated charging of the CSP or for settlement purposes across CDNs. Similarly, an Upstream CDN may collect delivery logs from a Downstream CDN in order to provide consolidated reporting and monitoring to the CSP.

o CDNI Loggingインターフェース：このインターフェースを使用すると、相互接続されたCDNのLoggingシステムが関連するアクティビティログを伝達して、ログを消費するアプリケーションをマルチCDN環境で動作させることができます。たとえば、アップストリームCDNは、CSPの統合課金を実行するため、またはCDN全体の決済目的で、ダウンストリームCDNから配信ログを収集する場合があります。同様に、アップストリームCDNは、ダウンストリームCDNから配信ログを収集して、CSPに統合されたレポートと監視を提供します。

Note that the actual grouping of functionalities under these four interfaces is considered tentative at this stage and may be changed after further study (e.g., some subset of functionality may be moved from one interface into another).

これらの4つのインターフェースの下での機能の実際のグループ化は、この段階では暫定的なものと見なされ、さらに調査した後で変更される可能性があることに注意してください（たとえば、機能の一部のサブセットを1つのインターフェースから別のインターフェースに移動する場合があります）。

The above list covers a significant potential problem space, in part because in order to interconnect two CDNs there are several 'touch points' that require standardization. However, it is expected that the CDNI interfaces need not be defined from scratch and instead can reuse or leverage existing protocols to a very significant extent; this is discussed further in Section 4.

上記のリストは、2つのCDNを相互接続するために、標準化を必要とするいくつかの「タッチポイント」があるため、重要な潜在的な問題領域をカバーしています。ただし、CDNIインターフェイスを最初から定義する必要はなく、既存のプロトコルを再利用または活用できることが非常に重要です。これについては、セクション4で詳しく説明します。

The interfaces that form the CDNI problem area are illustrated in Figure 1.

CDNI問題領域を形成するインターフェースを図1に示します。

     --------
    /        \
    |   CSP  |
    \        /
     --------
         *
         *
         *                         /\
         *                        /  \
     ----------------------      |CDNI|        ----------------------
    /     Upstream CDN     \     |    |       /    Downstream CDN    \
    |      +-------------+ | Control Interface| +-------------+      |
    |*******   Control   |<======|====|========>|   Control   *******|
    |*     +------*----*-+ |     |    |       | +-*----*------+     *|
    |*            *    *   |     |    |       |   *    *            *|
    |*     +------*------+ | Logging Interface| +------*------+     *|
    |* *****   Logging   |<======|====|========>|   Logging   ***** *|
    |* *   +-*-----------+ |     |    |       | +-----------*-+   * *|
    |* *     *         *   | Request Routing  |   *         *     * *|
  .....*...+-*---------*-+ |    Interface     | +-*---------*-+...*.*...
  . |* * *** Req-Routing |<======|====|========>| Req-Routing *** * *| .
  . |* * * +-------------+.|     |    |       | +-------------+ * * *| .
  . |* * *                 .  CDNI Metadata   |                 * * *| .
  . |* * * +-------------+ |.   Interface     | +-------------+ * * *| .
  . |* * * | Distribution|<==.===|====|========>| Distribution| * * *| .
  . |* * * |             | |  .   \  /        | |             | * * *| .
  . |* * * |+---------+  | |   .   \/         | |  +---------+| * * *| .
  . |* * ***| +---------+| |    ....Request......+---------+ |*** * *| .
  . |* *****+-|Surrogate|************************|Surrogate|-+***** *| .
  . |*******  +---------+| |   Acquisition    | |+----------+ *******| .
  . |      +-------------+ |                  | +-------*-----+      | .
  . \                      /                  \         *            / .
  .  ----------------------                    ---------*------------  .
  .                                                     *              .
  .                                                     * Delivery     .
  .                                                     *              .
  .                                                  +--*---+          .
  ...............Request.............................| User |..Request..
                                                     | Agent|
                                                     +------+

  <==>  interfaces inside the scope of CDNI
  ****  interfaces outside the scope of CDNI
  ....  interfaces outside the scope of CDNI

Figure 1: A Model for the CDNI Problem Area

図1：CDNI問題領域のモデル

As illustrated in Figure 1, the acquisition of content between interconnected CDNs is out of scope for CDNI; this deserves some additional explanation. The consequence of such a decision is that the CDNI problem space described in this document is focused on only defining the control plane for CDNI, and the CDNI data plane (i.e., the acquisition and distribution of the actual content objects) is out of scope. The rationale for such a decision is that CDNs today typically already use standardized protocols such as HTTP, FTP, rsync, etc. to acquire content from their CSP customers, and it is expected that the same protocols could be used for acquisition between interconnected CDNs. Therefore, the problem of content acquisition is considered already solved, and all that is required with respect to content acquisition from specifications developed by the CDNI working group is to describe within the CDNI Metadata the parameters to use to retrieve the content -- for example, the IP address/hostname to connect to, what protocol to use to retrieve the content, etc.

図1に示すように、相互接続されたCDN間のコンテンツの取得はCDNIの範囲外です。これはいくつかの追加説明に値します。このような決定の結果、このドキュメントで説明するCDNI問題空間は、CDNIのコントロールプレーンの定義のみに焦点が当てられ、CDNIデータプレーン（つまり、実際のコンテンツオブジェクトの取得と配信）は範囲外になります。このような決定の根拠は、今日のCDNは通常、HTTP、FTP、rsyncなどの標準化されたプロトコルを使用してCSP顧客からコンテンツを取得することであり、相互接続されたCDN間の取得に同じプロトコルを使用できることが予想されます。したがって、コンテンツ取得の問題はすでに解決されていると見なされ、CDNIワーキンググループによって開発された仕様からコンテンツを取得するために必要なことは、CDNIメタデータ内でコンテンツを取得するために使用するパラメーターを記述することだけです。たとえば、接続するIPアドレス/ホスト名、コンテンツの取得に使用するプロトコルなど

4. Scoping the CDNI Problem

4. CDNI問題のスコープ

This section outlines how the scope of work addressing the CDNI problem space can be constrained through reuse or leveraging of existing protocols to implement the CDNI interfaces. This discussion is not intended to preempt any working group decision as to the most appropriate protocols, technologies, and solutions to select to realize the CDNI interfaces but is intended as an illustration of the fact that the CDNI interfaces need not be created in a vacuum and that reuse or leverage of existing protocols is likely possible.

このセクションでは、CDNIインターフェイスを実装するために既存のプロトコルを再利用または活用することにより、CDNI問題空間に対処する作業の範囲をどのように制限できるかについて概説します。この説明は、CDNIインターフェイスを実現するために選択する最も適切なプロトコル、テクノロジー、およびソリューションに関するワーキンググループの決定を先取りすることを意図したものではなく、CDNIインターフェイスを真空で作成する必要がないという事実の例示として意図されています。既存のプロトコルの再利用または活用はおそらく可能です。

The four CDNI interfaces (CDNI Control interface, CDNI Request Routing interface, CDNI Metadata interface, and CDNI Logging interface) described in Section 3 within the CDNI problem area are all control plane interfaces operating at the application layer (Layer 7 in the OSI network model). Firstly, since it is not expected that these interfaces would exhibit unique session, transport, or network requirements as compared to the many other existing applications in the Internet, it is expected that the CDNI interfaces will be defined on top of existing session, transport, and network protocols.

CDNI問題領域内のセクション3で説明されている4つのCDNIインターフェース（CDNI制御インターフェース、CDNI要求ルーティングインターフェース、CDNIメタデータインターフェース、およびCDNIロギングインターフェース）は、すべてアプリケーションレイヤー（OSIネットワークモデルのレイヤー7）で動作するコントロールプレーンインターフェースです。）。まず、これらのインターフェースが、インターネットの他の多くの既存のアプリケーションと比較して、固有のセッション、トランスポート、またはネットワーク要件を示すとは予想されないため、CDNIインターフェースは、既存のセッション、トランスポートの上に定義されることが予想されます。およびネットワークプロトコル。

Secondly, although a new application protocol could be designed specifically for CDNI, our analysis below shows that this is unnecessary, and it is recommended that existing application protocols be reused or leveraged (HTTP [RFC2616], the Atom Publishing Protocol [RFC5023], the Extensible Messaging and Presence Protocol (XMPP) [RFC6120], for example) to realize the CDNI interfaces.

次に、新しいアプリケーションプロトコルをCDNI専用に設計することもできますが、以下の分析ではこれが不要であることを示しています。既存のアプリケーションプロトコルを再利用または活用することをお勧めします（HTTP [RFC2616]、Atom Publishing Protocol [RFC5023]、 CDNIインターフェイスを実現するための拡張メッセージングおよびプレゼンスプロトコル（XMPP）[RFC6120]など）。

4.1. CDNI Control Interface

4.1. CDNI制御インターフェース

The CDNI Control interface allows the Control system in interconnected CDNs to communicate. The exact inter-CDN control functionality required to be supported by the CDNI Control interface is less well defined than the other three CDNI interfaces at this time.

CDNI制御インターフェースにより、相互接続されたCDN内の制御システムが通信できるようになります。現在のところ、CDNI制御インターフェースでサポートする必要のある正確なCDN間制御機能は、他の3つのCDNIインターフェースほど明確に定義されていません。

It is expected that for the Control interface, as for the other CDNI interfaces, existing protocols can be reused or leveraged.

制御インターフェースでは、他のCDNIインターフェースと同様に、既存のプロトコルを再利用または活用できることが期待されています。

4.2. CDNI Request Routing Interface

4.2. CDNI要求ルーティングインターフェイス

The CDNI Request Routing interface enables a Request Routing function in an Upstream CDN to query a Request Routing function in a Downstream CDN to determine if the Downstream CDN is able (and willing) to accept the delegated Content Request. It also allows the Downstream CDN to control what should be returned to the User Agent in the redirection message by the upstream Request Routing function.

CDNIリクエストルーティングインターフェイスを使用すると、アップストリームCDNのリクエストルーティング機能がダウンストリームCDNのリクエストルーティング機能にクエリを送信し、ダウンストリームCDNが委任されたコンテンツリクエストを受け入れることができるかどうかを判断できます。また、ダウンストリームCDNは、アップストリームの要求ルーティング機能によってリダイレクトメッセージでユーザーエージェントに返されるものを制御できます。

The CDNI Request Routing interface is therefore a fairly straightforward request/response interface and could be implemented over any number of request/response protocols. For example, it may be implemented as a WebService using one of the common WebServices methodologies (Extensible Markup Language-Remote Procedure Calling (XML-RPC), HTTP query to a known URI, etc.). This removes the need for the CDNI working group to define a new protocol for the request/ response element of the CDNI Request Routing interface.

したがって、CDNI要求ルーティングインターフェイスは、かなり単純な要求/応答インターフェイスであり、任意の数の要求/応答プロトコルを介して実装できます。たとえば、一般的なWebServices手法の1つ（拡張マークアップ言語-リモートプロシージャコール（XML-RPC）、既知のURIへのHTTPクエリなど）を使用してWebServiceとして実装できます。これにより、CDNI作業グループがCDNI要求ルーティングインターフェイスの要求/応答要素に新しいプロトコルを定義する必要がなくなります。

Additionally, as discussed in Section 3, the CDNI Request Routing interface is also expected to enable a Downstream CDN to provide to the Upstream CDN (static or dynamic) information (e.g., resources, footprint, load) to facilitate selection of the Downstream CDN by the Upstream CDN Request Routing system when processing subsequent Content Requests from User Agents. It is expected that such functionality of the CDNI request routing could be specified by the CDNI working group with significant leveraging of existing IETF protocols supporting the dynamic distribution of reachability information (for example, by leveraging existing routing protocols) or supporting application-level queries for topological information (for example, by leveraging Application-Layer Traffic Optimization (ALTO) [RFC5693]).

さらに、セクション3で説明したように、CDNI要求ルーティングインターフェイスは、ダウンストリームCDNがアップストリームCDN（静的または動的）情報（リソース、フットプリント、ロードなど）に提供して、ダウンストリームCDNの選択を容易にすることも期待されています。ユーザーエージェントからの後続のコンテンツ要求を処理するときのアップストリームCDN要求ルーティングシステム。 CDNIリクエストルーティングのこのような機能は、到達可能性情報の動的配布をサポートする既存のIETFプロトコルを大幅に活用する（たとえば、既存のルーティングプロトコルを活用する）か、アプリケーションレベルのクエリをサポートするCDNIワーキンググループによって指定できると予想されます。トポロジー情報（たとえば、アプリケーション層トラフィック最適化（ALTO）[RFC5693]を活用することによる）。

4.3. CDNI Metadata Interface

4.3. CDNIメタデータインターフェイス

The CDNI Metadata interface enables the Distribution system in a Downstream CDN to request CDNI Metadata from an Upstream CDN so that the Downstream CDN can properly process and respond to redirection requests received over the CDNI Request Routing interface and Content Requests received directly from User Agents.

CDNIメタデータインターフェイスを使用すると、ダウンストリームCDNの配布システムがアップストリームCDNからCDNIメタデータを要求できるようになるため、ダウンストリームCDNは、CDNI要求ルーティングインターフェイスを介して受信したリダイレクト要求と、ユーザーエージェントから直接受信したコンテンツ要求を適切に処理および応答できます。

The CDNI Metadata interface is therefore similar to the CDNI Request Routing interface because it is a request/response interface with the potential addition that CDNI Metadata search may have more complex semantics than a straightforward Request Routing redirection request. Therefore, like the CDNI Request Routing interface, the CDNI Metadata interface may be implemented as a WebService using one of the common WebServices methodologies (XML-RPC, HTTP query to a known URI, etc.) or possibly using other existing protocols such as XMPP [RFC6120]. This removes the need for the CDNI working group to define a new protocol for the request/response element of the CDNI Metadata interface.

したがって、CDNIメタデータインターフェイスは、CDNIリクエストルーティングインターフェイスと似ています。これは、CDNIメタデータ検索に、単純なリクエストルーティングリダイレクトリクエストよりも複雑なセマンティクスが追加される可能性があるリクエスト/レスポンスインターフェイスです。したがって、CDNI要求ルーティングインターフェイスと同様に、CDNIメタデータインターフェイスは、一般的なWebServices手法（XML-RPC、既知のURIへのHTTPクエリなど）の1つを使用して、またはXMPPなどの他の既存のプロトコルを使用して、WebServiceとして実装できます。 [RFC6120]。これにより、CDNIワーキンググループが、CDNIメタデータインターフェイスの要求/応答要素の新しいプロトコルを定義する必要がなくなります。

4.4. CDNI Logging Interface

4.4. CDNIログインターフェイス

The CDNI Logging interface enables details of content distribution and delivery activities to be exchanged between interconnected CDNs -- for example, the exchange of log records related to the delivery of content, similar to the log records recorded in a web server's access log.

CDNI Loggingインターフェースを使用すると、相互に接続されたCDN間でコンテンツの配布と配信アクティビティの詳細を交換できます。たとえば、Webサーバーのアクセスログに記録されたログレコードと同様に、コンテンツの配信に関連するログレコードを交換できます。

Several protocols already exist that could potentially be used to exchange CDNI logs between interconnected CDNs, including the Simple Network Management Protocol (SNMP), syslog, FTP (and secure variants), HTTP POST, etc.

Simple Network Management Protocol（SNMP）、syslog、FTP（およびセキュアバリアント）、HTTP POSTなど、相互接続されたCDN間でCDNIログを交換するために使用できる可能性のあるいくつかのプロトコルがすでに存在します。

5. Security Considerations

5. セキュリティに関する考慮事項

Distribution of content by a CDN comes with a range of security considerations, such as how to enforce control of access to the content by End Users in line with the CSP policy, or how to trust the logging information generated by the CDN for the purposes of charging the CSP. These security aspects are already dealt with by CDN Providers and CSPs today in the context of standalone CDNs. However, interconnection of CDNs introduces a new set of security considerations by extending the trust model to a chain of trust (i.e., the CSP "trusts" a CDN that "trusts" another CDN). The mechanisms used to mitigate these risks in multi-CDN environments may be similar to those used in the single-CDN case, but their suitability in this more complex environment must be validated.

CDNによるコンテンツの配布には、CSPポリシーに従ってエンドユーザーによるコンテンツへのアクセス制御を実施する方法や、目的のためにCDNによって生成されたログ情報を信頼する方法など、さまざまなセキュリティ上の考慮事項が付属しています。 CSPの充電。これらのセキュリティの側面は、スタンドアロンCDNのコンテキストで、現在CDNプロバイダーとCSPによって既に処理されています。ただし、CDNの相互接続により、信頼モデルを信頼チェーンに拡張することにより、新しい一連のセキュリティに関する考慮事項が導入されます（つまり、CSPは、別のCDNを「信頼する」CDNを「信頼する」）。マルチCDN環境でこれらのリスクを軽減するために使用されるメカニズムは、シングルCDNの場合で使用されるメカニズムと似ている可能性がありますが、このより複雑な環境での適切性を検証する必要があります。

The interconnection of CDNs may also introduce additional privacy considerations on top of those that apply to the single-CDN case. In a multi-CDN environment, the different CDNs may reside in different legal regimes that require differing privacy requirements to be enforced. Such privacy requirements may impact the granularity of information that can be exchanged across the CDNI interfaces. For example, the Logging system in a Downstream CDN may need to apply some degree of anonymization, obfuscation, or even the complete removal of some fields before exchanging log records containing details of End User deliveries with an Upstream CDN.

CDNの相互接続は、単一CDNの場合に適用されるものに加えて、プライバシーに関する追加の考慮事項を導入する場合もあります。マルチCDN環境では、異なるCDNが異なる法的制度に属し、異なるプライバシー要件を適用する必要があります。このようなプライバシー要件は、CDNIインターフェイス間で交換できる情報の粒度に影響を与える可能性があります。たとえば、ダウンストリームCDNのロギングシステムは、エンドユーザー配信の詳細を含むログレコードをアップストリームCDNと交換する前に、ある程度の匿名化、難読化、または一部のフィールドの完全な削除を適用する必要がある場合があります。

Maintaining the security of the content itself, its associated metadata (including delivery policies), and the CDNs distributing and delivering it, are critical requirements for both CDN Providers and CSPs, and the CDN Interconnection interfaces must provide sufficient mechanisms to maintain the security of the overall system of interconnected CDNs as well as the information (content, metadata, logs, etc.) distributed and delivered through any set of interconnected CDNs.

コンテンツ自体、関連するメタデータ（配信ポリシーを含む）、およびコンテンツの配布と配信のセキュリティを維持することは、CDNプロバイダーとCSPの両方にとって重要な要件であり、CDN相互接続インターフェースは、セキュリティを維持するための十分なメカニズムを提供する必要があります。相互接続されたCDNのシステム全体と、相互接続されたCDNのセットを介して配布および配信される情報（コンテンツ、メタデータ、ログなど）。

5.1. Security of the CDNI Control Interface

5.1. CDNIコントロールインターフェイスのセキュリティ

Information exchanged between interconnected CDNs over this interface is of a sensitive nature. A pair of CDNs use this interface to allow bootstrapping of all the other CDNI interfaces, possibly including establishment of the mechanisms for securing these interfaces. Therefore, corruption of that interface may result in corruption of all other interfaces. Using this interface, an Upstream CDN may pre-position or delete content or metadata in a Downstream CDN, a Downstream CDN may provide administrative information to an Upstream CDN, etc. All of these operations require that the peer CDNs are appropriately authenticated and that the confidentiality and integrity of information flowing between them can be ensured.

このインターフェースを介して相互接続されたCDN間で交換される情報は、機密性の高い性質のものです。 CDNのペアは、このインターフェイスを使用して、他のすべてのCDNIインターフェイスのブートストラップを可能にします。これには、これらのインターフェイスを保護するためのメカニズムの確立も含まれます。したがって、そのインターフェイスが破損すると、他のすべてのインターフェイスが破損する可能性があります。このインターフェースを使用して、アップストリームCDNがダウンストリームCDNのコンテンツまたはメタデータを事前配信または削除したり、ダウンストリームCDNがアップストリームCDNに管理情報を提供したりできます。これらの操作はすべて、ピアCDNが適切に認証され、それらの間を流れる情報の機密性と完全性を保証することができます。

5.2. Security of the CDNI Request Routing Interface

5.2. CDNI要求ルーティングインターフェイスのセキュリティ

Appropriate levels of authentication and confidentiality must be used in this interface because it allows an Upstream CDN to query the Downstream CDN in order to redirect requests, and conversely, allows the Downstream CDN to influence the Upstream CDN's Request Routing function.

このインターフェースでは、適切なレベルの認証と機密性を使用する必要があります。これにより、要求をリダイレクトするためにアップストリームCDNがダウンストリームCDNを照会できるようになり、逆に、ダウンストリームCDNがアップストリームCDNの要求ルーティング機能に影響を与えることができるようになります。

In the absence of appropriate security on this interface, a rogue Upstream CDN could inundate Downstream CDNs with bogus requests or have the Downstream CDN send the rogue Upstream CDN private information. Also, a rogue Downstream CDN could influence the Upstream CDN so the Upstream CDN redirects requests to the rogue Downstream CDN or another Downstream CDN in order to, for example, attract additional delivery revenue.

このインターフェースに適切なセキュリティがない場合、不正なアップストリームCDNは、不正なリクエストでダウンストリームCDNを氾濫させるか、ダウンストリームCDNに不正なアップストリームCDNプライベート情報を送信させる可能性があります。また、不正なダウンストリームCDNがアップストリームCDNに影響を与える可能性があるため、アップストリームCDNは、リクエストを不正なダウンストリームCDNまたは別のダウンストリームCDNにリダイレクトして、たとえば、追加の配信収益を引き付けます。

5.3. Security of the CDNI Metadata Interface

5.3. CDNIメタデータインターフェイスのセキュリティ

This interface allows a Downstream CDN to request CDNI Metadata from an Upstream CDN, and therefore the Upstream CDN must ensure that the former is appropriately authenticated before sending the data. Conversely, a Downstream CDN must authenticate an Upstream CDN before requesting metadata to insulate itself from poisoning by rogue Upstream CDNs. The confidentiality and integrity of the information exchanged between the peers must be protected.

このインターフェイスを使用すると、ダウンストリームCDNがアップストリームCDNからCDNIメタデータをリクエストできるため、アップストリームCDNは、データを送信する前に前者が適切に認証されていることを確認する必要があります。逆に、ダウンストリームCDNは、不正なアップストリームCDNによるポイズニングから隔離するためにメタデータを要求する前に、アップストリームCDNを認証する必要があります。ピア間で交換される情報の機密性と完全性を保護する必要があります。

5.4. Security of the CDNI Logging Interface

5.4. CDNIログインターフェイスのセキュリティ

Logging data consists of potentially sensitive information (which End User accessed which media resource, IP addresses of End Users, potential names and subscriber account information, etc.). Confidentiality of this information must be protected as log records are moved between CDNs. This information may also be sensitive from the viewpoint that it can be the basis for charging across CDNs. Therefore, appropriate levels of protection are needed against corruption, duplication, and loss of this information.

ロギングデータは、潜在的に機密性の高い情報（どのエンドユーザーがどのメディアリソースにアクセスしたか、エンドユーザーのIPアドレス、潜在的な名前とサブスクライバーアカウント情報など）で構成されます。ログレコードはCDN間で移動されるため、この情報の機密性を保護する必要があります。この情報は、CDN全体の課金の基礎となる可能性があるという観点からも機密性が高い場合があります。したがって、この情報の破損、複製、および損失に対する適切なレベルの保護が必要です。

6. Acknowledgements

6. 謝辞

The authors would like to thank Andre Beck, Gilles Bertrand, Mark Carlson, Bruce Davie, David Ferguson, Yiu Lee, Kent Leung, Will Li, Kevin Ma, Julien Maisonneuve, Guy Meador, Larry Peterson, Emile Stephan, Oskar van Deventer, Mahesh Viveganandhan, and Richard Woundy for their review comments and contributions to the text.

著者は、Andre Beck、Gilles Bertrand、Mark Carlson、Bruce Davie、David Ferguson、Yiu Lee、Kent Leung、Will Li、Kevin Ma、Julien Maisonneuve、Guy Meador、Larry Peterson、Emile Stephan、Oskar van Deventer、Maheshに感謝します。 Viveganandhan、およびRichard Woundyのレビューコメントおよび本文への貢献。

7. Informative References

7. 参考引用

[ALTO-CDN-USE-CASES] Niven-Jenkins, B., Ed., Watson, G., Bitar, N., Medved, J., and S. Previdi, "Use Cases for ALTO within CDNs", Work in Progress, June 2012.

[ALTO-CDN-USE-CASES] Niven-Jenkins、B.、Ed。、Watson、G.、Bitar、N.、Medved、J。、およびS. Previdi、「CDN内のALTOの使用例」、Work in進捗状況、2012年6月。

[ALTO-Charter] "IETF ALTO WG Charter", <http://datatracker.ietf.org/wg/alto/charter/>.

[ALTO-Charter]「IETF ALTO WG Charter」、<http://datatracker.ietf.org/wg/alto/charter/>。

[CDNI-EXPERIMENTS] Bertrand, G., Ed., Le Faucheur, F., and L. Peterson, "Content Distribution Network Interconnection (CDNI) Experiments", Work in Progress, February 2012.

[CDNI-EXPERIMENTS] Bertrand、G.、Ed。、Le Faucheur、F.、and L. Peterson、 "Content Distribution Network Interconnection（CDNI）Experiments"、Work in Progress、2012年2月。

[CDNI-USE-CASES] Bertrand, G., Ed., Emile, S., Burbridge, T., Eardley, P., Ma, K., and G. Watson, "Use Cases for Content Delivery Network Interconnection", Work in Progress, August 2012.

[CDNI-USE-CASES] Bertrand、G.、Ed。、Emile、S.、Burbridge、T.、Eardley、P.、Ma、K.、and G. Watson、 "Use Cases for Content Delivery Network Interconnection"、進行中の作業、2012年8月。

[DECADE-Charter] "IETF DECADE WG Charter", <http://datatracker.ietf.org/wg/decade/charter/>.

[DECADE-Charter]「IETF DECADE WG Charter」、<http://datatracker.ietf.org/wg/decade/charter/>。

[P2PRG-CDNI] Davie, B. and F. Le Faucheur, "Interconnecting CDNs aka 'Peering Peer-to-Peer'", March 2010, <http://www.ietf.org/proceedings/77/slides/P2PRG-2.pdf>.

[P2PRG-CDNI]デイビー、B。、およびF.ルフォシェール、「相互接続CDN、別名「ピアリングピアツーピア」」、2010年3月、<http://www.ietf.org/proceedings/77/slides/P2PRG -2.pdf>。

[PPSP-Charter] "IETF PPSP WG Charter", <http://datatracker.ietf.org/wg/ppsp/charter/>.

[PPSP-Charter]「IETF PPSP WG Charter」、<http://datatracker.ietf.org/wg/ppsp/charter/>。

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「ハイパーテキスト転送プロトコル-HTTP / 1.1」、RFC 2616、1999年6月。

[RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", RFC 3040, January 2001.

[RFC3040]クーパー、I。、メルブ、I。、およびG.トムリンソン、「インターネットWebレプリケーションおよびキャッシング分類法」、RFC 3040、2001年1月。

[RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model for Content Internetworking (CDI)", RFC 3466, February 2003.

[RFC3466] Day、M.、Cain、B.、Tomlinson、G。、およびP. Rzewski、「A Model for Content Internetworking（CDI）」、RFC 3466、2003年2月。

[RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content Internetworking (CDI) Scenarios", RFC 3570, July 2003.

[RFC3570] Rzewski、P.、Day、M。、およびD. Gilletti、「Content Internetworking（CDI）Scenarios」、RFC 3570、2003年7月。

[RFC5023] Gregorio, J., Ed., and B. de hOra, Ed., "The Atom Publishing Protocol", RFC 5023, October 2007.

[RFC5023]グレゴリオ、J。、およびB. de hOra、編、「The Atom Publishing Protocol」、RFC 5023、2007年10月。

[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, October 2009.

[RFC5693] Seedorf、J。およびE. Burger、「Application-Layer Traffic Optimization（ALTO）Problem Statement」、RFC 5693、2009年10月。

[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.

[RFC6120] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）：Core」、RFC 6120、2011年3月。

[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, October 2011.

[RFC6390] Clark、A。およびB. Claise、「新しいパフォーマンスメトリック開発を検討するためのガイドライン」、BCP 170、RFC 6390、2011年10月。

[TAXONOMY] Pathan, A. and R. Buyya, "A Taxonomy and Survey of Content Delivery Networks", 2007, <http://www.cloudbus.org/reports/CDN-Taxonomy.pdf>.

[TAXONOMY] Pathan、A。およびR. Buyya、「A Taxonomy and Survey of Content Delivery Networks」、2007、<http://www.cloudbus.org/reports/CDN-Taxonomy.pdf>。

Appendix A. Design Considerations for Realizing the CDNI Interfaces

付録A. CDNIインターフェイスを実現するための設計上の考慮事項

This section expands on how CDNI interfaces can reuse and leverage existing protocols before describing each CDNI interface individually and highlighting example candidate protocols that could be considered for reuse or leveraging to implement the CDNI interfaces. However, the options discussed here are purely examples and do not present any consensus on protocols to be used later on.

このセクションでは、各CDNIインターフェースを個別に説明する前に、CDNIインターフェースが既存のプロトコルをどのように再利用および活用できるかを詳しく説明し、CDNIインターフェースの実装に再利用または活用できると考えられるプロトコルの例を示します。ただし、ここで説明するオプションは純粋な例であり、後で使用するプロトコルについての合意はありません。

A.1. CDNI Control Interface

A.1. CDNI制御インターフェース

However, as discussed in Section 3, the CDNI Control interface may be required to support functionality similar to the following:

ただし、セクション3で説明したように、CDNIコントロールインターフェイスは、次のような機能をサポートする必要がある場合があります。

o Allow an Upstream CDN and Downstream CDN to establish, update, or terminate their CDNI interconnection.

o アップストリームCDNおよびダウンストリームCDNがCDNI相互接続を確立、更新、または終了できるようにします。

o Allow bootstrapping of the other CDNI interfaces (e.g., protocol address discovery and establishment of security associations).

o 他のCDNIインターフェイスのブートストラップを許可します（プロトコルアドレスの検出やセキュリティアソシエーションの確立など）。

o Allow configuration of the other CDNI interfaces (e.g., Upstream CDN specifies information to be reported through the CDNI Logging interface).

o 他のCDNIインターフェイスの構成を許可します（たとえば、アップストリームCDNは、CDNIログインターフェイスを介して報告される情報を指定します）。

o Allow the Downstream CDN to communicate static information about its delivery capabilities, resources, and policies.

o ダウンストリームCDNが配信機能、リソース、およびポリシーに関する静的情報を通信できるようにします。

o Allow bootstrapping of the interface between CDNs for content acquisition (even if that interface itself is outside the scope of the CDNI work).

o コンテンツを取得するためにCDN間のインターフェースのブートストラップを許可します（そのインターフェース自体がCDNI作業の範囲外であっても）。

It is expected that for the Control interface, as for the other CDNI interfaces, existing protocols can be reused or leveraged. Those will be considered once the requirements for the Control interface have been refined.

制御インターフェースでは、他のCDNIインターフェースと同様に、既存のプロトコルを再利用または活用できることが期待されています。これらは、コントロールインターフェイスの要件が改善された後で検討されます。

A.2. CDNI Request Routing Interface

A.2. CDNI要求ルーティングインターフェイス

The CDNI Request Routing interface enables a Request Routing function in an Upstream CDN to query a Request Routing function in a Downstream CDN to determine if the Downstream CDN is able (and willing) to accept the delegated Content Request and to allow the Downstream CDN to control what the upstream Request Routing function should return to the User Agent in the redirection message.

CDNIリクエストルーティングインターフェイスにより、アップストリームCDNのリクエストルーティング機能がダウンストリームCDNのリクエストルーティング機能にクエリを送信し、ダウンストリームCDNが委任されたコンテンツリクエストを受け入れることができるかどうかを判断し、ダウンストリームCDNが制御できるようにします。アップストリームのリクエストルーティング機能がリダイレクトメッセージでユーザーエージェントに返すもの。

Therefore, the CDNI Request Routing interface needs to offer a mechanism for an Upstream CDN to issue a "Redirection Request" to a Downstream CDN. The Request Routing interface needs to be able to support scenarios where the initial User Agent request to the Upstream CDN is received over DNS as well as over a content-specific application protocol (e.g., HTTP, the Real Time Streaming Protocol (RTSP), the Real Time Messaging Protocol (RTMP), etc.).

したがって、CDNI要求ルーティングインターフェイスは、アップストリームCDNがダウンストリームCDNに「リダイレクト要求」を発行するためのメカニズムを提供する必要があります。リクエストルーティングインターフェースは、アップストリームCDNへの最初のユーザーエージェントリクエストがDNSおよびコンテンツ固有のアプリケーションプロトコル（HTTP、リアルタイムストリーミングプロトコル（RTSP）など）を介して受信されるシナリオをサポートできる必要があります。リアルタイムメッセージングプロトコル（RTMP）など）。

Therefore, a Redirection Request is expected to contain information such as:

したがって、リダイレクト要求には次のような情報が含まれていることが予想されます。

o The protocol (e.g., DNS, HTTP) over which the Upstream CDN received the initial User Agent request.

o アップストリームCDNが最初のユーザーエージェントリクエストを受信したプロトコル（DNS、HTTPなど）。

o Additional details of the User Agent request that are required to perform effective Request Routing by the Downstream CDN. For DNS, this would typically be the IP address of the DNS resolver making the request on behalf of the User Agent. For requests received over content-specific application protocols, the Redirection Request could contain significantly more information related to the original User Agent request but at a minimum is expected to include the User Agent's IP address, the equivalent of the HTTP Host header, and the equivalent of the HTTP abs_path as defined in [RFC2616].

o ダウンストリームCDNによる効果的な要求ルーティングを実行するために必要なユーザーエージェント要求の追加の詳細。 DNSの場合、これは通常、ユーザーエージェントに代わってリクエストを行うDNSリゾルバーのIPアドレスです。コンテンツ固有のアプリケーションプロトコルを介して受信したリクエストの場合、リダイレクトリクエストには元のユーザーエージェントリクエストに関連するかなり多くの情報が含まれる可能性がありますが、少なくともユーザーエージェントのIPアドレス、HTTPホストヘッダーに相当するもの、および同等のものが含まれていることが予想されます[RFC2616]で定義されているHTTP abs_pathの。

It should be noted that the CDNI architecture needs to consider that a Downstream CDN may receive requests from User Agents without first receiving a Redirection Request from an Upstream CDN for the corresponding User Agent request because, for example:

CDNIアーキテクチャは、ダウンストリームCDNがユーザーエージェントからリクエストを受信する可能性があることを考慮する必要があることに注意してください。最初に、対応するユーザーエージェントリクエストのアップストリームCDNからリダイレクトリクエストを受信します。

o User Agents (or DNS resolvers) may cache DNS or application responses from Request Routers.

o ユーザーエージェント（またはDNSリゾルバー）は、リクエストルーターからのDNSまたはアプリケーションの応答をキャッシュできます。

o Responses to Redirection Requests over the Request Routing interface may be cacheable.

o 要求ルーティングインターフェイスを介したリダイレクト要求への応答は、キャッシュ可能である場合があります。

o Some CDNs may rely on simple coarse policies, e.g., CDN B agrees to always serve CDN A's delegated redirection requests, in which case the necessary redirection details are exchanged out of band (of the CDNI interfaces), e.g., configured.

o 一部のCDNは、単純な大まかなポリシーに依存している場合があります。たとえば、CDN Bは、CDN Aの委任されたリダイレクト要求を常に提供することに同意します。

On receiving a Redirection Request, the Downstream CDN will use the information provided in the request to determine if it is able (and willing) to accept the delegated Content Request and needs to return the result of its decision to the Upstream CDN.

リダイレクト要求を受信すると、ダウンストリームCDNは、要求で提供された情報を使用して、委任されたコンテンツ要求を受け入れることができる（そして喜んで）かどうかを判断し、その決定の結果をアップストリームCDNに返す必要があります。

Thus, a Redirection Response from the Downstream CDN is expected to contain information such as:

したがって、ダウンストリームCDNからのリダイレクト応答には、次のような情報が含まれていることが予想されます。

o Status code indicating acceptance or rejection (possibly with accompanying reasons).

o 承認または拒否を示すステータスコード（付随する理由が考えられます）。

o Information to allow redirection by the Upstream CDN. In the case of DNS-based request routing, this is expected to include the equivalent of a DNS record(s) (e.g., a CNAME) that the Upstream CDN should return to the requesting DNS resolver. In the case of application-based request routing, this is expected to include the information necessary to construct the application-specific redirection response(s) to return to the requesting User Agent. For HTTP requests from User Agents, this could include a URI that the Upstream CDN could return in an HTTP 3xx response.

o アップストリームCDNによるリダイレクトを許可する情報。 DNSベースのリクエストルーティングの場合、これには、アップストリームCDNがリクエスト元のDNSリゾルバーに返す必要があるDNSレコード（CNAMEなど）と同等のものが含まれることが期待されます。アプリケーションベースの要求ルーティングの場合、これには、要求元のユーザーエージェントに戻るためのアプリケーション固有のリダイレクト応答を構築するために必要な情報が含まれていると予想されます。ユーザーエージェントからのHTTPリクエストの場合、これには、アップストリームCDNがHTTP 3xx応答で返すことができるURIを含めることができます。

The CDNI Request Routing interface is therefore a fairly straightforward request/response interface and could be implemented over any number of request/response protocols. For example, it may be implemented as a WebService using one of the common WebServices methodologies (XML-RPC, HTTP query to a known URI, etc.). This removes the need for the CDNI working group to define a new protocol for the request/response element of the CDNI Request Routing interface. Thus, the CDNI working group would be left only with the task of specifying:

したがって、CDNI要求ルーティングインターフェイスは、かなり単純な要求/応答インターフェイスであり、任意の数の要求/応答プロトコルを介して実装できます。たとえば、一般的なWebServices手法（XML-RPC、既知のURIへのHTTPクエリなど）の1つを使用してWebServiceとして実装できます。これにより、CDNIワーキンググループが、CDNI要求ルーティングインターフェイスの要求/応答要素に新しいプロトコルを定義する必要がなくなります。したがって、CDNIワーキンググループには、以下を指定するタスクのみが残されます。

o The recommended request/response protocol to use along with any additional semantics and procedures that are specific to the CDNI Request Routing interface (e.g., handling of malformed requests/ responses).

o CDNIリクエストルーティングインターフェースに固有の追加のセマンティクスと手順（不正なリクエスト/レスポンスの処理など）とともに使用する推奨のリクエスト/レスポンスプロトコル。

o The syntax (i.e., representation/encoding) of the redirection requests and responses.

o リダイレクト要求と応答の構文（つまり、表現/エンコード）。

o The semantics (i.e., meaning and expected contents) of the redirection requests and responses.

o リダイレクト要求と応答のセマンティクス（つまり、意味と期待される内容）。

さらに、セクション3で説明したように、CDNI要求ルーティングインターフェイスは、ダウンストリームCDNがアップストリームCDN（静的または動的）情報（リソース、フットプリント、ロードなど）に提供して、ダウンストリームCDNの選択を容易にすることも期待されています。ユーザーエージェントからの後続のコンテンツ要求を処理するときのアップストリームCDN要求ルーティングシステム。 CDNI要求ルーティングのこのような機能は、到達可能性情報の動的配布をサポートする既存のIETFプロトコルを大幅に活用して（たとえば、既存のルーティングプロトコルを活用して）、またはアプリケーションレベルのクエリをサポートして、CDNIワーキンググループによって指定できると予想されます。トポロジー情報（例えば、ALTOの活用による）。

A.3. CDNI Metadata Interface

A.3. CDNIメタデータインターフェイス

The CDNI Metadata interface enables the Distribution system in a Downstream CDN to obtain CDNI Metadata from an Upstream CDN so that the Downstream CDN can properly process and respond to:

CDNIメタデータインターフェースを使用すると、ダウンストリームCDNの配信システムは、アップストリームCDNからCDNIメタデータを取得できるため、ダウンストリームCDNは適切に処理および応答できます。

o Redirection Requests received over the CDNI Request Routing interface.

o CDNI要求ルーティングインターフェイスを介して受信したリダイレクト要求。

o Content Requests received directly from User Agents.

o ユーザーエージェントから直接受け取ったコンテンツ要求。

The CDNI Metadata interface needs to offer a mechanism for an Upstream CDN to:

CDNIメタデータインターフェースは、アップストリームCDNが次のことを行うためのメカニズムを提供する必要があります。

o Distribute/update/remove CDNI Metadata to a Downstream CDN.

o CDNIメタデータをダウンストリームCDNに配布/更新/削除します。

and/or to allow a Downstream CDN to:

ダウンストリームCDNが次のことを行えるようにする：

o Make direct requests for CDNI Metadata objects.

o CDNIメタデータオブジェクトを直接リクエストします。

o Make recursive requests for CDNI Metadata -- for example, to enable a Downstream CDN to walk down a tree of objects with inter-object relationships.

o CDNIメタデータに対して再帰的なリクエストを作成します。たとえば、ダウンストリームCDNがオブジェクト間の関係を持つオブジェクトのツリーをウォークダウンできるようにします。

Thus, the CDNI working group would be left only with the task of specifying:

したがって、CDNIワーキンググループには、以下を指定するタスクのみが残されます。

o The recommended request/response protocol to use along with any additional semantics that are specific to the CDNI Metadata interface (e.g., handling of malformed requests/responses).

o CDNIメタデータインターフェースに固有の追加のセマンティクス（不正な要求/応答の処理など）とともに使用することをお勧めする要求/応答プロトコル。

o The syntax (i.e., representation/encoding) of the CDNI Metadata objects that will be exchanged over the interface.

o インターフェースを介して交換されるCDNIメタデータオブジェクトの構文（つまり、表現/エンコード）。

o The semantics (i.e., meaning and expected contents) of the individual properties of a Metadata object.

o Metadataオブジェクトの個々のプロパティのセマンティクス（つまり、意味と期待される内容）。

o How the relationships between different CDNI Metadata objects are represented.

o 異なるCDNIメタデータオブジェクト間の関係を表す方法。

A.4. CDNI Logging Interface

A.4. CDNIログインターフェイス

The CDNI Logging interface enables details of content distribution and delivery activities to be exchanged between interconnected CDNs, such as log records related to the delivery of content (similar to the log records recorded in a web server's access log).

CDNIロギングインターフェイスを使用すると、コンテンツの配信に関連するログレコード（Webサーバーのアクセスログに記録されるログレコードと同様）など、相互接続されたCDN間でコンテンツの配信と配信アクティビティの詳細を交換できます。

Within CDNs today, log records are used for a variety of purposes. Specifically, CDNs use logs to generate Call Data Records (CDRs) for passing to billing and payment systems and to real-time (and near real-time) analytics systems. Such applications place requirements on the CDNI Logging interface to support guaranteed and timely delivery of log messages between interconnected CDNs. It may also be necessary to be able to prove the integrity of received log messages.

今日のCDN内では、ログレコードはさまざまな目的で使用されます。具体的には、CDNはログを使用して、請求および支払いシステムとリアルタイム（およびほぼリアルタイム）の分析システムに渡すためのコールデータレコード（CDR）を生成します。このようなアプリケーションは、相互接続されたCDN間でのログメッセージの保証されたタイムリーな配信をサポートするために、CDNI Loggingインターフェイスに要件を課します。受信したログメッセージの整合性を証明できる必要がある場合もあります。

Several protocols already exist that could potentially be used to exchange CDNI logs between interconnected CDNs, including SNMP traps, syslog, FTP, HTTP POST, etc., although it is likely that some of the candidate protocols may not be well suited to meet all the requirements of CDNI. For example, SNMP traps pose scalability concerns, and SNMP does not support guaranteed delivery of traps and therefore could result in log records being lost and the consequent CDRs and billing records for that content delivery not being produced, as well as that content delivery being invisible to any analytics platforms.

SNMPトラップ、syslog、FTP、HTTP POSTなど、相互接続されたCDN間でCDNIログを交換するために使用できる可能性のあるいくつかのプロトコルがすでに存在しますが、候補プロトコルの一部はすべてのプロトコルを満たすのに適していない可能性がありますCDNIの要件。たとえば、SNMPトラップはスケーラビリティの問題を引き起こし、SNMPはトラップの保証された配信をサポートしていないため、ログレコードが失われ、その結果のコンテンツ配信のCDRと請求レコードが作成されず、コンテンツ配信が見えなくなります。あらゆる分析プラットフォームに。

Although it is not necessary to define a new protocol for exchanging logs across the CDNI Logging interface, the CDNI working group would still need to specify:

CDNI Loggingインターフェースを介してログを交換するための新しいプロトコルを定義する必要はありませんが、CDNIワーキンググループは以下を指定する必要があります。

o The recommended protocol to use.

o 使用する推奨プロトコル。

o A default set of log fields and of their syntax and semantics. Today there is no standard set of common log fields across different content delivery protocols, and in some cases there is not even a standard set of log field names and values for different implementations of the same delivery protocol.

o ログフィールドとその構文およびセマンティクスのデフォルトセット。現在、さまざまなコンテンツ配信プロトコルに共通する共通のログフィールドのセットはなく、同じ配信プロトコルの異なる実装に対するログフィールド名と値の標準的なセットさえない場合もあります。

o A default set of conditions that trigger log records to be generated.

o ログレコードの生成をトリガーするデフォルトの条件セット。

Appendix B. Additional Material

付録B.追加資料

This section records related information that was produced as part of defining the CDNI problem statement.

このセクションでは、CDNI問題ステートメントの定義の一部として作成された関連情報を記録します。

B.1. Non-Goals for IETF

B.1. IETFの非目標

Listed below are aspects of content delivery that the authors propose be kept outside of the scope of the CDNI working group:

以下は、作成者がCDNIワーキンググループの範囲外に保つことを提案するコンテンツ配信の側面です。

o The interface between the Content Service Provider and the Authoritative CDN (i.e., the Upstream CDN contracted by the CSP for delivery by this CDN or by its Downstream CDNs).

o コンテンツサービスプロバイダーと信頼できるCDN（つまり、このCDNまたはそのダウンストリームCDNによる配信のためにCSPによって契約されたアップストリームCDN）間のインターフェイス。

o The delivery interface between the delivering CDN Surrogate and the User Agent, such as streaming protocols.

o 配信プロトコルなど、配信するCDNサロゲートとユーザーエージェント間の配信インターフェース。

o The request interface between the User Agent and the Request Routing system of a given CDN. Existing IETF protocols (e.g., HTTP, RTSP, DNS) are commonly used by User Agents to request content from a CDN and by CDN Request Routing systems to redirect the User Agent requests. The CDNI working group need not define new protocols for this purpose. Note, however, that the CDNI control plane interface may indirectly affect some of the information exchanged through the request interface (e.g., URI).

o 特定のCDNのユーザーエージェントとリクエストルーティングシステム間のリクエストインターフェイス。既存のIETFプロトコル（HTTP、RTSP、DNSなど）は、ユーザーエージェントがCDNからコンテンツをリクエストする場合や、CDNリクエストルーティングシステムがユーザーエージェントリクエストをリダイレクトする場合に一般的に使用されます。 CDNIワーキンググループは、この目的のために新しいプロトコルを定義する必要はありません。ただし、CDNIコントロールプレーンインターフェースは、リクエストインターフェースを介して交換される情報の一部（URIなど）に間接的に影響を与える可能性があることに注意してください。

o The content acquisition interface between CDNs (i.e., the data plane interface for actual delivery of a piece of content from one CDN to the other). This is expected to use existing protocols such as HTTP or protocols defined in other forums for content acquisition between an origin server and a CDN (e.g., HTTP-based C2 reference point of the Alliance for Telecommunications Industry Solutions IPTV Interoperability Forum Content on Demand service (ATIS IIF CoD)). The CDN Interconnection problem space described in this document may therefore only concern itself with the agreement/negotiation aspects of which content acquisition protocol is to be used between two interconnected CDNs in view of facilitating interoperability.

o CDN間のコンテンツ取得インターフェイス（つまり、1つのCDNから別のCDNにコンテンツを実際に配信するためのデータプレーンインターフェイス）。これは、元のサーバーとCDN間のコンテンツ取得のために、HTTPや他のフォーラムで定義されたプロトコルなどの既存のプロトコルを使用することが期待されます（たとえば、Alliance for Telecommunications Industry Solutions IPTV Interoperability Forum Content on DemandサービスのHTTPベースのC2リファレンスポイント（ ATIS IIF CoD）））。したがって、このドキュメントで説明するCDN相互接続問題スペースは、相互運用性を促進する観点から、2つの相互接続されたCDN間で使用されるコンテンツ取得プロトコルの合意/交渉の側面にのみ関係する可能性があります。

o End User/User Agent Authentication. End User/User Agent authentication and authorization are the responsibility of the Content Service Provider.

o エンドユーザー/ユーザーエージェント認証。エンドユーザー/ユーザーエージェントの認証と承認は、コンテンツサービスプロバイダーの責任です。

o Content preparation, including encoding and transcoding. The CDNI architecture aims at allowing distribution across interconnected CDNs of content treated as opaque objects. Interpretation and processing of the objects, as well as optimized delivery of these objects by the Surrogate to the End User, are outside the scope of CDNI.

o エンコーディングとトランスコーディングを含むコンテンツの準備。 CDNIアーキテクチャは、不透明なオブジェクトとして扱われるコンテンツの相互接続されたCDN間での配布を可能にすることを目的としています。オブジェクトの解釈と処理、およびサロゲートによるエンドユーザーへのこれらのオブジェクトの最適化された配信は、CDNIの範囲外です。

o Digital Rights Management (DRM). DRM is an end-to-end issue between a content protection system and the User Agent.

o デジタル著作権管理（DRM）。 DRMは、コンテンツ保護システムとユーザーエージェント間のエンドツーエンドの問題です。

o Applications consuming CDNI logs (e.g., charging, analytics, reporting, ...).

o CDNIログを使用するアプリケーション（例：課金、分析、レポートなど）。

o Internal CDN interfaces and protocols (i.e., interfaces and protocols within one CDN).

o 内部CDNインターフェースとプロトコル（つまり、1つのCDN内のインターフェースとプロトコル）。

o Scalability of individual CDNs. While scalability of the CDNI interfaces/approach is in scope, how an individual CDN scales is out of scope.

o 個々のCDNのスケーラビリティ。 CDNIインターフェイス/アプローチのスケーラビリティは範囲内ですが、個々のCDNのスケーリング方法は範囲外です。

o Actual algorithms for selection of CDNs or Surrogates by Request Routing systems (however, some specific parameters required as input to these algorithms may be in scope when they need to be communicated across CDNs).

o リクエストルーティングシステムによるCDNまたは代理の選択のための実際のアルゴリズム（ただし、これらのアルゴリズムへの入力として必要ないくつかの特定のパラメーターは、CDN間で通信する必要がある場合にスコープ内にある場合があります）。

o Surrogate algorithms. For example, caching algorithms and content acquisition methods are outside the scope of the CDNI work. Content management (e.g., Content Deletion) as it relates to CDNI content management policies is in scope, but the internal algorithms used by a cache to determine when to no longer cache an item of Content (in the absence of any specific metadata to the contrary) is out of scope.

o 代理アルゴリズム。たとえば、キャッシュアルゴリズムとコンテンツ取得方法は、CDNI作業の範囲外です。 CDNIコンテンツ管理ポリシーに関連するコンテンツ管理（コンテンツの削除など）は範囲に含まれますが、コンテンツのアイテムをキャッシュしない時期を決定するためにキャッシュによって使用される内部アルゴリズム（反対に特定のメタデータがない場合））は範囲外です。

o Element management interfaces.

o 要素管理インターフェース。

o Commercial, business, and legal aspects related to the interconnections of CDNs.

o CDNの相互接続に関連する商業、ビジネス、および法的側面。

B.2. Relationship to Relevant IETF Working Groups and IRTF Research Groups

B.2. 関連するIETFワーキンググループおよびIRTF研究グループとの関係

B.2.1. ALTO WG

B.2.1. アルトWG

As stated in the ALTO working group charter [ALTO-Charter]:

ALTOワーキンググループチャーター[ALTOチャーター]で述べたように、

The Working Group will design and specify an Application-Layer Traffic Optimization (ALTO) service that will provide applications with information to perform better-than-random initial peer selection. ALTO services may take different approaches at balancing factors such as maximum bandwidth, minimum cross-domain traffic, lowest cost to the user, etc. The working group will consider the needs of BitTorrent, tracker-less P2P, and other applications, such as content delivery networks (CDN) and mirror selection.

ワーキンググループは、ランダムな初期ピア選択を実行するための情報をアプリケーションに提供するアプリケーションレイヤートラフィック最適化（ALTO）サービスを設計および指定します。 ALTOサービスは、最大帯域幅、最小のクロスドメイントラフィック、ユーザーへの最低コストなどの要素のバランスをとる際に異なるアプローチを取る場合があります。ワーキンググループは、BitTorrent、トラッカーなしのP2P、およびコンテンツなどの他のアプリケーションのニーズを考慮します配信ネットワーク（CDN）とミラーの選択。

In particular, the ALTO service can be used by a CDN Request Routing system to improve its selection of a CDN Surrogate to serve a particular User Agent request (or to serve a request from another Surrogate). [ALTO-CDN-USE-CASES] describes a number of use cases for a CDN to be able to obtain network topology and cost information from an ALTO server(s) and discusses how CDN Request Routing could be used as an integration point of ALTO into CDNs. It is possible that the ALTO service could be used in the same manner in a multi-CDN environment based on CDN Interconnection. For example, an Upstream CDN may take advantage of the ALTO service in its decision for selecting a Downstream CDN to which a user request should be delegated.

特に、ALTOサービスをCDN要求ルーティングシステムで使用して、CDNサロゲートの選択を改善し、特定のユーザーエージェント要求を処理する（または別のサロゲートからの要求を処理する）ことができます。 [ALTO-CDN-USE-CASES]は、CDNがALTOサーバーからネットワークトポロジとコスト情報を取得できるようにするためのいくつかの使用例を説明し、CDNリクエストルーティングをALTOの統合ポイントとして使用する方法について説明します。 CDNに。 ALTOサービスは、CDN相互接続に基づくマルチCDN環境で同じように使用できる可能性があります。たとえば、アップストリームCDNは、ユーザーの要求を委任する必要があるダウンストリームCDNを選択するために、ALTOサービスを利用する場合があります。

However, the current work of ALTO is complementary to and does not overlap with the work described in this document because the integration between ALTO and a CDN is an internal decision for a specific CDN and is therefore out of scope for the CDNI working group. One area for further study is whether additional information should be provided by an ALTO service to facilitate CDNI CDN selection.

ただし、ALTOとCDNの統合は特定のCDNの内部決定であり、CDNIワーキンググループの範囲外であるため、ALTOの現在の作業はこのドキュメントで説明されている作業を補完し、重複しません。さらなる研究の1つの領域は、CDNI CDNの選択を容易にするために、ALTOサービスによって追加情報を提供する必要があるかどうかです。

B.2.2. DECADE WG

The DECADE working group [DECADE-Charter] is addressing the problem of reducing traffic on the last-mile uplink, as well as backbone and transit links caused by peer-to-peer (P2P) streaming and file-sharing applications. It addresses the problem by enabling an application endpoint to make content available from an in-network storage service and by enabling other application endpoints to retrieve the content from there.

DECADEワーキンググループ[DECADE-Charter]は、ラストマイルアップリンク、およびピアツーピア（P2P）ストリーミングおよびファイル共有アプリケーションによって引き起こされるバックボーンおよびトランジットリンクのトラフィックを削減する問題に取り組んでいます。これは、アプリケーションエンドポイントがネットワーク内ストレージサービスからコンテンツを利用できるようにし、他のアプリケーションエンドポイントがそこからコンテンツを取得できるようにすることで、問題に対処します。

Exchanging data through the in-network storage service in this manner, instead of through direct communication, provides significant gain where:

直接通信ではなく、この方法でネットワーク内ストレージサービスを介してデータを交換すると、次のような場合に大きなメリットがあります。

o The network capacity/bandwidth from the in-network storage service to the application endpoint significantly exceeds the capacity/ bandwidth from application endpoint to application endpoint (e.g., because of an end-user uplink bottleneck); and

o ネットワーク内ストレージサービスからアプリケーションエンドポイントへのネットワーク容量/帯域幅が、アプリケーションエンドポイントからアプリケーションエンドポイントへの容量/帯域幅を大幅に超えている（たとえば、エンドユーザーのアップリンクのボトルネックのため）。そして

o The content is to be accessed by multiple instances of application endpoints (e.g., as is typically the case for P2P applications).

o コンテンツは、アプリケーションエンドポイントの複数のインスタンスによってアクセスされます（たとえば、P2Pアプリケーションの場合は一般的です）。

While, as is the case for any other data distribution application, the DECADE architecture and mechanisms could potentially be used for exchange of CDNI control plane information via an in-network storage service (as opposed to directly between the entities terminating the CDNI interfaces in the neighbor CDNs), we observe that:

他のデータ配信アプリケーションの場合と同様に、DECADEアーキテクチャとメカニズムは、ネットワーク内のストレージサービスを介したCDNIコントロールプレーン情報の交換に使用できる可能性があります（隣人CDN）、私たちはそれを観察します：

o CDNI would operate as a "Content Distribution Application" from the DECADE viewpoint (i.e., would operate on top of DECADE).

o CDNIは、DECADEの観点からは「コンテンツ配布アプリケーション」として動作します（つまり、DECADEの上で動作します）。

o There do not seem to be obvious benefits in integrating the DECADE control plane responsible for signaling information relating to control of the in-network storage service itself, and the CDNI control plane responsible for application-specific CDNI interactions (such as exchange of CDNI Metadata, CDNI request redirection, and transfer of CDNI logging information).

o ネットワーク内ストレージサービス自体の制御に関連するシグナリング情報を担当するDECADEコントロールプレーンと、アプリケーション固有のCDNIインタラクション（CDNIメタデータの交換など）を担当するCDNIコントロールプレーンを統合することには、明らかな利点はないようです。 CDNI要求のリダイレクト、およびCDNIロギング情報の転送）。

o There would typically be limited benefits in making use of a DECADE in-network storage service because the CDNI interfaces are expected to be terminated by a very small number of CDNI clients (if not one) in each CDN, and the CDNI clients are expected to benefit from high bandwidth/capacity when communicating directly to each other (at least as high as if they were communicating via an in-network storage server).

o CDNインターフェイスは各CDN内の非常に少数のCDNIクライアント（1つではない場合）によって終了されることが期待されており、CDNIクライアントは相互に直接通信する場合の高帯域幅/容量のメリット（少なくともネットワーク内のストレージサーバーを介して通信しているかのように）。

The DECADE in-network storage architecture and mechanisms may theoretically be used for the acquisition of the content objects themselves between interconnected CDNs. It is not expected that this would have obvious benefits in typical situations where a content object is acquired only once from an Upstream CDN to a Downstream CDN (and then distributed as needed inside the Downstream CDN). But it might have benefits in some particular situations. Since the acquisition protocol between CDNs is outside the scope of the CDNI work, this question is left for further study.

DECADEインネットワークストレージアーキテクチャとメカニズムは、理論的には、相互接続されたCDN間のコンテンツオブジェクト自体の取得に使用できます。これは、コンテンツオブジェクトがアップストリームCDNからダウンストリームCDNに1回だけ取得され（その後、ダウンストリームCDN内で必要に応じて配信される）典型的な状況では明らかな利点があるとは予想されません。ただし、特定の状況ではメリットがある場合があります。 CDN間の取得プロトコルはCDNI作業の範囲外であるため、この問題は今後の検討課題として残されています。

The DECADE in-network storage architecture and mechanisms may potentially also be used within a given CDN for the distribution of the content objects themselves among Surrogates of that CDN. Since the CDNI work does not concern itself with operation within a CDN, this question is left for further study.

DECADEインネットワークストレージアーキテクチャとメカニズムは、特定のCDN内でも、そのCDNのサロゲート間のコンテンツオブジェクト自体の配布に使用される可能性があります。 CDNIの作業は、CDN内での操作に関係しないため、この問題はさらに調査する必要があります。

Therefore, the work of DECADE may be complementary to, but does not overlap with, the CDNI work described in this document.

したがって、DECADEの作業は、このドキュメントで説明されているCDNIの作業を補完するものですが、重複することはありません。

B.2.3. PPSP WG

As stated in the PPSP working group charter [PPSP-Charter]:

PPSPワーキンググループチャーター[PPSP憲章]で述べられているように、

The Peer-to-Peer Streaming Protocol (PPSP) working group develops two signaling and control protocols for a peer-to-peer (P2P) streaming system for transmitting live and time-shifted media content with near real-time delivery requirements...

ピアツーピアストリーミングプロトコル（PPSP）ワーキンググループは、ピアツーピア（P2P）ストリーミングシステム用の2つのシグナリングおよび制御プロトコルを開発し、ほぼリアルタイムの配信要件でライブおよびタイムシフトメディアコンテンツを送信します...

... The PPSP working group designs a protocol for signaling and control between trackers and peers (the PPSP "tracker protocol") and a signaling and control protocol for communication among the peers (the PPSP "peer protocol"). The two protocols enable peers to receive streaming data within the time constraints required by specific content items.

... PPSPワーキンググループは、トラッカーとピア間のシグナリングと制御のためのプロトコル（PPSP "トラッカープロトコル"）と、ピア間の通信のためのシグナリングと制御プロトコル（PPSP "ピアプロトコル"）を設計します。 2つのプロトコルにより、ピアは特定のコンテンツアイテムに必要な時間制限内でストリーミングデータを受信できます。

Therefore, PPSP is concerned with the distribution of the streamed content itself along with the necessary signaling and control required to distribute the content. As such, it could potentially be used for the acquisition of streamed content across interconnected CDNs. But since the acquisition protocol is outside the scope of the work proposed for CDNI, we leave this for further study. Also, because of its streaming nature, PPSP is not seen as applicable to the distribution and control of the CDNI control plane and CDNI data representations.

したがって、PPSPは、コンテンツの配信に必要なシグナリングと制御とともに、ストリーミングされたコンテンツ自体の配信に関係しています。そのため、相互接続されたCDN全体でストリーミングコンテンツを取得するために使用できる可能性があります。ただし、取得プロトコルはCDNIに提案された作業の範囲外であるため、これは今後の調査に残します。また、ストリーミングの性質上、PPSPはCDNIコントロールプレーンとCDNIデータ表現の配布と制御に適用できるとは見なされていません。

Therefore, the work of PPSP may be complementary to, but does not overlap with, the work described in this document for CDNI.

したがって、PPSPの作業は、このドキュメントで説明されているCDNIの作業を補完するもので、重複することはありません。

B.2.4. IRTF P2P Research Group

B.2.4. IRTF P2P研究グループ

Some information on CDN Interconnection motivations and technical issues were presented in the P2P research group at IETF 77. The presentation can be found in [P2PRG-CDNI].

CDN相互接続の動機と技術的な問題に関するいくつかの情報は、IETF 77のP2P研究グループで発表されました。このプレゼンテーションは、[P2PRG-CDNI]にあります。

Authors' Addresses

著者のアドレス

Ben Niven-Jenkins Velocix (Alcatel-Lucent) 326 Cambridge Science Park Milton Road, Cambridge CB4 0WG UK

Ben Niven-Jenkins Velocix（Alcatel-Lucent）326 Cambridge Science Park Milton Road、Cambridge CB4 0WG UK

   EMail: ben@velocix.com

Francois Le Faucheur Cisco Systems Greenside, 400 Avenue de Roumanille Sophia Antipolis 06410 France

Francois Le Faucheur Cisco Systems Greenside、400 Avenue de Roumanille Sophia Antipolis 06410フランス

   Phone: +33 4 97 23 26 19
   EMail: flefauch@cisco.com

Nabil Bitar Verizon 60 Sylvan Road Waltham, MA 02145 USA

なびｌびたｒゔぇりぞん６０Ｓｙｌゔぁんろあｄわｌてゃｍ、ま０２１４５うさ

   EMail: nabil.n.bitar@verizon.com