[要約] RFC 7336は、CDN間の相互接続を可能にするためのフレームワークです。その目的は、異なるCDN間でのコンテンツの効率的な配信を実現することです。
Internet Engineering Task Force (IETF) L. Peterson
Request for Comments: 7336 Akamai Technologies, Inc.
Obsoletes: 3466 B. Davie
Category: Informational VMware, Inc.
ISSN: 2070-1721 R. van Brandenburg, Ed.
TNO
August 2014
Framework for Content Distribution Network Interconnection (CDNI)
コンテンツ配信ネットワーク相互接続（CDNI）のフレームワーク
Abstract
概要
This document presents a framework for Content Distribution Network Interconnection (CDNI). The purpose of the framework is to provide an overall picture of the problem space of CDNI and to describe the relationships among the various components necessary to interconnect CDNs. CDNI requires the specification of interfaces and mechanisms to address issues such as request routing, distribution metadata exchange, and logging information exchange across CDNs. The intent of this document is to outline what each interface needs to accomplish and to describe how these interfaces and mechanisms fit together, while leaving their detailed specification to other documents. This document, in combination with RFC 6707, obsoletes RFC 3466.
このドキュメントでは、コンテンツ配信ネットワーク相互接続（CDNI）のフレームワークについて説明します。フレームワークの目的は、CDNIの問題空間の全体像を提供し、CDNの相互接続に必要なさまざまなコンポーネント間の関係を説明することです。 CDNIでは、要求のルーティング、配布メタデータの交換、CDN間のログ情報交換などの問題に対処するためのインターフェイスとメカニズムの仕様が必要です。このドキュメントの目的は、詳細な仕様を他のドキュメントに残しながら、各インターフェイスが達成する必要があることの概要を示し、これらのインターフェイスとメカニズムがどのように組み合わされるかを説明することです。このドキュメントは、RFC 6707と組み合わせて、RFC 3466を廃止します。
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/rfc7336.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7336で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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 ....................................................4
1.1. Terminology ................................................4
1.2. Reference Model ............................................6
1.3. Structure of This Document ................................10
2. Building Blocks ................................................10
2.1. Request Redirection .......................................10
2.1.1. DNS Redirection ....................................10
2.1.2. HTTP Redirection ...................................12
3. Overview of CDNI Operation .....................................12
3.1. Preliminaries .............................................14
3.2. Iterative HTTP Redirect Example ...........................15
3.3. Recursive HTTP Redirection Example ........................21
3.4. Iterative DNS-Based Redirection Example ...................25
3.4.1. Notes on Using DNSSEC ..............................28
3.5. Dynamic Footprint Discovery Example .......................29
3.6. Content Removal Example ...................................31
3.7. Pre-positioned Content Acquisition Example ................32
3.8. Asynchronous CDNI Metadata Example ........................33
3.9. Synchronous CDNI Metadata Acquisition Example .............35
3.10. Content and Metadata Acquisition with Multiple
Upstream CDNs ............................................37
4. Main Interfaces ................................................38
4.1. In-Band versus Out-of-Band Interfaces .....................39
4.2. Cross-Interface Concerns ..................................40
4.3. Request Routing Interfaces ................................40
4.4. CDNI Logging Interface ....................................41
4.5. CDNI Control Interface ....................................43
4.6. CDNI Metadata Interface ...................................43
4.7. HTTP Adaptive Streaming Concerns ..........................44
4.8. URI Rewriting .............................................46
5. Deployment Models ..............................................47
5.1. Meshed CDNs ...............................................47
5.2. CSP Combined with CDN .....................................48
5.3. CSP Using CDNI Request Routing Interface ..................49
5.4. CDN Federations and CDN Exchanges .........................50
6. Trust Model ....................................................53
7. Privacy Considerations .........................................54
8. Security Considerations ........................................55
8.1. Security of CDNI Interfaces ...............................56
8.2. Digital Rights Management .................................56
9. Contributors ...................................................56
10. Acknowledgements ..............................................57
11. Informative References ........................................57
This document provides an overview of the various components necessary to interconnect CDNs, expanding on the problem statement and use cases introduced in [RFC6770] and [RFC6707]. It describes the necessary interfaces and mechanisms in general terms and outlines how they fit together to form a complete system for CDN Interconnection. Detailed specifications are left to other documents. This document makes extensive use of message flow examples to illustrate the operation of interconnected CDNs, but these examples should be considered illustrative rather than prescriptive.
このドキュメントは、CDNを相互接続するために必要なさまざまなコンポーネントの概要を提供し、[RFC6770]と[RFC6707]で導入された問題ステートメントとユースケースを拡張します。必要なインターフェイスとメカニズムを一般的な用語で説明し、CDN相互接続のための完全なシステムを形成するためにそれらをどのように組み合わせるかについて概説します。詳細な仕様は他のドキュメントに任されています。このドキュメントでは、相互に接続されたCDNの操作を説明するためにメッセージフローの例を広範囲に使用していますが、これらの例は、規範的というよりは例示的であると考えるべきです。
[RFC3466] uses different terminology and models for "Content (distribution) Internetworking (CDI)". It is also less prescriptive in terms of interfaces. To avoid confusion, this document obsoletes [RFC3466].
[RFC3466]は、「コンテンツ（配布）インターネットワーキング（CDI）」に異なる用語とモデルを使用しています。また、インターフェースの面でも規範的ではありません。混乱を避けるため、このドキュメントは廃止されました[RFC3466]。
This document uses the core terminology defined in [RFC6707]. It also introduces the following terms:
このドキュメントでは、[RFC6707]で定義されているコア用語を使用しています。また、次の用語も紹介します。
CDN-Domain: a hostname (Fully Qualified Domain Name -- FQDN) at the beginning of a URL (excluding port and scheme), representing a set of content that is served by a given CDN. For example, in the URL http://cdn.csp.example/...rest of URL..., the CDN-Domain is cdn.csp.example. A major role of CDN-Domain is to identify a region (subset) of the URI space relative to which various CDNI rules and policies apply. For example, a record of CDNI Metadata might be defined for the set of resources corresponding to some CDN-Domain.
CDN-ドメイン：URLの先頭にあるホスト名（完全修飾ドメイン名-FQDN）（ポートとスキームを除く）。特定のCDNによって提供されるコンテンツのセットを表します。たとえば、URL http：//cdn.csp.example/...rest of URL ...では、CDN-Domainはcdn.csp.exampleです。 CDN-Domainの主な役割は、さまざまなCDNIルールおよびポリシーが適用されるURIスペースの領域（サブセット）を識別することです。たとえば、CDNメタデータのレコードは、一部のCDNドメインに対応するリソースのセットに対して定義される場合があります。
Distinguished CDN-Domain: a CDN-Domain that is allocated by a CDN for the purposes of communication with a peer CDN but that is not found in client requests. Such CDN-Domains may be used for inter-CDN acquisition, or as redirection targets, and enable a CDN to distinguish a request from a peer CDN from an end-user request.
Distinguished CDN-Domain：ピアCDNとの通信を目的としてCDNによって割り当てられたが、クライアント要求には見つからないCDNドメイン。このようなCDNドメインは、CDN間の取得に使用したり、リダイレクト先として使用したりすることができ、CDNがピアCDNからの要求とエンドユーザーの要求を区別できるようにします。
Delivering CDN: the CDN that ultimately delivers a piece of content to the end user. The last in a potential sequence of Downstream CDNs.
CDNの配信：最終的にコンテンツの一部をエンドユーザーに配信するCDN。潜在的な一連のダウンストリームCDNの最後。
Iterative CDNI Request Redirection: When an Upstream CDN elects to redirect a request towards a Downstream CDN, the Upstream CDN can base its redirection purely on a local decision (and without attempting to take into account how the Downstream CDN may in turn redirect the user agent). In that case, the Upstream CDN redirects the request to the Request Routing system in the Downstream CDN, which in turn will decide how to redirect that request: this approach is referred to as "Iterative" CDNI Request Redirection.
反復CDNI要求のリダイレクト：アップストリームCDNが要求をダウンストリームCDNにリダイレクトすることを選択した場合、アップストリームCDNはそのリダイレクトを純粋にローカルの決定に基づくことができます（ダウンストリームCDNがユーザーエージェントをリダイレクトする方法を考慮せずに） ）。その場合、アップストリームCDNはリクエストをダウンストリームCDNのリクエストルーティングシステムにリダイレクトします。ダウンストリームCDNは、そのリクエストをリダイレクトする方法を決定します。このアプローチは「反復的」CDNIリクエストリダイレクトと呼ばれます。
Recursive CDNI Request Redirection: When an Upstream CDN elects to redirect a request towards a Downstream CDN, the Upstream CDN can query the Downstream CDN Request Routing system via the CDNI Request Routing Redirection interface (or use information cached from earlier similar queries) to find out how the Downstream CDN wants the request to be redirected. This allows the Upstream CDN to factor in the Downstream CDN response when redirecting the user agent. This approach is referred to as "Recursive" CDNI Request Redirection. Note that the Downstream CDN may elect to have the request redirected directly to a Surrogate inside the Downstream CDN, or to any other element in the Downstream CDN (or in another CDN), to handle the redirected request appropriately.
再帰的CDNI要求リダイレクト：アップストリームCDNが要求をダウンストリームCDNにリダイレクトすることを選択した場合、アップストリームCDNはCDNI要求ルーティングリダイレクションインターフェイスを介してダウンストリームCDN要求ルーティングシステムにクエリを実行します（または以前の同様のクエリからキャッシュされた情報を使用します）。ダウンストリームCDNが要求をリダイレクトする方法。これにより、ユーザーエージェントをリダイレクトするときに、アップストリームCDNがダウンストリームCDN応答を考慮に入れることができます。このアプローチは、「再帰的」CDNI要求リダイレクトと呼ばれます。ダウンストリームCDNは、リダイレクトされた要求を適切に処理するために、要求をダウンストリームCDN内のサロゲートまたはダウンストリームCDN（または別のCDN）の他の要素に直接リダイレクトすることを選択できることに注意してください。
Synchronous CDNI operations: operations between CDNs that happen during the process of servicing a user request, i.e., between the time that the user agent begins its attempt to obtain content and the time at which that request is served.
同期CDNI操作：ユーザー要求の処理プロセス中に発生するCDN間の操作、つまり、ユーザーエージェントがコンテンツの取得を開始してから、その要求が処理されるまでの操作。
Asynchronous CDNI operations: operations between CDNs that happen independently of any given user request, such as advertisement of footprint information or pre-positioning of content for later delivery.
非同期CDNI操作：フットプリント情報のアドバタイズまたは後で配信するためのコンテンツの事前配信など、特定のユーザー要求とは無関係に発生するCDN間の操作。
Trigger Interface: a subset of the CDNI Control interface that includes operations to pre-position, revalidate, and purge both metadata and content. These operations are typically called in response to some action (Trigger) by the Content Service Provider (CSP) on the Upstream CDN.
トリガーインターフェイス：メタデータとコンテンツの両方を事前配置、再検証、および削除する操作を含むCDNIコントロールインターフェイスのサブセット。これらの操作は通常、アップストリームCDNのコンテンツサービスプロバイダー（CSP）によって何らかのアクション（トリガー）に応答して呼び出されます。
We also sometimes use uCDN and dCDN as shorthand for Upstream CDN and Downstream CDN (see [RFC6707]), respectively.
また、アップストリームCDNおよびダウンストリームCDN（[RFC6707]を参照）の短縮形として、それぞれuCDNおよびdCDNを使用することもあります。
At various points in this document, the concept of a CDN footprint is used. For a discussion on what constitutes a CDN footprint, the reader is referred to [FOOTPRINT-CAPABILITY].
このドキュメントのさまざまな時点で、CDNフットプリントの概念が使用されています。 CDNフットプリントの構成要素については、[FOOTPRINT-CAPABILITY]を参照してください。
This document uses the reference model in Figure 1, which expands the reference model originally defined in [RFC6707]. (The difference is that the expanded model splits the Request Routing interface into its two distinct parts: the Request Routing Redirection interface and the Footprint & Capabilities Advertisement interface, as described below.)
このドキュメントでは、[RFC6707]で最初に定義された参照モデルを拡張した図1の参照モデルを使用します。 （違いは、拡張モデルがリクエストルーティングインターフェイスを2つの異なる部分に分割することです：リクエストルーティングリダイレクションインターフェイスとフットプリントと機能のアドバタイズメントインターフェイス（以下で説明）。）
--------
/ \
| CSP |
\ /
--------
*
*
* /\
* / \
---------------------- |CDNI| ----------------------
/ Upstream CDN \ | | / Downstream CDN \
| +-------------+ | | CI | | +-------------+ |
|******* Control |<======|====|=======>| Control *******|
|* +------*----*-+ | | | | +-*----*------+ *|
|* * * | | | | * * *|
|* +------*------+ | | LI | | +------*------+ *|
|* ***** Logging |<======|====|=======>| Logging ***** *|
|* * +-*-----------+ | | | | +-----------*-+ * *|
|* * * * | | | | * * * *|
.....*...+-*---------*-+ | | RI | | +-*---------*-+...*.*...
. |* * | |<======|====|=======>| | * *| .
. |* * | Req-Routing | | |FCI | | | Req-Routing | * *| .
. |* * *** |<======|====|=======>| |** * *| .
. |* * * +-------------+.| | | | +-------------+ * * *| .
. |* * * . | | | * * *| .
. |* * * +-------------+ |. | MI | | +-------------+ * * *| .
. |* * * | Distribution|<==.===|====|=======>| Distribution| * * *| .
. |* * * | | | . \ / | | | * * *| .
. |* * * |+---------+ | | . \/ | | +---------+| * * *| .
. |* * ***| +---------+| | ...Request......+---------+ |*** * *| .
. |* *****+-|Surrogate|***********************|Surrogate|-+***** *| .
. |******* +---------+| | Acquisition | |+----------+ *******| .
. | +-------------+ | | +-------*-----+ | .
. \ / \ * / .
. ---------------------- ---------*------------ .
. * .
. * Delivery .
. * .
. +--*---+ .
...............Request............................| User |..Request..
| Agent|
+------+
<==> interfaces inside the scope of CDNI
**** and .... interfaces outside the scope of CDNI
Figure 1: CDNI Expanded Model and CDNI Interfaces
図1：CDNI拡張モデルとCDNIインターフェイス
While some interfaces in the reference model are "out of scope" for the CDNI WG (in the sense that there is no need to define new protocols for those interfaces), we note that we still need to refer to them in this document to explain the overall operation of CDNI.
参照モデルの一部のインターフェースはCDNI WGの「範囲外」です（これらのインターフェースに新しいプロトコルを定義する必要がないという意味で）が、説明のためにこのドキュメントでそれらを参照する必要があることに注意してくださいCDNIの全体的な操作。
We also note that, while we generally show only one Upstream CDN serving a given CSP, it is entirely possible that multiple uCDNs can serve a single CSP. In fact, this situation effectively exists today in the sense that a single CSP can currently delegate its content delivery to more than one CDN.
また、通常は特定のCSPにサービスを提供する1つのアップストリームCDNのみを示していますが、複数のuCDNが1つのCSPにサービスを提供することも可能です。実際、この状況は今日、単一のCSPが現在、コンテンツ配信を複数のCDNに委任できるという意味で事実上存在しています。
The following briefly describes the five CDNI interfaces, paraphrasing the definitions given in [RFC6707]. We discuss these interfaces in more detail in Section 4.
以下は5つのCDNIインターフェースを簡潔に説明し、[RFC6707]で与えられた定義を言い換えます。これらのインターフェースについては、セクション4で詳しく説明します。
o CDNI Control interface (CI): Operations to bootstrap and parameterize the other CDNI interfaces, as well as operations to pre-position, revalidate, and purge both metadata and content. The latter subset of operations is sometimes collectively called the "Trigger interface".
o CDNI制御インターフェース（CI）：他のCDNIインターフェースをブートストラップおよびパラメーター化する操作、およびメタデータとコンテンツの両方を事前配置、再検証、およびパージする操作。後者の操作のサブセットは、まとめて「トリガーインターフェース」と呼ばれることがあります。
o CDNI Request Routing interface: Operations to determine what CDN (and optionally what Surrogate within a CDN) is to serve end-user requests. This interface is actually a logical bundling of two separate, but related, interfaces:
o CDNIリクエストルーティングインターフェイス：エンドユーザーのリクエストを処理するためのCDN（およびオプションでCDN内のサロゲート）を決定する操作。このインターフェースは実際には、2つの別個の、しかし関連するインターフェースの論理的なバンドルです。
* CDNI Footprint & Capabilities Advertisement interface (FCI): Asynchronous operations to exchange routing information (e.g., the network footprint and capabilities served by a given CDN) that enables CDN selection for subsequent user requests; and
* CDNI Footprint＆Capabilities Advertisement Interface（FCI）：非同期操作により、ルーティング情報（たとえば、特定のCDNによって提供されるネットワークフットプリントと機能）を交換し、後続のユーザー要求に対してCDNを選択できるようにします。そして
* CDNI Request Routing Redirection interface (RI): Synchronous operations to select a delivery CDN (Surrogate) for a given user request.
* CDNI要求ルーティングリダイレクトインターフェイス（RI）：同期操作は、特定のユーザー要求の配信CDN（代理）を選択します。
o CDNI Metadata interface (MI): Operations to communicate metadata that governs how the content is delivered by interconnected CDNs. Examples of CDNI Metadata include geo-blocking directives, availability windows, access control mechanisms, and purge directives. It may include a combination of:
o CDNIメタデータインターフェイス（MI）：相互接続されたCDNによるコンテンツの配信方法を管理するメタデータを通信する操作。 CDNIメタデータの例には、ジオブロッキングディレクティブ、可用性ウィンドウ、アクセス制御メカニズム、およびパージディレクティブが含まれます。次の組み合わせが含まれる場合があります。
* Asynchronous operations to exchange metadata that govern subsequent user requests for content; and
* コンテンツに対する後続のユーザー要求を管理するメタデータを交換するための非同期操作。そして
* Synchronous operations that govern behavior for a given user request for content.
* コンテンツに対する特定のユーザー要求の動作を制御する同期操作。
o CDNI Logging interface (LI): Operations that allow interconnected CDNs to exchange relevant activity logs. It may include a combination of:
o CDNI Loggingインターフェース（LI）：相互接続されたCDNが関連するアクティビティログを交換できるようにする操作。次の組み合わせが含まれる場合があります。
* Real-time exchanges, suitable for runtime traffic monitoring; and
* 実行時のトラフィック監視に適したリアルタイムの交換。そして
* Offline exchanges, suitable for analytics and billing.
* 分析と請求に適したオフラインの交換。
The division between the sets of Trigger-based operations in the CDNI Control interface and the CDNI Metadata interface is somewhat arbitrary. For both cases, the information passed from the Upstream CDN to the Downstream CDN can broadly be viewed as metadata that describes how content is to be managed by the Downstream CDN. For example, the information conveyed by the CI to pre-position, revalidate, or purge metadata is similar to the information conveyed by posting updated metadata via the MI. Even the CI operation to purge content could be viewed as a metadata update for that content: purge simply says that the availability window for the named content ends now. The two interfaces share much in common, so minimally, there will need to be a consistent data model that spans both.
CDNIコントロールインターフェイスとCDNIメタデータインターフェイスでのトリガーベースの操作のセット間の分割は、やや恣意的です。どちらの場合も、アップストリームCDNからダウンストリームCDNに渡される情報は、コンテンツがダウンストリームCDNでどのように管理されるかを説明するメタデータとして広く見ることができます。たとえば、CIによって事前配置、再検証、またはパージメタデータに伝達される情報は、MI経由で更新されたメタデータを投稿することによって伝達される情報と同様です。コンテンツをパージするCI操作でさえ、そのコンテンツのメタデータ更新と見なすことができます。パージは、指定されたコンテンツの可用性ウィンドウが終了したことを示しています。 2つのインターフェースは共通点が多いため、最低限、両方にまたがる一貫したデータモデルが必要になります。
The distinction we draw has to do with what the uCDN knows about the successful application of the metadata by the dCDN. In the case of the CI, the Downstream CDN returning a successful status message guarantees that the operation has been successfully completed; for example, the content has been purged or pre-positioned. This implies that the Downstream CDN accepts responsibility for having successfully completed the requested operation. In contrast, metadata passed between CDNs via the MI carries no such completion guarantee. Returning success implies successful receipt of the metadata, but nothing can be inferred about precisely when the metadata will take effect in the Downstream CDN, only that it will take effect eventually. This is because of the challenge in globally synchronizing updates to metadata with end-user requests that are currently in progress (or indistinguishable from currently being in progress). Clearly, a CDN will not be viewed as a trusted peer if "eventually" often becomes an indefinite period of time, but the acceptance of responsibility cannot be as crisply defined for the MI.
私たちが描く区別は、uCDNがdCDNによるメタデータの適用の成功について知っていることに関係しています。 CIの場合、成功したステータスメッセージを返すダウンストリームCDNは、操作が正常に完了したことを保証します。たとえば、コンテンツが削除または事前配信されています。これは、ダウンストリームCDNが、要求された操作を正常に完了したことに対する責任を受け入れることを意味します。対照的に、MIを介してCDN間で渡されるメタデータには、そのような完了保証はありません。成功を返すと、メタデータが正常に受信されたことを意味しますが、メタデータがダウンストリームCDNで有効になる時期を正確に推測することはできず、最終的に有効になるだけです。これは、メタデータへの更新を、現在進行中の（または現在進行中の区別がつかない）エンドユーザーの要求とグローバルに同期させることが難しいためです。明らかに、「最終的に」不明確な期間になることが多い場合、CDNは信頼できるピアと見なされませんが、MIに対して責任の受け入れを明確に定義することはできません。
Finally, there is a practical issue that impacts all of the CDNI interfaces, and that is whether or not to optimize CDNI for HTTP Adaptive Streaming (HAS). We highlight specific issues related to delivering HAS content throughout this document, but for a more thorough treatment of the topic, see [RFC6983].
最後に、すべてのCDNIインターフェイスに影響する実用的な問題があり、それはHTTPアダプティブストリーミング（HAS）用にCDNIを最適化するかどうかです。このドキュメント全体でHASコンテンツの配信に関連する特定の問題を強調していますが、トピックのより完全な扱いについては、[RFC6983]を参照してください。
The remainder of this document is organized as follows:
このドキュメントの残りの部分は、次のように構成されています。
o Section 2 describes some essential building blocks for CDNI, notably the various options for redirecting user requests to a given CDN.
o セクション2では、CDNIのいくつかの重要な構成要素について説明します。特に、ユーザー要求を特定のCDNにリダイレクトするためのさまざまなオプションについて説明します。
o Section 3 provides a number of illustrative examples of various CDNI operations.
o セクション3では、さまざまなCDNI操作の多数の例を示します。
o Section 4 describes the functionality of the main CDNI interfaces.
o セクション4では、主なCDNIインターフェイスの機能について説明します。
o Section 5 shows how various deployment models of CDNI may be achieved using the defined interfaces.
o セクション5は、定義されたインターフェースを使用して、CDNIのさまざまなデプロイメントモデルをどのように実現できるかを示しています。
o Section 6 describes the trust model of CDNI and the issues of transitive trust in particular that CDNI raises.
o セクション6では、CDNIの信頼モデルと、特にCDNIが提起する推移的信頼の問題について説明します。
At its core, CDNI requires the redirection of requests from one CDN to another. For any given request that is received by an Upstream CDN, it will either respond to the request directly, or somehow redirect the request to a Downstream CDN. Two main mechanisms are available for redirecting a request to a Downstream CDN. The first leverages the DNS name resolution process and the second uses application-layer redirection mechanisms such as the HTTP 302 or Real-Time Streaming Protocol (RTSP) 302 redirection responses. While there exists a large variety of application-layer protocols that include some form of redirection mechanism, this document will use HTTP (and HTTPS) in its examples. Similar mechanisms can be applied to other application-layer protocols. What follows is a short discussion of both DNS- and HTTP-based redirection, before presenting some examples of their use in Section 3.
CDNIのコアでは、1つのCDNから別のCDNへの要求のリダイレクトが必要です。アップストリームCDNが受信した特定の要求については、要求に直接応答するか、何らかの方法で要求をダウンストリームCDNにリダイレクトします。要求をダウンストリームCDNにリダイレクトするには、2つの主要なメカニズムを使用できます。 1つ目はDNS名前解決プロセスを利用し、2つ目はHTTP 302またはリアルタイムストリーミングプロトコル（RTSP）302リダイレクト応答などのアプリケーション層リダイレクトメカニズムを使用します。何らかの形のリダイレクトメカニズムを含むさまざまなアプリケーション層プロトコルが存在しますが、このドキュメントでは、例としてHTTP（およびHTTPS）を使用します。同様のメカニズムを他のアプリケーション層プロトコルに適用できます。次のセクションでは、DNSベースとHTTPベースの両方のリダイレクトについて簡単に説明した後、セクション3でそれらの使用例をいくつか紹介します。
DNS redirection is based on returning different IP addresses for the same DNS name, for example, to balance server load or to account for the client's location in the network. A DNS server, sometimes called the Local DNS (LDNS), resolves DNS names on behalf of an end user. The LDNS server in turn queries other DNS servers until it reaches the authoritative DNS server for the CDN-Domain. The network operator typically provides the LDNS server, although the user is free to choose other DNS servers (e.g., OpenDNS, Google Public DNS).
DNSリダイレクションは、同じDNS名に対して異なるIPアドレスを返すことに基づいています。たとえば、サーバーの負荷を分散したり、ネットワーク内のクライアントの場所を明らかにしたりします。ローカルDNS（LDNS）とも呼ばれるDNSサーバーは、エンドユーザーに代わってDNS名を解決します。 LDNSサーバーは、CDNドメインの信頼できるDNSサーバーに到達するまで、他のDNSサーバーにクエリを送信します。ユーザーは他のDNSサーバー（OpenDNS、Google Public DNSなど）を自由に選択できますが、ネットワークオペレーターは通常、LDNSサーバーを提供します。
This latter possibility is important because the authoritative DNS server sees only the IP address of the DNS server that queries it, not the IP address of the original end user.
権限のあるDNSサーバーは、クエリを実行するDNSサーバーのIPアドレスのみを認識し、元のエンドユーザーのIPアドレスは認識しないため、この後者の可能性は重要です。
The advantage of DNS redirection is that it is completely transparent to the end user; the user sends a DNS name to the LDNS server and gets back an IP address. On the other hand, DNS redirection is problematic because the DNS request comes from the LDNS server, not the end user. This may affect the accuracy of server selection that is based on the user's location. The transparency of DNS redirection is also a problem in that there is no opportunity to take the attributes of the user agent or the URI path component into account. We consider two main forms of DNS redirection: simple and CNAME-based.
DNSリダイレクトの利点は、エンドユーザーに対して完全に透過的であることです。ユーザーはDNS名をLDNSサーバーに送信し、IPアドレスを取得します。一方、DNSリダイレクトはエンドユーザーではなくLDNSサーバーからのDNSリクエストであるため、問題があります。これは、ユーザーの場所に基づくサーバー選択の精度に影響を与える可能性があります。 DNSリダイレクションの透過性は、ユーザーエージェントまたはURIパスコンポーネントの属性を考慮する機会がないという点でも問題です。 DNSリダイレクションの2つの主要な形式、シンプルとCNAMEベースを検討します。
In simple DNS redirection, the authoritative DNS server for the name simply returns an IP address from a set of possible IP addresses. The answer is chosen from the set based on characteristics of the set (e.g., the relative loads on the servers) or characteristics of the client (e.g., the location of the client relative to the servers). Simple redirection is straightforward. The only caveats are (1) there is a limit to the number of alternate IP addresses a single DNS server can manage; and (2) DNS responses are cached by Downstream servers so the Time to Live (TTL) on the response must be set to an appropriate value so as to preserve the freshness of the redirection.
単純なDNSリダイレクトでは、名前の信頼できるDNSサーバーは、可能なIPアドレスのセットからIPアドレスを返すだけです。答えは、セットの特性（サーバー上の相対的な負荷など）またはクライアントの特性（サーバーに対するクライアントの場所など）に基づいて、セットから選択されます。単純なリダイレクトは簡単です。唯一の注意点は（1）1つのDNSサーバーが管理できる代替IPアドレスの数に制限があることです。 （2）DNS応答はダウンストリームサーバーによってキャッシュされるため、応答の有効期間（TTL）を適切な値に設定して、リダイレクトの鮮度を維持する必要があります。
In CNAME-based DNS redirection, the authoritative server returns a CNAME response to the DNS request, telling the LDNS server to restart the name lookup using a new name. A CNAME is essentially a symbolic link in the DNS namespace, and like a symbolic link, redirection is transparent to the client; the LDNS server gets the CNAME response and re-executes the lookup. Only when the name has been resolved to an IP address does it return the result to the user. Note that DNAME would be preferable to CNAME if it becomes widely supported.
CNAMEベースのDNSリダイレクトでは、権限のあるサーバーがDNS要求にCNAME応答を返し、LDNSサーバーに新しい名前を使用して名前の検索を再開するように指示します。 CNAMEは本質的にDNS名前空間のシンボリックリンクであり、シンボリックリンクと同様に、リダイレクトはクライアントに対して透過的です。 LDNSサーバーはCNAME応答を取得し、ルックアップを再実行します。名前がIPアドレスに解決された場合にのみ、結果がユーザーに返されます。広くサポートされるようになった場合、DNAMEはCNAMEよりも望ましいことに注意してください。
One of the advantages of DNS redirection compared to HTTP redirection is that it can be cached, reducing load on the redirecting CDN's DNS server. However, this advantage can also be a drawback, especially when a given DNS resolver doesn't strictly adhere to the TTL, which is a known problem in some real-world environments. In such cases, an end user might end up at a dCDN without first having passed through the uCDN, which might be an undesirable scenario from a uCDN point of view.
HTTPリダイレクションと比較したDNSリダイレクションの利点の1つは、キャッシュを使用できるため、リダイレクトするCDNのDNSサーバーの負荷を軽減できることです。ただし、この利点は、特に特定のDNSリゾルバーがTTLに厳密に準拠していない場合にも欠点となる可能性があり、これは一部の現実の環境では既知の問題です。このような場合、エンドユーザーは最初にuCDNを通過せずにdCDNに到達する可能性があります。これは、uCDNの観点からは望ましくないシナリオです。
HTTP redirection makes use of the redirection response of the HTTP protocol (e.g.,"302" or "307"). This response contains a new URL that the application should fetch instead of the original URL. By changing the URL appropriately, the server can cause the user to redirect to a different server. The advantages of HTTP redirection are that (1) the server can change the URL fetched by the client to include, for example, both the DNS name of the particular server to use, as well as the original HTTP server that was being accessed; (2) the client sends the HTTP request to the server, so that its IP address is known and can be used in selecting the server; and (3) other attributes (e.g., content type, user agent type) are visible to the redirection mechanism.
HTTPリダイレクションは、HTTPプロトコルのリダイレクション応答（「302」や「307」など）を利用します。この応答には、元のURLではなく、アプリケーションが取得する必要のある新しいURLが含まれています。 URLを適切に変更することで、サーバーはユーザーに別のサーバーにリダイレクトさせることができます。 HTTPリダイレクションの利点は、（1）サーバーがクライアントによってフェッチされたURLを変更して、たとえば、使用する特定のサーバーのDNS名と、アクセスされていた元のHTTPサーバーの両方を含めることができることです。 （2）クライアントはHTTPリクエストをサーバーに送信するため、そのIPアドレスは既知であり、サーバーの選択に使用できます。 （3）その他の属性（コンテンツタイプ、ユーザーエージェントタイプなど）がリダイレクトメカニズムに表示されます。
Just as is the case for DNS redirection, there are some potential disadvantages of using HTTP redirection. For example, it may affect application behavior; web browsers will not send cookies if the URL changes to a different domain. In addition, although this might also be an advantage, results of HTTP redirection are not cached so that all redirections must go through to the uCDN.
DNSリダイレクションの場合と同様に、HTTPリダイレクションの使用にはいくつかの潜在的な欠点があります。たとえば、アプリケーションの動作に影響を与える可能性があります。 URLが別のドメインに変更された場合、WebブラウザーはCookieを送信しません。さらに、これも利点になる可能性がありますが、HTTPリダイレクトの結果はキャッシュされないため、すべてのリダイレクトがuCDNに到達する必要があります。
To provide a big-picture overview of the various components of CDNI, we walk through a "day in the life" of a content item that is made available via a pair of interconnected CDNs. This will serve to illustrate many of the functions that need to be supported in a complete CDNI solution. We give examples using both DNS-based and HTTP-based redirection. We begin with very simple examples and then show how additional capabilities, such as recursive request redirection and content removal, might be added.
CDNIのさまざまなコンポーネントの全体像を提供するために、相互に接続された2つのCDNを介して利用可能になるコンテンツアイテムの「日常生活」について説明します。これは、完全なCDNIソリューションでサポートする必要がある機能の多くを示すのに役立ちます。 DNSベースとHTTPベースの両方のリダイレクトを使用した例を示します。非常に単純な例から始めて、再帰的なリクエストのリダイレクトやコンテンツの削除などの追加機能がどのように追加されるかを示します。
Before walking through the specific examples, we present a high-level view of the operations that may take place. This high-level overview is illustrated in Figure 2. Note that most operations will involve only a subset of all the messages shown below, and that the order and number of operations may vary considerably, as the more detailed examples illustrate.
特定の例を説明する前に、実行される可能性のある操作の概要を示します。この高レベルの概要を図2に示します。ほとんどの操作には、以下に示すすべてのメッセージのサブセットのみが含まれ、より詳細な例が示すように、操作の順序と数は大幅に異なる場合があります。
The following shows Operator A as the Upstream CDN (uCDN) and Operator B as the Downstream CDN (dCDN), where the former has a relationship with a content provider and the latter is the CDN selected by Operator A to deliver content to the end user. The interconnection relationship may be symmetric between these two CDN operators, but each direction can be considered as operating independently of the other; for simplicity, we show the interaction in one direction only.
以下は、オペレーターAをアップストリームCDN（uCDN）として、オペレーターBをダウンストリームCDN（dCDN）として示しています。前者はコンテンツプロバイダーと関係があり、後者はオペレーターAがコンテンツをエンドユーザーに配信するために選択したCDNです。 。相互接続関係は、これら2つのCDNオペレーター間で対称である場合がありますが、各方向は、他の方向とは独立して動作していると見なすことができます。簡単にするために、一方向のみの相互作用を示します。
End User Operator B Operator A
| | |
| | |
| | [Async FCI Push] | (1)
| | |
| | [MI pre-positioning] | (2)
| | |
| CONTENT REQUEST | |
|-------------------------------------------------->| (3)
| | |
| | [Sync RI Pull] | (4)
| | |
| CONTENT REQUEST REDIRECTION |
|<--------------------------------------------------| (5)
| | |
| | |
| CONTENT REQUEST | |
|------------------------>| | (6)
| | |
| | [Sync MI Pull] | (7)
| | |
| | ACQUISITION REQUEST |
| X------------------------>| (8)
| X |
| X CONTENT DATA |
| X<------------------------| (9)
| | |
| CONTENT DATA | |
|<------------------------| | (10)
| | |
: : :
: [Other content requests] :
: : :
| | [CI: Content Purge] | (11)
: : :
| | [LI: Log exchange] | (12)
| | |
Figure 2: Overview of Operation
図2：操作の概要
The operations shown in the figure are as follows:
図に示す操作は次のとおりです。
1. The dCDN uses the FCI to advertise information relevant to its delivery footprint and capabilities prior to any content requests being redirected.
1. dCDNはFCIを使用して、コンテンツ要求がリダイレクトされる前に、その配信フットプリントと機能に関連する情報をアドバタイズします。
2. Prior to any content request, the uCDN uses the MI to pre-position CDNI Metadata to the dCDN, thereby making that metadata available in readiness for later content requests.
2. コンテンツ要求の前に、uCDNはMIを使用してCDNIメタデータをdCDNに事前配信します。これにより、後のコンテンツ要求に備えてそのメタデータをすぐに使用できるようになります。
3. A content request from a user agent arrives at the uCDN.
3. ユーザーエージェントからのコンテンツ要求がuCDNに到着します。
4. The uCDN may use the RI to synchronously request information from the dCDN regarding its delivery capabilities to decide if the dCDN is a suitable target for redirection of this request.
4. uCDNは、RIを使用して、dCDNがこの要求のリダイレクトに適したターゲットであるかどうかを判断するために、その配信機能に関する情報をdCDNに同期的に要求します。
5. The uCDN redirects the request to the dCDN by sending some response (DNS, HTTP) to the user agent.
5. uCDNは、ユーザーエージェントに応答（DNS、HTTP）を送信することにより、要求をdCDNにリダイレクトします。
6. The user agent requests the content from the dCDN.
6. ユーザーエージェントは、dCDNにコンテンツを要求します。
7. The dCDN may use the MI to synchronously request metadata related to this content from uCDN, e.g., to decide whether to serve it.
7. dCDNはMIを使用して、このコンテンツに関連するメタデータをuCDNに同期的に要求し、たとえば、コンテンツを提供するかどうかを決定します。
8. If the content is not already in a suitable cache in the dCDN, the dCDN may acquire it from the uCDN.
8. コンテンツがdCDNの適切なキャッシュにまだない場合、dCDNはuCDNからコンテンツを取得できます。
9. The content is delivered to the dCDN from the uCDN.
9. コンテンツはuCDNからdCDNに配信されます。
10. The content is delivered to the user agent by the dCDN.
10. コンテンツは、dCDNによってユーザーエージェントに配信されます。
11. Some time later, perhaps at the request of the CSP (not shown) the uCDN may use the CI to instruct the dCDN to purge the content, thereby ensuring it is not delivered again.
11. しばらくして、おそらくCSP（図示せず）の要求に応じて、uCDNはCIを使用してdCDNにコンテンツをパージするように指示し、コンテンツが再度配信されないようにします。
12. After one or more content delivery actions by the dCDN, a log of delivery actions may be provided to the uCDN using the LI.
12. dCDNによる1つ以上のコンテンツ配信アクションの後、配信アクションのログがLIを使用してuCDNに提供されます。
The following sections show some more specific examples of how these operations may be combined to perform various delivery, control, and logging operations across a pair of CDNs.
以下のセクションでは、これらの操作を組み合わせて、CDNのペア全体でさまざまな配信、制御、およびロギング操作を実行する方法のいくつかのより具体的な例を示します。
Initially, we assume that there is at least one CSP that has contracted with an Upstream CDN (uCDN) to deliver content on its behalf. We are not particularly concerned with the interface between the CSP and uCDN, other than to note that it is expected to be the same as in the "traditional" (non-interconnected) CDN case. Existing mechanisms such as DNS CNAMEs or HTTP redirects (Section 2) can be used to direct a user request for a piece of content from the CSP towards the CSP's chosen Upstream CDN.
最初は、コンテンツを配信するためにアップストリームCDN（uCDN）と契約しているCSPが少なくとも1つあると想定しています。 「従来の」（相互接続されていない）CDNの場合と同じであると予想されることを除いて、CSPとuCDNの間のインターフェースは特に関係ありません。 DNS CNAMEやHTTPリダイレクト（セクション2）などの既存のメカニズムを使用して、ユーザーからのコンテンツの要求をCSPからCSPが選択したアップストリームCDNに転送できます。
We assume Operator A provides an Upstream CDN that serves content on behalf of a CSP with CDN-Domain cdn.csp.example. We assume that Operator B provides a Downstream CDN. An end user at some point makes a request for URL
オペレーターAが、CSPNに代わってCDNドメインcdn.csp.exampleを使用してコンテンツを提供するアップストリームCDNを提供すると想定します。オペレーターBがダウンストリームCDNを提供すると想定します。ある時点でエンドユーザーがURLを要求する
http://cdn.csp.example/...rest of URL...
http：//cdn.csp.example / ...残りのURL ...
It may well be the case that cdn.csp.example is just a CNAME for some other CDN-Domain (such as csp.op-a.example). Nevertheless, the HTTP request in the examples that follow is assumed to be for the example URL above.
cdn.csp.exampleが他のCDNドメイン（csp.op-a.exampleなど）のCNAMEにすぎない場合もあります。それでも、以下の例のHTTP要求は、上記のURLの例であると想定されています。
Our goal is to enable content identified by the above URL to be served by the CDN of Operator B. In the following sections, we will walk through some scenarios in which content is served as well as other CDNI operations such as the removal of content from a Downstream CDN.
私たちの目標は、上記のURLで識別されるコンテンツをオペレーターBのCDNで提供できるようにすることです。次のセクションでは、コンテンツが提供されるいくつかのシナリオと、コンテンツの削除などの他のCDNI操作について説明します。ダウンストリームCDN。
In this section, we walk through a simple, illustrative example using HTTP redirection from a uCDN to a dCDN. The example also assumes the use of HTTP redirection inside the uCDN and dCDN; however, this is independent of the choice of redirection approach across CDNs, so an alternative example could be constructed still showing HTTP redirection from the uCDN to dCDN but using DNS for the handling of the request inside each CDN.
このセクションでは、uCDNからdCDNへのHTTPリダイレクションを使用した簡単で説明的な例を紹介します。この例では、uCDNおよびdCDN内でのHTTPリダイレクションの使用も想定しています。ただし、これはCDN全体でのリダイレクトアプローチの選択とは無関係であるため、uCDNからdCDNへのHTTPリダイレクトを示しながら、各CDN内の要求の処理にDNSを使用する別の例を作成できます。
For this example, we assume that Operators A and B have established an agreement to interconnect their CDNs, with A being Upstream and B being Downstream.
この例では、オペレーターAとオペレーターBがCDNを相互接続するための合意を確立し、Aが上流、Bが下流であることを前提としています。
The operators agree that a CDN-Domain peer-a.op-b.example will be used as the target of redirections from the uCDN to dCDN. We assume the name of this domain is communicated by some means to each CDN. (This could be established out of band or via a CDNI interface.) We refer to this domain as a "distinguished" CDN-Domain to convey the fact that its use is limited to the interconnection mechanism; such a domain is never used directly by a CSP.
オペレーターは、CDNドメインのpeer-a.op-b.exampleがuCDNからdCDNへのリダイレクトのターゲットとして使用されることに同意します。このドメインの名前は、何らかの方法で各CDNに伝達されると想定しています。 （これは、帯域外またはCDNIインターフェイスを介して確立できます。）このドメインを「区別された」CDNドメインと呼び、その使用が相互接続メカニズムに限定されていることを伝えます。このようなドメインは、CSPによって直接使用されることはありません。
We assume the operators also agree on some distinguished CDN-Domain that will be used for inter-CDN acquisition of the CSP's content from the uCDN by the dCDN. In this example, we'll use op-b-acq.op-a.example.
オペレーターは、dCDNによるuCDNからのCSPのコンテンツのCDN間取得に使用されるいくつかの際立ったCDNドメインにも同意するものとします。この例では、op-b-acq.op-a.exampleを使用します。
We assume the operators also exchange information regarding which requests the dCDN is prepared to serve. For example, the dCDN may be prepared to serve requests from clients in a given geographical region or a set of IP address prefixes. This information may again be provided out of band or via a defined CDNI interface.
オペレーターは、dCDNが提供する準備ができている要求に関する情報も交換すると想定します。たとえば、dCDNは、特定の地理的領域または一連のIPアドレスプレフィックスでクライアントからの要求に対応するように準備できます。この情報も、帯域外または定義済みのCDNIインターフェースを介して提供されます。
We assume DNS is configured in the following way:
DNSは次のように構成されていると想定します。
o The content provider is configured to make Operator A the authoritative DNS server for cdn.csp.example (or to return a CNAME for cdn.csp.example for which Operator A is the authoritative DNS server).
o コンテンツプロバイダーは、オペレーターAをcdn.csp.exampleの権限のあるDNSサーバーにする（またはオペレーターAが権限のあるDNSサーバーであるcdn.csp.exampleのCNAMEを返す）ように構成されています。
o Operator A is configured so that a DNS request for op-b-acq.op-a.example returns a Request Router in Operator A.
o オペレーターAは、op-b-acq.op-a.exampleのDNS要求がオペレーターAの要求ルーターを返すように構成されています。
o Operator B is configured so that a DNS request for peer-a.op-b.example/cdn.csp.example returns a Request Router in Operator B.
o オペレーターBは、peer-a.op-b.example / cdn.csp.exampleに対するDNS要求がオペレーターBの要求ルーターを返すように構成されています。
Figure 3 illustrates how a client request for
図3は、クライアントが
http://cdn.csp.example/...rest of URL...
http：//cdn.csp.example / ...残りのURL ...
is handled.
扱われます。
End User Operator B Operator A
|DNS cdn.csp.example | |
|-------------------------------------------------->|
| | |(1)
|IPaddr of A's Request Router |
|<--------------------------------------------------|
|HTTP cdn.csp.example | |
|-------------------------------------------------->|
| | |(2)
|302 peer-a.op-b.example/cdn.csp.example |
|<--------------------------------------------------|
|DNS peer-a.op-b.example | |
|------------------------>| |
| |(3) |
|IPaddr of B's Request Router |
|<------------------------| |
| | |
|HTTP peer-a.op-b.example/cdn.csp.example |
|------------------------>| |
| |(4) |
|302 node1.peer-a.op-b.example/cdn.csp.example |
|<------------------------| |
|DNS node1.peer-a.op-b.example |
|------------------------>| |
| |(5) |
|IPaddr of B's Delivery Node |
|<------------------------| |
| | |
|HTTP node1.peer-a.op-b.example/cdn.csp.example |
|------------------------>| |
| |(6) |
| |DNS op-b-acq.op-a.example|
| |------------------------>|
| | |(7)
| |IPaddr of A's Request Router
| |<------------------------|
| |HTTP op-b-acq.op-a.example
| |------------------------>|
| | |(8)
| |302 node2.op-b-acq.op-a.example
| |<------------------------|
| |DNS node2.op-b-acq.op-a.example
| |------------------------>|
| | |(9)
| |IPaddr of A's Delivery Node
| |<------------------------|
| | |
| |HTTP node2.op-b-acq.op-a.example
| |------------------------>|
| | |(10)
| |Data |
| |<------------------------|
|Data | |
|<------------------------| |
Figure 3: Message Flow for Iterative HTTP Redirection
図3：反復HTTPリダイレクションのメッセージフロー
The steps illustrated in the figure are as follows:
図に示す手順は次のとおりです。
1. A DNS resolver for Operator A processes the DNS request for its customer based on CDN-Domain cdn.csp.example. It returns the IP address of a Request Router in Operator A.
1. オペレーターAのDNSリゾルバーは、CDNドメインcdn.csp.exampleに基づいて、顧客のDNS要求を処理します。オペレーターAの要求ルーターのIPアドレスを返します。
2. A Request Router for Operator A processes the HTTP request and recognizes that the end user is best served by another CDN, specifically one provided by Operator B, and so it returns a 302 redirect message for a new URL constructed by "stacking" Operator B's distinguished CDN-Domain (peer-a.op-b.example) on the front of the original URL. (Note that more complex URL manipulations are possible, such as replacing the initial CDN-Domain by some opaque handle.)
2.オペレーターAのリクエストルーターがHTTPリクエストを処理し、エンドユーザーが別のCDN、特にオペレーターBが提供するCDNが最適であると認識し、「スタッキング」オペレーターによって作成された新しいURLの302リダイレクトメッセージを返します。元のURLの前にあるBの識別されたCDNドメイン（peer-a.op-b.example）。 （初期のCDNドメインを不透明なハンドルで置き換えるなど、より複雑なURL操作が可能であることに注意してください。）
3. The end user does a DNS lookup using Operator B's distinguished CDN-Domain (peer-a.op-b.example). B's DNS resolver returns the IP address of a Request Router for Operator B. Note that if request routing within the dCDN was performed using DNS instead of HTTP redirection, B's DNS resolver would also behave as the Request Router and directly return the IP address of a delivery node.
3. エンドユーザーは、オペレーターBの識別されたCDNドメイン（peer-a.op-b.example）を使用してDNSルックアップを実行します。 BのDNSリゾルバーはオペレーターBのリクエストルーターのIPアドレスを返します。dCDN内のリクエストルーティングがHTTPリダイレクションの代わりにDNSを使用して実行された場合、BのDNSリゾルバーはリクエストルーターとしても動作し、直接IPアドレスを返します。配信ノード。
4. The Request Router for Operator B processes the HTTP request and selects a suitable delivery node to serve the end-user request, and it returns a 302 redirect message for a new URL constructed by replacing the hostname with a subdomain of the Operator B's distinguished CDN-Domain that points to the selected delivery node.
4. オペレーターBのリクエストルーターは、HTTPリクエストを処理し、エンドユーザーリクエストに対応する適切な配信ノードを選択し、ホスト名をオペレーターBの識別されたCDNのサブドメインに置き換えることによって構築された新しいURLの302リダイレクトメッセージを返します。選択した配信ノードを指すドメイン。
5. The end user does a DNS lookup using Operator B's delivery node subdomain (node1.peer-a.op-b.example). B's DNS resolver returns the IP address of the delivery node.
5. エンドユーザーは、オペレーターBの配信ノードサブドメイン（node1.peer-a.op-b.example）を使用してDNSルックアップを実行します。 BのDNSリゾルバーは、配信ノードのIPアドレスを返します。
6. The end user requests the content from B's delivery node. In the case of a cache hit, steps 6, 7, 8, 9, and 10 below do not happen, and the content data is directly returned by the delivery node to the end user. In the case of a cache miss, the content needs to be acquired by the dCDN from the uCDN (not the CSP). The distinguished CDN-Domain peer-a.op-b.example indicates to the dCDN that this content is to be acquired from the uCDN; stripping the CDN-Domain reveals the original CDN-Domain cdn.csp.example, and the dCDN may verify that this CDN-Domain belongs to a known peer (so as to avoid being tricked into serving as an open proxy). It then does a DNS request for an inter-CDN acquisition CDN-Domain as agreed above (in this case, op-b-acq.op-a.example).
6. エンドユーザーはBの配信ノードにコンテンツを要求します。キャッシュヒットの場合、以下の手順6、7、8、9、および10は発生せず、コンテンツデータは配信ノードからエンドユーザーに直接返されます。キャッシュミスの場合、コンテンツは、（CDではなく）uCDNからdCDNによって取得される必要があります。識別されたCDNドメインpeer-a.op-b.exampleは、このコンテンツがuCDNから取得されることをdCDNに示します。 CDN-Domainを取り除くと、元のCDN-Domain cdn.csp.exampleが明らかになり、dCDNはこのCDN-Domainが既知のピアに属していることを確認できます（だまされてオープンプロキシとして機能するのを回避するため）。次に、上記で合意したように、CDN間取得CDNドメインのDNS要求を行います（この場合は、op-b-acq.op-a.example）。
7. Operator A's DNS resolver processes the DNS request and returns the IP address of a Request Router in Operator A.
7. オペレーターAのDNSリゾルバーはDNS要求を処理し、オペレーターAの要求ルーターのIPアドレスを返します。
8. The Request Router for Operator A processes the HTTP request from Operator B's delivery node. Operator A's Request Router recognizes that the request is from a peer CDN rather than an end user because of the dedicated inter-CDN acquisition domain (op-b-acq.op-a.example). (Note that without this specially defined inter-CDN acquisition domain, Operator A would be at risk of redirecting the request back to Operator B, resulting in an infinite loop). The Request Router for Operator A selects a suitable delivery node in uCDN to serve the inter-CDN acquisition request and returns a 302 redirect message for a new URL constructed by replacing the hostname with a subdomain of the Operator A's distinguished inter-CDN acquisition domain that points to the selected delivery node.
8.オペレーターAの要求ルーターは、オペレーターBの配信ノードからのHTTP要求を処理します。オペレーターAのリクエストルーターは、専用のCDN間取得ドメイン（op-b-acq.op-a.example）があるため、リクエストがエンドユーザーではなくピアCDNからのものであることを認識します。 （この特別に定義されたCDN間取得ドメインがない場合、オペレーターAはリクエストをオペレーターBにリダイレクトして、無限ループに陥るリスクがあることに注意してください）。オペレーターAのリクエストルーターは、CDN間取得要求を処理するためにuCDNの適切な配信ノードを選択し、ホスト名をオペレーターAの識別されたCDN間取得ドメインのサブドメインに置き換えることによって構築された新しいURLの302リダイレクトメッセージを返します。選択した配信ノードを指します。
9. Operator A's DNS resolver processes the DNS request and returns the IP address of the delivery node in Operator A.
9. オペレーターAのDNSリゾルバーはDNS要求を処理し、オペレーターAの配信ノードのIPアドレスを返します。
10. Operator B requests (acquires) the content from Operator A. Although not shown, Operator A processes the rest of the URL: it extracts information identifying the origin server, validates that this server has been registered, and determines the content provider that owns the origin server. It may also perform its own content acquisition steps if needed before returning the content to dCDN.
10. オペレーターBはオペレーターAにコンテンツを要求（取得）します。ここには示されていませんが、オペレーターAは残りのURLを処理します。つまり、オリジンサーバーを識別する情報を抽出し、このサーバーが登録されていることを検証し、オリジンを所有するコンテンツプロバイダーを決定します。サーバ。また、コンテンツをdCDNに戻す前に、必要に応じて独自のコンテンツ取得手順を実行する場合もあります。
The main advantage of this design is that it is simple: each CDN need only know the distinguished CDN-Domain for each peer, with the Upstream CDN "pushing" the Downstream CDN-Domain onto the URL as part of its redirect (step 2), and the Downstream CDN "popping" its CDN-Domain off the URL to expose a CDN-Domain that the Upstream CDN can correctly process. Neither CDN need be aware of the internal structure of the other's URLs. Moreover, the inter-CDN redirection is entirely supported by a single HTTP redirect; neither CDN need be aware of the other's internal redirection mechanism (i.e., whether it is DNS or HTTP based).
この設計の主な利点は、シンプルであることです。各CDNは、各ピアの識別されたCDNドメインのみを知っていればよく、アップストリームCDNは、リダイレクトの一部としてURLにダウンストリームCDNドメインを「プッシュ」します（ステップ2）。 、およびダウンストリームCDNは、そのCDNドメインをURLから「ポップ」して、アップストリームCDNが正しく処理できるCDNドメインを公開します。どちらのCDNも、相手のURLの内部構造を認識する必要はありません。さらに、CDN間のリダイレクトは、単一のHTTPリダイレクトによって完全にサポートされています。どちらのCDNも、相手の内部リダイレクトメカニズム（つまり、DNSベースかHTTPベースか）を認識する必要はありません。
One disadvantage is that the end user's browser is redirected to a new URL that is not in the same domain of the original URL. This has implications on a number of security or validation mechanisms sometimes used on endpoints. For example, it is important that any redirected URL be in the same domain (e.g., csp.example) if the browser is expected to send any cookies associated with that domain. As another example, some video players enforce validation of a cross-domain policy that needs to accommodate the domains involved in the CDN redirection. These problems are generally solvable, but the solutions complicate the example, so we do not discuss them further in this document.
欠点の1つは、エンドユーザーのブラウザーが、元のURLと同じドメインにない新しいURLにリダイレクトされることです。これは、エンドポイントで使用されることがある多くのセキュリティまたは検証メカニズムに影響を与えます。たとえば、ブラウザがそのドメインに関連付けられたCookieを送信することが予想される場合、リダイレクトされたURLが同じドメイン（csp.exampleなど）にあることが重要です。別の例として、一部のビデオプレーヤーは、CDNリダイレクトに関与するドメインに対応する必要があるクロスドメインポリシーの検証を実施します。これらの問題は一般に解決可能ですが、解決策は例を複雑にするため、このドキュメントではそれらについてこれ以上説明しません。
We note that this example begins to illustrate some of the interfaces that may be required for CDNI, but it does not require all of them. For example, obtaining information from a dCDN regarding the set of client IP addresses or geographic regions it might be able to serve is an aspect of request routing (specifically of the CDNI Footprint & Capabilities Advertisement interface). Important configuration information such as the distinguished names used for redirection and inter-CDN acquisition could also be conveyed via a CDNI interface (e.g., perhaps the CDNI Control interface). The example also shows how existing HTTP-based methods suffice for the acquisition interface. Arguably, the absolute minimum metadata required for CDNI is the information required to acquire the content, and this information was provided "in-band" in this example by means of the URI handed to the client in the HTTP 302 response. The example also assumes that the CSP does not require any distribution policy (e.g., time window or geo-blocking) or delivery processing to be applied by the interconnected CDNs. Hence, there is no explicit CDNI Metadata interface invoked in this example. There is also no explicit CDNI Logging interface discussed in this example.
この例では、CDNIに必要となる可能性のある一部のインターフェースを示し始めていますが、すべてのインターフェースが必要なわけではありません。たとえば、dCDNから提供できる一連のクライアントIPアドレスまたは地理的領域に関する情報を取得することは、要求ルーティング（特にCDNI Footprint＆Capabilities Advertisementインターフェースの）の側面です。リダイレクトやCDN間取得に使用される識別名などの重要な構成情報は、CDNIインターフェース（例：CDNI制御インターフェース）を介して伝達することもできます。この例は、既存のHTTPベースのメソッドが取得インターフェイスにどのように十分対応できるかも示しています。間違いなく、CDNIに必要な絶対最小メタデータはコンテンツを取得するために必要な情報であり、この情報は、この例ではHTTP 302応答でクライアントに渡されたURIによって「インバンド」で提供されました。この例では、CSPが相互接続されたCDNによって適用される配信ポリシー（タイムウィンドウやジオブロッキングなど）または配信処理を必要としないことも想定しています。したがって、この例で呼び出される明示的なCDNIメタデータインターフェイスはありません。この例では、明示的なCDNIログインターフェイスについても説明していません。
We also note that the step of deciding when a request should be redirected to the dCDN rather than served by the uCDN has been somewhat glossed over. It may be as simple as checking the client IP address against a list of prefixes, or it may be considerably more complex, involving a wide range of factors, such as the geographic location of the client (perhaps determined from a third-party service), CDN load, or specific business rules.
また、リクエストをuCDNで処理するのではなく、dCDNにリダイレクトするタイミングを決定する手順については、いくぶん詳しく説明していません。プレフィックスのリストに対してクライアントのIPアドレスをチェックするだけの簡単な場合もあれば、クライアントの地理的位置などのさまざまな要因（おそらくサードパーティのサービスから決定される）など、かなり複雑な場合もあります。 、CDNロード、または特定のビジネスルール。
This example uses the "iterative" CDNI request redirection approach. That is, a uCDN performs part of the request redirection function by redirecting the client to a Request Router in the dCDN, which then performs the rest of the redirection function by redirecting to a suitable Surrogate. If request routing is performed in the dCDN using HTTP redirection, this translates in the end user experiencing two successive HTTP redirections. By contrast, the alternative approach of "recursive" CDNI request redirection effectively coalesces these two successive HTTP redirections into a single one, sending the end user directly to the right delivery node in the dCDN. This "recursive" CDNI request routing approach is discussed in the next section.
この例では、「反復的」CDNI要求リダイレクト手法を使用しています。つまり、uCDNは、クライアントをdCDN内のリクエストルーターにリダイレクトすることにより、リクエストリダイレクト機能の一部を実行し、その後、適切なサロゲートにリダイレクトすることにより、残りのリダイレクト機能を実行します。 HTTPリダイレクトを使用してリクエストルーティングがdCDNで実行される場合、これはエンドユーザーが2つの連続したHTTPリダイレクトを経験することを意味します。対照的に、「再帰的」CDNI要求リダイレクトの代替アプローチは、これら2つの連続したHTTPリダイレクトを単一のリダイレクトに効果的に合体させ、エンドユーザーをdCDNの適切な配信ノードに直接送信します。この「再帰的な」CDNIリクエストルーティングアプローチについては、次のセクションで説明します。
While the example above uses HTTP, the iterative HTTP redirection mechanism would work over HTTPS in a similar fashion. In order to make sure an end user's HTTPS request is not downgraded to HTTP along the redirection path, it is necessary for every Request Router along the path from the initial uCDN Request Router to the final Surrogate in the dCDN to respond to an incoming HTTPS request with an HTTP redirect containing an HTTPS URL. It should be noted that using HTTPS will have the effect of increasing the total redirection process time and increasing the load on the Request Routers, especially when the redirection path includes many redirects and thus many Secure Socket Layer/Transport Layer Security (SSL/TLS) sessions. In such cases, a recursive HTTP redirection mechanism, as described in an example in the next section, might help to reduce some of these issues.
上記の例ではHTTPを使用していますが、反復的なHTTPリダイレクションメカニズムはHTTPSを介して同様に機能します。エンドユーザーのHTTPSリクエストがリダイレクトパスでHTTPにダウングレードされないようにするために、最初のuCDNリクエストルーターからdCDNの最後のサロゲートまでのパスにあるすべてのリクエストルーターが着信HTTPSリクエストに応答する必要があります。 HTTPS URLを含むHTTPリダイレクト。 HTTPSを使用すると、リダイレクトプロセスの合計時間が増加し、リクエストルーターの負荷が増加することに注意してください。特に、リダイレクトパスに多くのリダイレクトが含まれ、したがって多くのSecure Socket Layer / Transport Layer Security（SSL / TLS）が含まれる場合に注意してください。セッション。このような場合、次のセクションの例で説明するように、再帰的なHTTPリダイレクションメカニズムがこれらの問題のいくつかを軽減するのに役立つ場合があります。
The following example builds on the previous one to illustrate the use of the request routing interface (specifically, the CDNI Request Routing Redirection interface) to enable "recursive" CDNI request routing. We build on the HTTP-based redirection approach because it illustrates the principles and benefits clearly, but it is equally possible to perform recursive redirection when DNS-based redirection is employed.
次の例は、前の例に基づいて、リクエストルーティングインターフェース（具体的には、CDNIリクエストルーティングリダイレクションインターフェース）を使用して「再帰的な」CDNIリクエストルーティングを有効にする方法を示しています。 HTTPベースのリダイレクションアプローチは、原理と利点を明確に示しているため構築していますが、DNSベースのリダイレクションが採用されている場合は、再帰的なリダイレクションを実行することも同様に可能です。
In contrast to the prior example, the operators need not agree in advance on a CDN-Domain to serve as the target of redirections from the uCDN to dCDN. We assume that the operators agree on some distinguished CDN-Domain that will be used for inter-CDN acquisition of the CSP's content by dCDN. In this example, we'll use op-b-acq.op-a.example.
前の例とは対照的に、uCDNからdCDNへのリダイレクトのターゲットとして機能するために、オペレーターはCDNドメインについて事前に合意する必要はありません。オペレーターは、dCDNによるCSPのコンテンツのCDN間取得に使用されるいくつかの際立ったCDNドメインに同意するものとします。この例では、op-b-acq.op-a.exampleを使用します。
We assume the operators also exchange information regarding which requests the dCDN is prepared to serve. For example, the dCDN may be prepared to serve requests from clients in a given geographical region or a set of IP address prefixes. This information may again be provided out of band or via a defined protocol.
オペレーターは、dCDNが提供する準備ができている要求に関する情報も交換すると想定します。たとえば、dCDNは、特定の地理的領域または一連のIPアドレスプレフィックスでクライアントからの要求に対応するように準備できます。この情報も、帯域外または定義されたプロトコルを介して提供されます。
We assume DNS is configured in the following way:
DNSは次のように構成されていると想定します。
o The content provider is configured to make Operator A the authoritative DNS server for cdn.csp.example (or to return a CNAME for cdn.csp.example for which Operator A is the authoritative DNS server).
o コンテンツプロバイダーは、オペレーターAをcdn.csp.exampleの権限のあるDNSサーバーにする（またはオペレーターAが権限のあるDNSサーバーであるcdn.csp.exampleのCNAMEを返す）ように構成されています。
o Operator A is configured so that a DNS request for op-b-acq.op-a.example returns a Request Router in Operator A.
o オペレーターAは、op-b-acq.op-a.exampleのDNS要求がオペレーターAの要求ルーターを返すように構成されています。
o Operator B is configured so that a request for node1.op-b.example/ cdn.csp.example returns the IP address of a delivery node. Note that there might be a number of such delivery nodes.
o オペレーターBは、node1.op-b.example / cdn.csp.exampleに対する要求が配信ノードのIPアドレスを返すように構成されています。このような配信ノードが多数存在する可能性があることに注意してください。
Figure 3 illustrates how a client request for
図3は、クライアントが
http://cdn.csp.example/...rest of URL...
http：//cdn.csp.example / ...残りのURL ...
is handled.
扱われます。
End User Operator B Operator A
|DNS cdn.csp.example | |
|-------------------------------------------------->|
| | |(1)
|IPaddr of A's Request Router |
|<--------------------------------------------------|
|HTTP cdn.csp.example | |
|-------------------------------------------------->|
| | |(2)
| |RR/RI REQ cdn.csp.example|
| |<------------------------|
| | |
| |RR/RI RESP node1.op-b.example
| |------------------------>|
| | |(3)
|302 node1.op-b.example/cdn.csp.example |
|<--------------------------------------------------|
|DNS node1.op-b.example | |
|------------------------>| |
| |(4) |
|IPaddr of B's Delivery Node |
|<------------------------| |
|HTTP node1.op-b.example/cdn.csp.example |
|------------------------>| |
| |(5) |
| |DNS op-b-acq.op-a.example|
| |------------------------>|
| | |(6)
| |IPaddr of A's Request Router
| |<------------------------|
| |HTTP op-b-acq.op-a.example
| |------------------------>|
| | |(7)
| |302 node2.op-b-acq.op-a.example
| |<------------------------|
| |DNS node2.op-b-acq.op-a.example
| |------------------------>|
| | |(8)
| |IPaddr of A's Delivery Node
| |<------------------------|
| | |
| |HTTP node2.op-b-acq.op-a.example
| |------------------------>|
| | |(9)
| |Data |
| |<------------------------|
|Data | |
|<------------------------| |
Figure 4: Message Flow for Recursive HTTP Redirection
図4：再帰的なHTTPリダイレクトのメッセージフロー
The steps illustrated in the figure are as follows:
図に示す手順は次のとおりです。
1. A DNS resolver for Operator A processes the DNS request for its customer based on CDN-Domain cdn.csp.example. It returns the IP address of a Request Router in Operator A.
1. オペレーターAのDNSリゾルバーは、CDNドメインcdn.csp.exampleに基づいて、顧客のDNS要求を処理します。オペレーターAの要求ルーターのIPアドレスを返します。
2. A Request Router for Operator A processes the HTTP request and recognizes that the end user is best served by another CDN -- specifically one provided by Operator B -- so it queries the CDNI Request Routing Redirection interface of Operator B, providing a set of information about the request including the URL requested. Operator B replies with the DNS name of a delivery node.
2. オペレーターAのリクエストルーターがHTTPリクエストを処理し、エンドユーザーが別のCDN（特にオペレーターBが提供するCDN）が最適なサービスであることを認識するため、オペレーターBのCDNIリクエストルーティングリダイレクションインターフェースにクエリを送信し、一連の情報を提供します。リクエストされたURLを含むリクエストについて。オペレーターBは、配信ノードのDNS名で応答します。
3. Operator A returns a 302 redirect message for a new URL obtained from the RI.
3. オペレーターAは、RIから取得した新しいURLの302リダイレクトメッセージを返します。
4. The end user does a DNS lookup using the hostname of the URL just provided (node1.op-b.example). B's DNS resolver returns the IP address of the corresponding delivery node. Note that, since the name of the delivery node was already obtained from B using the RI, there should not be any further redirection here (in contrast to the iterative method described above.)
4. エンドユーザーは、提供されたURL（node1.op-b.example）のホスト名を使用してDNSルックアップを実行します。 BのDNSリゾルバーは、対応する配信ノードのIPアドレスを返します。配信ノードの名前はRIを使用してBからすでに取得されているため、ここではこれ以上のリダイレクトは行わないでください（上記の反復方法とは対照的です）。
5. The end user requests the content from B's delivery node, potentially resulting in a cache miss. In the case of a cache miss, the content needs to be acquired from the uCDN (not the CSP.) The distinguished CDN-Domain op-b.example indicates to the dCDN that this content is to be acquired from another CDN; stripping the CDN-Domain reveals the original CDN-Domain cdn.csp.example. The dCDN may verify that this CDN-Domain belongs to a known peer (so as to avoid being tricked into serving as an open proxy). It then does a DNS request for the inter-CDN Acquisition "distinguished" CDN-Domain as agreed above (in this case, op-b-acq.op-a.example).
5.エンドユーザーがBの配信ノードにコンテンツを要求し、キャッシュミスが発生する可能性があります。キャッシュミスの場合、コンテンツは（CDではなく）uCDNから取得する必要があります。区別されたCDN-Domain op-b.exampleは、このコンテンツが別のCDNから取得されることをdCDNに示します。 CDN-Domainを削除すると、元のCDN-Domain cdn.csp.exampleが明らかになります。 dCDNは、このCDNドメインが既知のピアに属していることを確認する場合があります（だまされてオープンプロキシとして機能することを回避するため）。次に、上記で合意したように、CDN間取得の「区別された」CDNドメイン（この場合はop-b-acq.op-a.example）に対してDNS要求を行います。
6. Operator A's DNS resolver processes the DNS request and returns the IP address of a Request Router in Operator A.
6. オペレーターAのDNSリゾルバーはDNS要求を処理し、オペレーターAの要求ルーターのIPアドレスを返します。
7. The Request Router for Operator A processes the HTTP request from Operator B's delivery node. Operator A's Request Router recognizes that the request is from a peer CDN rather than an end user because of the dedicated inter-CDN acquisition domain (op-b-acq.op-a.example). (Note that without this specially defined inter-CDN acquisition domain, Operator A would be at risk of redirecting the request back to Operator B, resulting in an infinite loop). The Request Router for Operator A selects a suitable delivery node in the uCDN to serve the inter-CDN acquisition request and returns a 302 redirect message for a new URL constructed by replacing the hostname with a subdomain of the Operator A's distinguished inter-CDN acquisition domain that points to the selected delivery node.
7. オペレーターAの要求ルーターは、オペレーターBの配信ノードからのHTTP要求を処理します。オペレーターAのリクエストルーターは、専用のCDN間取得ドメイン（op-b-acq.op-a.example）があるため、リクエストがエンドユーザーではなくピアCDNからのものであることを認識します。 （この特別に定義されたCDN間取得ドメインがない場合、オペレーターAはリクエストをオペレーターBにリダイレクトして、無限ループに陥るリスクがあることに注意してください）。オペレーターAのリクエストルーターは、CDN間取得リクエストを処理するためにuCDN内の適切な配信ノードを選択し、ホスト名をオペレーターAの識別されたCDN間取得ドメインのサブドメインに置き換えることによって構築された新しいURLの302リダイレクトメッセージを返します選択した配信ノードを指します。
8. Operator A recognizes that the DNS request is from a peer CDN rather than an end user (due to the internal CDN-Domain) and so returns the address of a delivery node. (Note that without this specially defined internal domain, Operator A would be at risk of redirecting the request back to Operator B, resulting in an infinite loop.)
8. オペレーターAは、DNS要求がエンドユーザーではなくピアCDNからのものであることを認識し（内部CDNドメインにより）、配信ノードのアドレスを返します。 （この特別に定義された内部ドメインがないと、オペレーターAはリクエストをオペレーターBにリダイレクトして、無限ループに陥る危険があることに注意してください。）
9. Operator B requests (acquires) the content from Operator A. Operator A serves content for the requested CDN-Domain to the dCDN. Although not shown, it is at this point that Operator A processes the rest of the URL: it extracts information identifying the origin server, validates that this server has been registered, and determines the content provider that owns the origin server. It may also perform its own content acquisition steps if needed before returning the content to the dCDN.
9. オペレーターBは、オペレーターAにコンテンツを要求（取得）します。オペレーターAは、要求されたCDNドメインのコンテンツをdCDNに提供します。示されていないが、この時点でオペレーターAは残りのURLを処理します。つまり、オリジンサーバーを識別する情報を抽出し、このサーバーが登録されていることを検証し、オリジンサーバーを所有するコンテンツプロバイダーを決定します。また、コンテンツをdCDNに返す前に、必要に応じて独自のコンテンツ取得手順を実行する場合もあります。
Recursive redirection has the advantage (over iterative redirection) of being more transparent from the end user's perspective but the disadvantage of each CDN exposing more of its internal structure (in particular, the addresses of edge caches) to peer CDNs. By contrast, iterative redirection does not require the dCDN to expose the addresses of its edge caches to the uCDN.
再帰リダイレクトには、エンドユーザーの観点から透過的になるという利点（反復リダイレクトよりも）がありますが、各CDNが内部構造（特にエッジキャッシュのアドレス）をピアCDNに公開するという欠点があります。対照的に、反復リダイレクトでは、エッジキャッシュのアドレスをuCDNに公開するためにdCDNは必要ありません。
This example happens to use HTTP-based redirection in both CDN A and CDN B, but a similar example could be constructed using DNS-based redirection in either CDN. Hence, the key point to take away here is simply that the end user only sees a single redirection of some type, as opposed to the pair of redirections in the prior (iterative) example.
この例では、CDN AとCDN Bの両方でHTTPベースのリダイレクトを使用していますが、どちらかのCDNでDNSベースのリダイレクトを使用して同様の例を構築できます。したがって、ここで取り上げるべき重要な点は、前の（反復的な）例のリダイレクトのペアとは対照的に、エンドユーザーにはあるタイプの単一のリダイレクトしか表示されないということです。
The use of the RI requires that the request routing mechanism be appropriately configured and bootstrapped, which is not shown here. More discussion on the bootstrapping of interfaces is provided in Section 4
RIを使用するには、リクエストルーティングメカニズムを適切に構成してブートストラップする必要がありますが、ここでは示していません。インターフェースのブートストラップに関する詳細は、セクション4で説明します。
In this section we walk through a simple example using DNS-based redirection for request redirection from the uCDN to the dCDN (as well as for request routing inside the dCDN and the uCDN). As noted in Section 2.1, DNS-based redirection has certain advantages over HTTP-based redirection (notably, it is transparent to the end user) as well as some drawbacks (notably, the client IP address is not visible to the Request Router).
このセクションでは、uCDNからdCDNへの要求リダイレクト（およびdCDNとuCDN内の要求ルーティング）にDNSベースのリダイレクトを使用する簡単な例について説明します。セクション2.1で述べたように、DNSベースのリダイレクトには、HTTPベースのリダイレクトに比べていくつかの利点があります（特に、エンドユーザーに対して透過的です）だけでなく、いくつかの欠点もあります（特に、クライアントIPアドレスがリクエストルーターに見えない）。
As before, Operator A has to learn the set of requests that the dCDN is willing or able to serve (e.g., which client IP address prefixes or geographic regions are part of the dCDN footprint). We assume Operator B has and makes known to Operator A some unique identifier that can be used for the construction of a distinguished CDN-Domain, as shown in more detail below. (This identifier strictly needs only to be unique within the scope of Operator A, but a globally unique identifier, such as an Autonomous System (AS) number assigned to B, is one easy way to achieve that.) Also, Operator A obtains the NS records for Operator B's externally visible redirection servers. Also, as before, a distinguished CDN-Domain, such as op-b-acq.op-a.example, must be assigned for inter-CDN acquisition.
以前と同様に、オペレーターAは、dCDNが提供する意思がある、または提供できる一連の要求を学習する必要があります（たとえば、どのクライアントIPアドレスプレフィックスまたは地理的領域がdCDNフットプリントの一部であるか）。以下に詳細を示すように、オペレーターBは、識別されたCDNドメインの構築に使用できるいくつかの一意の識別子をオペレーターAに保持していることを前提としています。 （この識別子は、オペレーターAのスコープ内で一意である必要がありますが、Bに割り当てられた自律システム（AS）番号などのグローバルに一意の識別子は、これを達成する1つの簡単な方法です。）また、オペレーターAは、オペレーターBの外部から見えるリダイレクトサーバーのNSレコード。また、以前と同様に、op-b-acq.op-a.exampleなどの識別されたCDNドメインをCDN間取得に割り当てる必要があります。
We assume DNS is configured in the following way:
DNSは次のように構成されていると想定します。
o The CSP is configured to make Operator A the authoritative DNS server for cdn.csp.example (or to return a CNAME for cdn.csp.example for which Operator A is the authoritative DNS server).
o CSPは、オペレーターAをcdn.csp.exampleの信頼できるDNSサーバーにする（またはオペレーターAが信頼できるDNSサーバーであるcdn.csp.exampleのCNAMEを返す）ように構成されています。
o When uCDN sees a request best served by the dCDN, it returns CNAME and NS records for "b.cdn.csp.example", where "b" is the unique identifier assigned to Operator B. (It may, for example, be an AS number assigned to Operator B.)
o uCDNは、dCDNが最適に処理するリクエストを見つけると、「b.cdn.csp.example」のCNAMEレコードとNSレコードを返します。「b」は、オペレーターBに割り当てられた一意の識別子です（たとえば、オペレーターBに割り当てられたAS番号。）
o The dCDN is configured so that a request for "b.cdn.csp.example" returns a delivery node in the dCDN.
o dCDNは、「b.cdn.csp.example」に対するリクエストがdCDNの配信ノードを返すように構成されています。
o The uCDN is configured so that a request for "op-b-acq.op-a.example" returns a delivery node in the uCDN.
o uCDNは、「op-b-acq.op-a.example」のリクエストがuCDNの配信ノードを返すように構成されています。
Figure 5 depicts the exchange of DNS and HTTP requests. The main differences from Figure 3 are the lack of HTTP redirection and transparency to the end user.
図5は、DNS要求とHTTP要求の交換を示しています。図3との主な違いは、HTTPリダイレクションの欠如とエンドユーザーに対する透過性です。
End User Operator B Operator A
|DNS cdn.csp.example | |
|-------------------------------------------------->|
| | |(1)
|CNAME b.cdn.csp.example | |
|<--------------------------------------------------|
| | |
|DNS b.cdn.csp.example | |
|-------------------------------------------------->|
| | |(2)
|NS records for b.cdn.csp.example + |
|Glue AAAA/A records for b.cdn.csp.example |
|<--------------------------------------------------|
| | |
|DNS b.cdn.csp.example | |
|------------------------>| |
| |(3) |
|IPaddr of B's Delivery Node |
|<------------------------| |
|HTTP cdn.csp.example | |
|------------------------>| |
| |(4) |
| |DNS op-b-acq.op-a.example|
| |------------------------>|
| | |(5)
| |IPaddr of A's Delivery Node
| |<------------------------|
| |HTTP op-b-acq.op-a.example
| |------------------------>|
| | |(6)
| |Data |
| |<------------------------|
|Data | |
|<------------------------| |
Figure 5: Message Flow for DNS-Based Redirection
図5：DNSベースのリダイレクトのメッセージフロー
The steps illustrated in the figure are as follows:
図に示す手順は次のとおりです。
1. The Request Router for Operator A processes the DNS request for CDN-Domain cdn.csp.example and recognizes that the end user is best served by another CDN. (This may depend on the IP address of the user's LDNS resolver, or other information discussed below.) The Request Router returns a DNS CNAME response by "stacking" the distinguished identifier for Operator B onto the original CDN-Domain (e.g., b.cdn.csp.example).
1. オペレーターAのリクエストルーターは、CDNドメインcdn.csp.exampleのDNSリクエストを処理し、エンドユーザーに別のCDNが最適なサービスを提供していることを認識します。 （これは、ユーザーのLDNSリゾルバーのIPアドレス、または以下で説明するその他の情報に依存する場合があります。）リクエストルーターは、オペレーターBの識別識別子を元のCDNドメイン（例：b。 cdn.csp.example）。
2. The end user sends a DNS query for the modified CDN-Domain (i.e., b.cdn.csp.example) to Operator A's DNS server. The Request Router for Operator A processes the DNS request and returns a delegation to b.cdn.csp.example by sending an NS record plus glue records pointing to Operator B's DNS server. (This extra step is necessary since typical DNS implementation won't follow an NS record when it is sent together with a CNAME record, thereby necessitating a two-step approach.)
2. エンドユーザーは、変更されたCDNドメイン（つまり、b.cdn.csp.example）のDNSクエリをオペレーターAのDNSサーバーに送信します。オペレーターAのリクエストルーターはDNSリクエストを処理し、オペレーターBのDNSサーバーを指すNSレコードとグルーレコードを送信することにより、委任をb.cdn.csp.exampleに返します。 （CNAMEレコードと一緒に送信される場合、通常のDNS実装はNSレコードに追従しないため、この追加の手順が必要です。したがって、2段階のアプローチが必要になります。）
3. The end user sends a DNS query for the modified CDN-Domain (i.e., b.cdn.csp.example) to Operator B's DNS server, using the NS and AAAA/A records received in step 2. This causes B's Request Router to respond with a suitable delivery node.
3. エンドユーザーは、手順2で受信したNSおよびAAAA / Aレコードを使用して、変更されたCDNドメインのDNSクエリ（b.cdn.csp.example）をオペレーターBのDNSサーバーに送信します。これにより、Bのリクエストルーターが応答します。適切な配信ノードを使用します。
4. The end user requests the content from B's delivery node. The requested URL contains the name cdn.csp.example. (Note that the returned CNAME does not affect the URL.) At this point, the delivery node has the correct IP address of the end user and can do an HTTP 302 redirect if the redirections in steps 2 and 3 were incorrect. Otherwise, B verifies that this CDN-Domain belongs to a known peer (so as to avoid being tricked into serving as an open proxy). It then does a DNS request for an "internal" CDN-Domain as agreed above (op-b-acq.op-a.example).
4. エンドユーザーはBの配信ノードにコンテンツを要求します。要求されたURLにはcdn.csp.exampleという名前が含まれています。 （返されたCNAMEはURLに影響を与えないことに注意してください。）この時点で、配信ノードはエンドユーザーの正しいIPアドレスを持ち、手順2と3のリダイレクトが正しくない場合、HTTP 302リダイレクトを実行できます。それ以外の場合、BはこのCDN-Domainが既知のピアに属していることを確認します（だまされてオープンプロキシとして機能するのを回避するため）。次に、上記で合意した「内部」CDNドメインのDNS要求を実行します（op-b-acq.op-a.example）。
5. Operator A recognizes that the DNS request is from a peer CDN rather than an end user (due to the internal CDN-Domain) and so returns the address of a delivery node in uCDN.
5. オペレーターAは、DNSリクエストがエンドユーザーではなくピアCDNからのものであることを認識し（内部CDNドメインにより）、uCDNで配信ノードのアドレスを返します。
6. Operator A serves content to dCDN. Although not shown, it is at this point that Operator A processes the rest of the URL: it extracts information identifying the origin server, validates that this server has been registered, and determines the content provider that owns the origin server.
6. オペレーターAがコンテンツをdCDNに提供します。示されていないが、この時点でオペレーターAは残りのURLを処理します。つまり、オリジンサーバーを識別する情報を抽出し、このサーバーが登録されていることを検証し、オリジンサーバーを所有するコンテンツプロバイダーを決定します。
The advantages of this approach are that it is more transparent to the end user and requires fewer round trips than HTTP-based redirection (in its worst case, i.e., when none of the needed DNS information is cached). A potential problem is that the Upstream CDN depends on being able to learn the correct Downstream CDN that serves the end user from the client address in the DNS request. In standard DNS operation, the uCDN will only obtain the address of the client's LDNS resolver, which is not guaranteed to be in the same network (or geographic region) as the client. If not (e.g., the end user uses a global DNS service), then the Upstream CDN cannot determine the appropriate Downstream CDN to serve the end user. In this case, and assuming the uCDN is capable of detecting that situation, one option is for the Upstream CDN to treat the end user as it would any user not connected to a peer CDN. Another option is for the Upstream CDN to "fall back" to a pure HTTP-based redirection strategy in this case (i.e., use the first method). Note that this problem affects existing CDNs that rely on DNS to determine where to redirect client requests, but the consequences are arguably less serious for CDNI since the LDNS is likely in the same network as the dCDN serves.
このアプローチの利点は、エンドユーザーに対して透過的であり、HTTPベースのリダイレクトよりもラウンドトリップが少なくて済むことです（最悪の場合、つまり必要なDNS情報がキャッシュされていない場合）。潜在的な問題は、アップストリームCDNが、DNS要求のクライアントアドレスからエンドユーザーにサービスを提供する正しいダウンストリームCDNを学習できるかどうかに依存することです。標準のDNS操作では、uCDNはクライアントのLDNSリゾルバーのアドレスのみを取得します。これは、クライアントと同じネットワーク（または地理的領域）にあることが保証されていません。そうでない場合（たとえば、エンドユーザーがグローバルDNSサービスを使用する場合）、アップストリームCDNは、エンドユーザーにサービスを提供するための適切なダウンストリームCDNを決定できません。この場合、uCDNがその状況を検出できると想定すると、1つのオプションは、アップストリームCDNがエンドユーザーをピアCDNに接続していないユーザーと同様に扱うことです。別のオプションは、この場合、アップストリームCDNが純粋なHTTPベースのリダイレクト戦略に「フォールバック」することです（つまり、最初の方法を使用します）。この問題は、クライアント要求をリダイレクトする場所を決定するためにDNSに依存する既存のCDNに影響しますが、LDNSはdCDNと同じネットワークにある可能性が高いため、結果はCDNIにとってはそれほど深刻ではないことに注意してください。
As with the prior example, this example partially illustrates the various interfaces involved in CDNI. Operator A could learn dynamically from Operator B the set of prefixes or regions that B is willing and able to serve via the CDNI Footprint & Capabilities Advertisement interface. The distinguished name used for acquisition and the identifier for Operator B that is prepended to the CDN-Domain on redirection are examples of information elements that might also be conveyed by CDNI interfaces (or, alternatively, statically configured). As before, minimal metadata sufficient to obtain the content is carried "in-band" as part of the redirection process, and standard HTTP is used for inter-CDN acquisition. There is no explicit CDNI Logging interface discussed in this example.
前の例と同様に、この例はCDNIに関連するさまざまなインターフェースを部分的に示しています。オペレーターAは、BがCDNI Footprint＆Capabilities Advertisementインターフェースを介してサービスを提供できる意思のあるプレフィックスまたはリージョンのセットをオペレーターBから動的に学習できます。取得に使用される識別名と、リダイレクト時にCDNドメインの前に付加されるオペレーターBのIDは、CDNIインターフェースによって（または、静的に構成されて）伝達される情報要素の例です。以前と同様に、コンテンツを取得するのに十分な最小限のメタデータがリダイレクトプロセスの一部として「インバンド」で伝送され、標準のHTTPがCDN間取得に使用されます。この例では、明示的なCDNIログインターフェイスについて説明していません。
Although it is possible to use DNSSEC in combination with the Iterative DNS-based Redirection mechanism explained above, it is important to note that the uCDN might have to sign records on the fly, since the CNAME returned, and thus the signature provided, can potentially be different for each incoming query. Although there is nothing preventing a uCDN from performing such on-the-fly signing, this might be computationally expensive. In the case where the number of dCDNs, and thus the number of different CNAMEs to return, is relatively stable, an alternative solution would be for the uCDN to pre-generate signatures for all possible CNAMEs. For each incoming query, the uCDN would then determine the appropriate CNAME and return it together with the associated pre-generated signature. Note: In the latter case, maintaining the serial number and signature of Start of Authority (SOA) might be an issue since, technically, it should change every time a different CNAME is used. However, since, in practice, direct SOA queries are relatively rare, a uCDN could defer incrementing the serial number and resigning the SOA until it is queried and then do it on-the-fly.
上記で説明した反復DNSベースのリダイレクトメカニズムと組み合わせてDNSSECを使用することは可能ですが、CNAMEが返され、提供された署名が潜在的に署名される可能性があるため、uCDNがその場でレコードに署名する必要があることに注意することが重要です着信クエリごとに異なります。 uCDNがそのようなオンザフライ署名を実行するのを妨げるものは何もありませんが、これは計算コストがかかる可能性があります。 dCDNの数、つまり返される異なるCNAMEの数が比較的安定している場合、uCDNがすべての可能なCNAMEのシグネチャを事前に生成する別の解決策があります。着信クエリごとに、uCDNは適切なCNAMEを決定し、関連する事前生成された署名とともに返します。注：後者の場合、技術的には異なるCNAMEが使用されるたびに変更する必要があるため、Start of Authority（SOA）のシリアル番号と署名の維持が問題になる可能性があります。ただし、実際には直接のSOAクエリは比較的まれであるため、uCDNはシリアル番号のインクリメントを延期し、クエリが実行されるまでSOAを再署名して、オンザフライで実行することができます。
Note also that the NS record and the glue records used in step 2 in the previous section should generally be identical to those of their authoritative zone managed by Operator B. Even if they differ, this will not make the DNS resolution process fail, but the client DNS server will prefer the authoritative data in its cache and use it for subsequent queries. Such inconsistency is a general operational issue of DNS, but it may be more important for this architecture because the uCDN (Operator A) would rely on the consistency to make the resulting redirection work as intended. In general, it is the administrator's responsibility to make them consistent.
前のセクションのステップ2で使用されたNSレコードとグルーレコードは、通常、オペレーターBが管理する権威ゾーンのものと同一である必要があります。これらが異なる場合でも、DNS解決プロセスは失敗しませんが、クライアントDNSサーバーは、キャッシュ内の信頼できるデータを優先し、それを後続のクエリに使用します。このような不整合はDNSの一般的な運用上の問題ですが、uCDN（オペレーターA）は結果として生じるリダイレクトを意図したとおりに機能させるために整合性に依存するため、このアーキテクチャにとってより重要な場合があります。一般に、それらを整合させるのは管理者の責任です。
There could be situations where being able to dynamically discover the set of requests that a given dCDN is willing and able to serve is beneficial. For example, a CDN might at one time be able to serve a certain set of client IP prefixes, but that set might change over time due to changes in the topology and routing policies of the IP network. The following example illustrates this capability. We have chosen the example of DNS-based redirection, but HTTP-based redirection could equally well use this approach.
特定のdCDNが喜んで提供できる一連の要求を動的に検出できると有益な場合があります。たとえば、CDNは一度に特定のクライアントIPプレフィックスのセットを提供できる場合がありますが、そのセットはIPネットワークのトポロジとルーティングポリシーの変更により、時間の経過とともに変化する可能性があります。次の例は、この機能を示しています。 DNSベースのリダイレクトの例を選択しましたが、HTTPベースのリダイレクトでもこのアプローチを使用できます。
End User Operator B Operator A
|DNS cdn.csp.example | |
|-------------------------------------------------->|
| | |(1)
| | RI REQ op-b.example |
| |<------------------------|
| | |(2)
| | RI REPLY |
| |------------------------>|
| | |(3)
|CNAME b.cdn.csp.example | |
|NS records for b.cdn.csp.example |
|<--------------------------------------------------|
|DNS b.cdn.csp.example | |
|------------------------>| |
| |(2) |
|IPaddr of B's Delivery Node |
|<------------------------| |
|HTTP cdn.csp.example | |
|------------------------>| |
| |(3) |
| |DNS op-b-acq.op-a.example|
| |------------------------>|
| | |(4)
| |IPaddr of A's Delivery Node
| |<------------------------|
| |HTTP op-b-acq.op-a.example
| |------------------------>|
| | |(5)
| |Data |
| |<------------------------|
|Data | |
|<------------------------| |
Figure 6: Message Flow for Dynamic Footprint Discovery
図6：動的フットプリント検出のメッセージフロー
This example differs from the one in Figure 5 only in the addition of an RI request (step 2) and corresponding response (step 3). The RI REQ could be a message such as "Can you serve clients from this IP Prefix?" or it could be "Provide the list of client IP prefixes you can currently serve". In either case the response might be cached by Operator A to avoid repeatedly asking the same question. Alternatively, or in addition, Operator B may spontaneously advertise to Operator A information (or changes) on the set of requests it is willing and able to serve on behalf of Operator A; in that case, Operator B may spontaneously issue RR/RI REPLY messages that are not in direct response to a corresponding RR/RI REQ message. (Note that the issues of determining the client's subnet from DNS requests, as described above, are exactly the same here as in Section 3.4.)
この例は、RI要求（ステップ2）と対応する応答（ステップ3）の追加のみが図5の例と異なります。 RI REQは、「このIPプレフィックスからクライアントにサービスを提供できますか？」などのメッセージである可能性があります。または、「現在提供できるクライアントIPプレフィックスのリストを提供する」の場合もあります。どちらの場合も、同じ質問を繰り返し尋ねることを避けるために、応答はオペレーターAによってキャッシュされる可能性があります。あるいは、またはそれに加えて、オペレーターBは、オペレーターAに代わって提供する意思があり、提供できる一連の要求に関する情報（または変更）をオペレーターAに自発的にアドバタイズできます。その場合、オペレーターBは、対応するRR / RI REQメッセージに直接応答しないRR / RI REPLYメッセージを自発的に発行することがあります。 （上記のように、DNS要求からクライアントのサブネットを決定する問題は、ここでセクション3.4とまったく同じであることに注意してください。）
Once Operator A obtains the RI response, it is now able to determine that Operator B's CDN is an appropriate dCDN for this request and therefore a valid candidate dCDN to consider in its redirection decision. If that dCDN is selected, the redirection and serving of the request proceeds as before (i.e., in the absence of dynamic footprint discovery).
オペレーターAがRI応答を取得すると、オペレーターBのCDNがこの要求に適切なdCDNであり、リダイレクトの決定で検討する有効な候補dCDNであると判断できるようになりました。そのdCDNが選択されている場合、リクエストのリダイレクトと処理は以前と同様に（つまり、動的なフットプリントの検出がない場合）続行されます。
The following example illustrates how the CDNI Control interface may be used to achieve pre-positioning of an item of content in the dCDN. In this example, user requests for a particular content, and corresponding redirection of such requests from Operator A to Operator B CDN, may (or may not) have taken place earlier. Then, at some point in time, the uCDN (for example, in response to a corresponding Trigger from the Content Provider) uses the CI to request that content identified by a particular URL be removed from dCDN. The following diagram illustrates the operation. It should be noted that a uCDN will typically not know whether a dCDN has cached a given content item; however, it may send the content removal request to make sure no cached versions remain to satisfy any contractual obligations it may have.
次の例は、CDNI制御インターフェースを使用して、dCDN内のコンテンツの項目の事前配信を実現する方法を示しています。この例では、特定のコンテンツに対するユーザーの要求、およびオペレーターAからオペレーターBのCDNへのそのような要求の対応するリダイレクトが、以前に行われた（または行われない）場合があります。次に、ある時点で、uCDNは（たとえば、コンテンツプロバイダーからの対応するトリガーに応じて）CIを使用して、特定のURLで識別されるコンテンツをdCDNから削除するように要求します。次の図は、操作を示しています。 uCDNは通常、dCDNが特定のコンテンツアイテムをキャッシュしたかどうかを知らないことに注意してください。ただし、コンテンツの削除要求を送信して、契約上の義務を満たすためにキャッシュされたバージョンが残っていないことを確認できます。
End User Operator B Operator A
| |CI purge cdn.csp.example/...
| |<------------------------|
| | |
| |CI OK |
| |------------------------>|
| | |
Figure 7: Message Flow for Content Removal
図7：コンテンツ削除のメッセージフロー
The CI is used to convey the request from the uCDN to the dCDN that some previously acquired content should be deleted. The URL in the request specifies which content to remove. This example corresponds to a DNS-based redirection scenario such as Section 3.4. If HTTP-based redirection had been used, the URL for removal would be of the form peer-a.op-b.example/cdn.csp.example/...
CIは、以前に取得したコンテンツを削除する必要があるという要求をuCDNからdCDNに伝えるために使用されます。リクエストのURLは、削除するコンテンツを指定します。この例は、セクション3.4などのDNSベースのリダイレクトシナリオに対応しています。 HTTPベースのリダイレクトが使用されていた場合、削除するためのURLは、peer-a.op-b.example / cdn.csp.example / ...の形式になります。
The dCDN is expected to confirm to the uCDN, as illustrated by the CI OK message, the completion of the removal of the targeted content from all the caches in the dCDN.
CI CD OKメッセージによって示されるように、dCDNはuCDNに確認することが期待されています。これは、dCDN内のすべてのキャッシュからのターゲットコンテンツの削除の完了です。
The following example illustrates how the CI may be used to pre-position an item of content in the dCDN. In this example, Operator A uses the CDNI Metadata interface to request that content identified by a particular URL be pre-positioned into Operator B CDN.
次の例は、CIを使用してdCDN内のコンテンツのアイテムを事前配信する方法を示しています。この例では、オペレーターAはCDNIメタデータインターフェースを使用して、特定のURLで識別されるコンテンツをオペレーターB CDNに事前配信するように要求します。
End User Operator B Operator A
エンドユーザーオペレーターBオペレーターA
| |CI pre-position cdn.csp.example/...
| |<------------------------|
| | |(1)
| |CI OK |
| |------------------------>|
| | |
| |DNS op-b-acq.op-a.example|
| |------------------------>|
| | |(2)
| |IPaddr of A's Delivery Node
| |<------------------------|
| |HTTP op-b-acq.op-a.example
| |------------------------>|
| | |(3)
| |Data |
| |<------------------------|
|DNS cdn.csp.example | |
|--------------------------------------------->|
| | |(4)
|IPaddr of A's Request Router |
|<---------------------------------------------|
|HTTP cdn.csp.example| |
|--------------------------------------------->|
| | |(5)
|302 peer-a.op-b.example/cdn.csp.example |
|<---------------------------------------------|
|DNS peer-a.op-b.example |
|------------------->| |
| |(6) |
|IPaddr of B's Delivery Node |
|<-------------------| |
|HTTP peer-a.op-b.example/cdn.csp.example |
|------------------->| |
| |(7) |
|Data | |
|<-------------------| |
Figure 8: Message Flow for Content Pre-Positioning
図8：コンテンツの事前配信のメッセージフロー
The steps illustrated in the figure are as follows:
図に示す手順は次のとおりです。
1. Operator A uses the CI to request that Operator B pre-position a particular content item identified by its URL. Operator B responds by confirming that it is willing to perform this operation.
1. オペレーターAはCIを使用して、オペレーターBがそのURLで識別される特定のコンテンツアイテムを事前配信することを要求します。オペレーターBは、この操作を実行する意思があることを確認して応答します。
Steps 2 and 3 are exactly the same as steps 5 and 6 of Figure 3, only this time those steps happen as the result of the Pre-positioning request instead of as the result of a cache miss.
ステップ2と3は、図3のステップ5と6とまったく同じですが、今回は、キャッシュミスの結果としてではなく、事前配置要求の結果としてこれらのステップが発生します。
Steps 4, 5, 6, and 7 are exactly the same as steps 1, 2, 3, and 4 of Figure 3, only this time, Operator B's CDN can serve the end-user request without triggering dynamic content acquisition, since the content has been pre-positioned in the dCDN. Note that, depending on dCDN operations and policies, the content pre-positioned in the dCDN may be pre-positioned to all, or a subset of, dCDN caches. In the latter case, intra-CDN dynamic content acquisition may take place inside the dCDN serving requests from caches on which the content has not been pre-positioned; however, such intra-CDN dynamic acquisition would not involve the uCDN.
ステップ4、5、6、および7は、図3のステップ1、2、3、および4とまったく同じですが、今回は、オペレーターBのCDNが動的コンテンツ取得をトリガーせずにエンドユーザーのリクエストに対応できます。 dCDNで事前配信されています。 dCDNの操作とポリシーに応じて、dCDNに事前配信されるコンテンツは、dCDNキャッシュのすべてまたはサブセットに事前配信される場合があることに注意してください。後者の場合、CDN内の動的コンテンツの取得は、コンテンツが事前配信されていないキャッシュからの要求を処理するdCDN内で行われる可能性があります。ただし、このようなCDN内動的取得にはuCDNは含まれません。
In this section, we walk through a simple example illustrating a scenario of asynchronously exchanging CDNI Metadata, where the Downstream CDN obtains CDNI Metadata for content ahead of a corresponding content request. The example that follows assumes that HTTP-based inter-CDN redirection and recursive CDNI request routing are used, as in Section 3.3. However, Asynchronous exchange of CDNI Metadata is similarly applicable to DNS-based inter-CDN redirection and iterative request routing (in which cases the CDNI Metadata may be used at slightly different processing stages of the message flows).
このセクションでは、ダウンストリームCDNが対応するコンテンツ要求の前にコンテンツのCDNIメタデータを取得する、非同期のCDNIメタデータ交換のシナリオを示す簡単な例について説明します。次の例では、セクション3.3のように、HTTPベースのCDN間のリダイレクトと再帰的なCDNI要求ルーティングが使用されることを前提としています。ただし、CDNIメタデータの非同期交換は、DNSベースのCDN間リダイレクトおよび反復要求ルーティングにも同様に適用できます（この場合、CDNIメタデータは、メッセージフローのわずかに異なる処理段階で使用できます）。
End User Operator B Operator A
| | |
| |CI pre-position (Trigger)|
| |<------------------------|(1)
| | |
| |CI OK |
| |------------------------>|(2)
| | |
| |MI pull REQ |
| |------------------------>|(3)
| | |
| |MI metadata REP |(4)
| | |
| | |
| CONTENT REQUEST | |
|-------------------------------------------------->|(5)
| | |
| | RI REQ |
| |<------------------------|(6)
| | |
| | RI RESP |
| |------------------------>|(7)
| | |
| CONTENT REDIRECTION | |
|<--------------------------------------------------|(8)
| | |
| CONTENT REQUEST | |
|------------------------>|(9) |
| | |
: : :
| CONTENT DATA | |
|<------------------------| |(10)
Figure 9: Message Flow for Asynchronous CDNI Metadata
図9：非同期CDNIメタデータのメッセージフロー
The steps illustrated in the figure are as follows:
図に示す手順は次のとおりです。
1. Operator A uses the CI to trigger the signaling of the availability of CDNI Metadata to Operator B.
1. オペレーターAはCIを使用して、CDNIメタデータの可用性のオペレーターBへのシグナリングをトリガーします。
2. Operator B acknowledges the receipt of this Trigger.
2. オペレーターBは、このトリガーの受信を確認します。
3. Operator B requests the latest metadata from Operator A using the MI.
3. オペレーターBは、MIを使用してオペレーターAに最新のメタデータを要求します。
4. Operator A replies with the requested metadata. This document does not constrain how the CDNI Metadata information is actually represented. For the purposes of this example, we assume that Operator A provides CDNI Metadata to Operator B indicating that:
4. オペレーターAは、要求されたメタデータで応答します。このドキュメントは、CDNIメタデータ情報が実際にどのように表されるかを制約しません。この例では、オペレーターAがCDNIメタデータをオペレーターBに提供して、次のことを示していると想定しています。
* this CDNI Metadata is applicable to any content referenced by some CDN-Domain.
* このCDNIメタデータは、一部のCDNドメインによって参照されるすべてのコンテンツに適用できます。
* this CDNI Metadata consists of a distribution policy requiring enforcement by the delivery node of a specific per-request authorization mechanism (e.g., URI signature or token validation).
* このCDNIメタデータは、特定のリクエストごとの承認メカニズム（URI署名やトークン検証など）の配信ノードによる適用を必要とする配布ポリシーで構成されています。
5. A Content Request occurs as usual.
5. コンテンツリクエストは通常どおり発生します。
6. A CDNI Request Routing Redirection request (RI REQ) is issued by Operator A's CDN, as discussed in Section 3.3. Operator B's Request Router can access the CDNI Metadata that are relevant to the requested content and that have been pre-positioned as per Steps 1-4, which may or may not affect the response.
6. セクション3.3で説明するように、CDNI要求ルーティングリダイレクト要求（RI REQ）は、オペレーターAのCDNによって発行されます。オペレーターBの要求ルーターは、要求されたコンテンツに関連し、手順1〜4に従って事前配信されたCDNIメタデータにアクセスできます。これは、応答に影響する場合と影響しない場合があります。
7. Operator B's Request Router issues a CDNI Request Routing Redirection response (RI RESP) as in Section 3.3.
7. オペレーターBのリクエストルーターは、セクション3.3のようにCDNIリクエストルーティングリダイレクトレスポンス（RI RESP）を発行します。
8. Operator B performs content redirection as discussed in Section 3.3.
8. オペレーターBは、セクション3.3で説明するようにコンテンツのリダイレクトを実行します。
9. On receipt of the Content Request by the end user, the delivery node detects that previously acquired CDNI Metadata is applicable to the requested content. In accordance with the specific CDNI metadata of this example, the delivery node will invoke the appropriate per-request authorization mechanism, before serving the content. (Details of this authorization are not shown.)
9. エンドユーザーがコンテンツ要求を受信すると、配信ノードは、以前に取得したCDNIメタデータが要求されたコンテンツに適用可能であることを検出します。この例の特定のCDNIメタデータに従って、配信ノードはコンテンツを提供する前に、リクエストごとの適切な認証メカニズムを呼び出します。 （この許可の詳細は表示されません。）
10. Assuming successful per-request authorization, serving of Content Data (possibly preceded by inter-CDN acquisition) proceeds as in Section 3.3.
10. リクエストごとの認証が成功したと仮定すると、コンテンツデータの提供（CDN間の取得の前に行われる可能性があります）はセクション3.3のように進行します。
In this section we walk through a simple example illustrating a scenario of Synchronous CDNI Metadata acquisition, in which the Downstream CDN obtains CDNI Metadata for content at the time of handling a first request for the corresponding content. As in the preceding section, this example assumes that HTTP-based inter-CDN redirection and recursive CDNI request routing are used (as in Section 3.3), but dynamic CDNI Metadata acquisition is applicable to other variations of request routing.
このセクションでは、対応するコンテンツの最初のリクエストを処理するときに、ダウンストリームCDNがコンテンツのCDNIメタデータを取得する、同期CDNIメタデータ取得のシナリオを示す簡単な例について説明します。前のセクションと同様に、この例では、HTTPベースのCDN間のリダイレクトと再帰的なCDNI要求ルーティングが使用されていることを前提としています（セクション3.3と同様）。動的なCDNIメタデータの取得は、要求ルーティングの他のバリエーションにも適用できます。
End User Operator B Operator A
| | |
| CONTENT REQUEST | |
|-------------------------------------------------->|(1)
| | |
| | RI REQ |
| (2)|<------------------------|
| | |
| | MI REQ |
| (3)|------------------------>|
| | MI RESP |
| |<------------------------|(4)
| | |
| | RI RESP |
| |------------------------>|(5)
| | |
| | |
| CONTENT REDIRECTION | |
|<--------------------------------------------------|(6)
| | |
| CONTENT REQUEST | |
|------------------------>|(7) |
| | |
| | MI REQ |
| (8)|------------------------>|
| | MI RESP |
| |<------------------------|(9)
| | |
: : :
| CONTENT DATA | |
|<------------------------| |(10)
Figure 10: Message Flow for Synchronous CDNI Metadata Acquisition
図10：同期CDNIメタデータ取得のメッセージフロー
The steps illustrated in the figure are as follows:
図に示す手順は次のとおりです。
1. A Content Request arrives as normal.
1. コンテンツ要求は通常どおり到着します。
2. An RI request occurs as in the prior example.
2. 前の例のようにRI要求が発生します。
3. On receipt of the CDNI Request Routing Request, Operator B's CDN initiates Synchronous acquisition of CDNI Metadata that are needed for routing of the end-user request. We assume the URI for the a metadata server is known ahead of time through some out-of-band means.
3. CDNI要求ルーティング要求を受信すると、オペレーターBのCDNは、エンドユーザー要求のルーティングに必要なCDNIメタデータの同期取得を開始します。メタデータサーバーのURIは、帯域外の手段によって事前に認識されていると想定しています。
4. On receipt of a CDNI Metadata request, Operator A's CDN responds, making the corresponding CDNI Metadata information available to Operator B's CDN. This metadata is considered by Operator B's CDN before responding to the Request Routing request. (In a simple case, the metadata could simply be an allow or deny response for this particular request.)
4. CDNIメタデータ要求を受信すると、オペレーターAのCDNが応答し、対応するCDNIメタデータ情報をオペレーターBのCDNが使用できるようにします。このメタデータは、リクエストルーティングリクエストに応答する前に、オペレーターBのCDNによって考慮されます。 （単純なケースでは、メタデータは単にこの特定の要求に対する許可または拒否の応答である可能性があります。）
5. Response to the RI request as normal.
5. 通常どおりのRI要求への応答。
6. Redirection message is sent to the end user.
6. リダイレクトメッセージがエンドユーザーに送信されます。
7. A delivery node of Operator B receives the end user request.
7. オペレーターBの配信ノードがエンドユーザーのリクエストを受信します。
8. The delivery node Triggers dynamic acquisition of additional CDNI Metadata that are needed to process the end-user content request. Note that there may exist cases where this step need not happen, for example, because the metadata were already acquired previously.
8. 配信ノードは、エンドユーザーのコンテンツ要求を処理するために必要な追加のCDNIメタデータの動的取得をトリガーします。たとえば、メタデータがすでに取得されているため、この手順を実行する必要がない場合もあります。
9. Operator A's CDN responds to the CDNI Metadata Request and makes the corresponding CDNI Metadata available to Operator B. This metadata influence how Operator B's CDN processes the end-user request.
9. オペレーターAのCDNはCDNIメタデータ要求に応答し、対応するCDNIメタデータをオペレーターBが利用できるようにします。このメタデータは、オペレーターBのCDNがエンドユーザー要求を処理する方法に影響を与えます。
10. Content is served (possibly preceded by inter-CDN acquisition) as in Section 3.3.
10. セクション3.3のように、コンテンツが提供されます（おそらくCDN間の取得が先行します）。
A single dCDN may receive end-user requests from multiple uCDNs. When a dCDN receives an end-user request, it must determine the identity of the uCDN from which it should acquire the requested content.
1つのdCDNが複数のuCDNからエンドユーザーのリクエストを受信する場合があります。 dCDNはエンドユーザーの要求を受信すると、要求されたコンテンツを取得する必要があるuCDNのIDを決定する必要があります。
Ideally, the acquisition path of an end-user request will follow the redirection path of the request. The dCDN should acquire the content from the same uCDN that redirected the request.
理想的には、エンドユーザーリクエストの取得パスは、リクエストのリダイレクトパスに従います。 dCDNは、要求をリダイレクトした同じuCDNからコンテンツを取得する必要があります。
Determining the acquisition path requires the dCDN to reconstruct the redirection path based on information in the end-user request. The method for reconstructing the redirection path differs based on the redirection approach: HTTP or DNS.
取得パスを決定するには、dCDNがエンドユーザー要求の情報に基づいてリダイレクトパスを再構築する必要があります。リダイレクションパスを再構築する方法は、リダイレクションアプローチ（HTTPまたはDNS）によって異なります。
With HTTP-redirection, the rewritten URI should include sufficient information for the dCDN to directly or indirectly determine the uCDN when the end-user request is received. The HTTP-redirection approach can be further broken-down based on the how the URL is rewritten during redirection: HTTP redirection with or without Site Aggregation. HTTP redirection with Site Aggregation hides the identity of the original CSP. HTTP redirection without Site Aggregation does not attempt to hide the identity of the original CSP. With both approaches, the rewritten URI includes enough information to identify the immediate neighbor uCDN.
HTTPリダイレクションの場合、書き換えられたURIには、エンドユーザーのリクエストを受信したときに、dCDNが直接または間接にuCDNを決定するための十分な情報が含まれている必要があります。 HTTPリダイレクションアプローチは、リダイレクション中にURLがどのようにリライトされるかに基づいて、さらに細分化できます。サイトアグリゲーションの有無にかかわらず、HTTPリダイレクションです。サイト集約を使用したHTTPリダイレクションでは、元のCSPのIDが隠されます。サイト集約なしのHTTPリダイレクトは、元のCSPのIDを隠そうとしません。どちらのアプローチでも、書き換えられたURIには、隣接するuCDNを識別するのに十分な情報が含まれています。
With DNS-redirection, the dCDN receives the published URI (instead of a rewritten URI) and does not have sufficient information for the dCDN to identify the appropriate uCDN. The dCDN may narrow the set of viable uCDNs by examining the CDNI Metadata from each to determine which uCDNs are hosting metadata for the requested content. If there is a single uCDN hosting metadata for the requested content, the dCDN can assume that the request redirection is coming from this uCDN and can acquire content from that uCDN. If there are multiple uCDNs hosting metadata for the requested content, the dCDN may be ready to trust any of these uCDNs to acquire the content (provided the uCDN is in a position to serve it). If the dCDN is not ready to trust any of these uCDNs, it needs to ensure via out of band arrangements that, for a given content, only a single uCDN will ever redirect requests to the dCDN.
DNSリダイレクションでは、dCDNは（書き換えられたURIではなく）公開されたURIを受信し、dCDNが適切なuCDNを識別するための十分な情報を持っていません。 dCDNは、それぞれからCDNIメタデータを調べて、要求されたコンテンツのメタデータをホストしているuCDNを判別することにより、実行可能なuCDNのセットを狭める場合があります。要求されたコンテンツの単一のuCDNホスティングメタデータがある場合、dCDNは、要求のリダイレクトがこのuCDNからのものであると想定し、そのuCDNからコンテンツを取得できます。要求されたコンテンツのメタデータをホストするuCDNが複数ある場合、dCDNはこれらのuCDNのいずれかを信頼してコンテンツを取得する準備ができている可能性があります（uCDNがコンテンツを提供できる場合）。 dCDNがこれらのuCDNのいずれかを信頼する準備ができていない場合、特定のコンテンツについて、単一のuCDNのみが要求をdCDNにリダイレクトすることを帯域外の調整を介して確認する必要があります。
Content acquisition may be preceded by content metadata acquisition. If possible, the acquisition path for metadata should also follow the redirection path. Additionally, we assume metadata is indexed based on rewritten URIs in the case of HTTP redirection and is indexed based on published URIs in the case of DNS-redirection. Thus, the RI and the MI are tightly coupled in that the result of request routing (a rewritten URI pointing to the dCDN) serves as an input to metadata lookup. If the content metadata includes information for acquiring the content, then the MI is also tightly coupled with the acquisition interface in that the result of the metadata lookup (an acquisition URL likely hosted by the uCDN) should serve as input to the content acquisition.
コンテンツの取得の前に、コンテンツのメタデータを取得できます。可能であれば、メタデータの取得パスもリダイレクトパスに従う必要があります。さらに、HTTPリダイレクトの場合、メタデータは書き換えられたURIに基づいてインデックス付けされ、DNSリダイレクトの場合、公開されたURIに基づいてインデックス付けされると想定します。したがって、リクエストルーティングの結果（dCDNを指す書き換えられたURI）がメタデータルックアップへの入力として機能するという点で、RIとMIは密接に結びついています。コンテンツメタデータにコンテンツを取得するための情報が含まれている場合、MIも取得インターフェイスと緊密に結合され、メタデータルックアップの結果（uCDNによってホストされる可能性のある取得URL）がコンテンツ取得への入力として機能します。
Figure 1 illustrates the main interfaces that are in scope for the CDNI WG, along with several others. The detailed specifications of these interfaces are left to other documents, but see [RFC6707] and [RFC7337] for some discussion of the interfaces.
図1は、CDNI WGの対象となる主なインターフェイスとその他のインターフェイスを示しています。これらのインターフェースの詳細な仕様は他のドキュメントに任されていますが、インターフェースのいくつかの議論については[RFC6707]と[RFC7337]を見てください。
One interface that is not shown in Figure 1 is the interface between the user and the CSP. While for the purposes of CDNI that interface is out of scope, it is worth noting that it does exist and can provide useful functions, such as end-to-end performance monitoring and some forms of authentication and authorization.
図1に示されていない1つのインターフェイスは、ユーザーとCSP間のインターフェイスです。 CDNIの目的では、このインターフェースは範囲外ですが、このインターフェースが存在し、エンドツーエンドのパフォーマンスモニタリングや認証や承認などの便利な機能を提供できることは注目に値します。
There is also an important interface between the user and the Request Routing function of both uCDN and dCDN (shown as the "Request" interface in Figure 1). As we saw in some of the preceding examples, that interface can be used as a way of passing metadata, such as the minimum information that is required for dCDN to obtain the content from the uCDN.
ユーザーとuCDNとdCDNの両方のリクエストルーティング機能の間に重要なインターフェイスもあります（図1で「リクエスト」インターフェイスとして示されています）。前のいくつかの例で見たように、dCDNがuCDNからコンテンツを取得するために必要な最小限の情報など、メタデータを渡す方法としてそのインターフェースを使用できます。
In this section we will provide an overview of the functions performed by each of the CDNI interfaces and discuss how they fit into the overall solution. We also examine some of the design trade-offs, and explore several cross-interface concerns. We begin with an examination of one such trade-off that affects all the interfaces -- the use of in-band or out-of-band communication.
このセクションでは、各CDNIインターフェースによって実行される機能の概要を示し、それらがソリューション全体にどのように適合するかを説明します。また、設計のトレードオフのいくつかを調べ、いくつかのクロスインターフェースの問題を調査します。まず、すべてのインターフェイスに影響を与えるそのようなトレードオフの1つであるインバンド通信またはアウトオブバンド通信の使用について検討します。
Before getting to the individual interfaces, we observe that there is a high-level design choice for each, involving the use of existing in-band communication channels versus defining new out-of-band interfaces.
個々のインターフェイスに進む前に、既存の帯域内通信チャネルの使用と新しい帯域外インターフェイスの定義を含む、それぞれに高レベルの設計選択があることを確認します。
It is possible that the information needed to carry out various interconnection functions can be communicated between peer CDNs using existing in-band protocols. The use of HTTP 302 redirect is an example of how certain aspects of request routing can be implemented in-band (embedded in URIs). Note that using existing in-band protocols does not imply that the CDNI interfaces are null; it is still necessary to establish the rules (conventions) by which such protocols are used to implement the various interface functions.
さまざまな相互接続機能を実行するために必要な情報は、既存の帯域内プロトコルを使用してピアCDN間で通信できる可能性があります。 HTTP 302リダイレクトの使用は、リクエストルーティングの特定の側面をインバンド（URIに埋め込む）で実装する方法の例です。既存のインバンドプロトコルを使用しても、CDNIインターフェイスがnullであることを意味するわけではありません。このようなプロトコルを使用してさまざまなインターフェース機能を実装するための規則（規約）を確立する必要があります。
There are other opportunities for in-band communication beyond HTTP redirects. For example, many of the HTTP directives used by proxy servers can also be used by peer CDNs to inform each other of caching activity. Of these, one that is particularly relevant is the If-Modified-Since directive, which is used with the GET method to make it conditional: if the requested object has not been modified since the time specified in this field, a copy of the object will not be returned, and instead, a 304 (not modified) response will be returned.
HTTPリダイレクト以外にも、インバンド通信の機会があります。たとえば、プロキシサーバーで使用されるHTTPディレクティブの多くは、ピアCDNでも使用して、キャッシュアクティビティを互いに通知できます。これらのうち、特に関連があるのは、条件付きにするためにGETメソッドで使用されるIf-Modified-Sinceディレクティブです。要求されたオブジェクトがこのフィールドで指定された時間以降に変更されていない場合、オブジェクトのコピーは返されず、代わりに304（変更されていない）応答が返されます。
Although the CDNI interfaces are largely independent, there are a set of conventions practiced consistently across all interfaces. Most important among these is how resources are named, for example, how the CDNI Metadata and Control interfaces identify the set of resources to which a given directive applies or the CDNI Logging interface identifies the set of resources for which a summary record applies.
CDNIインターフェイスはほぼ独立していますが、すべてのインターフェイスで一貫して実践されている一連の規則があります。これらの中で最も重要なのは、リソースの命名方法です。たとえば、CDNIメタデータおよび制御インターフェースが、特定のディレクティブが適用されるリソースのセットを識別する方法や、CDNIロギングインターフェースが要約レコードが適用されるリソースのセットを識別する方法です。
While, theoretically, the CDNI interfaces could explicitly identify every individual resource, in practice, they name resource aggregates (sets of URIs) that are to be treated in a similar way. For example, URI aggregates can be identified by a CDN-Domain (i.e., the FQDN at the beginning of a URI) or by a URI-Filter (i.e., a regular expression that matches a subset of URIs contained in some CDN-Domain). In other words, CDN-Domains and URI-Filters provide a uniform means to aggregate sets (and subsets) of URIs for the purpose of defining the scope for some operation in one of the CDNI interfaces.
理論的には、CDNIインターフェイスは個々のリソースを明示的に識別できますが、実際には、同様の方法で処理されるリソースの集合体（URIのセット）を指定します。たとえば、URI集約は、CDN-ドメイン（つまり、URIの先頭のFQDN）またはURI-Filter（つまり、一部のCDN-ドメインに含まれるURIのサブセットと一致する正規表現）によって識別できます。 。つまり、CDNドメインとURIフィルターは、CDNIインターフェイスの1つで操作のスコープを定義する目的で、URIのセット（およびサブセット）を集約する統一された手段を提供します。
The Request Routing interface comprises two parts: the Asynchronous interface used by a dCDN to advertise footprint and capabilities (denoted FCI) to a uCDN, allowing the uCDN to decide whether to redirect particular user requests to that dCDN; and the Synchronous interface used by the uCDN to redirect a user request to the dCDN (denoted RI). (These are somewhat analogous to the operations of routing and forwarding in IP.)
リクエストルーティングインターフェイスは2つの部分で構成されています。dCDNがフットプリントと機能（FCIと表記）をuCDNにアドバタイズするために使用する非同期インターフェイス。uCDNが特定のユーザーリクエストをそのdCDNにリダイレクトするかどうかを決定できるようにします。 uCDNがユーザー要求をdCDN（RIと表記）にリダイレクトするために使用する同期インターフェース。 （これらは、IPでのルーティングおよび転送の操作にいくらか類似しています。）
As illustrated in Section 3, the RI part of request routing may be implemented in part by DNS and HTTP. Naming conventions may be established by which CDN peers communicate whether a request should be routed or content served.
セクション3に示すように、リクエストルーティングのRI部分は、DNSとHTTPによって部分的に実装できます。 CDNピアが要求をルーティングする必要があるか、コンテンツを提供する必要があるかを伝達する命名規則を確立できます。
We also note that RI plays a key role in enabling recursive redirection, as illustrated in Section 3.3. It enables the user to be redirected to the correct delivery node in dCDN with only a single redirection step (as seen by the user). This may be particularly valuable as the chain of interconnected CDNs increases beyond two CDNs. For further discussion on the RI, see [REDIRECTION].
セクション3.3に示すように、RIは再帰的なリダイレクトを可能にする上で重要な役割を果たすことにも注意してください。これにより、ユーザーは1回のリダイレクト手順（ユーザーから見た場合）でdCDNの正しい配信ノードにリダイレクトできます。相互接続されたCDNのチェーンが2つのCDNを超えて増加するため、これは特に価値があります。 RIの詳細については、[リダイレクト]を参照してください。
In support of these redirection requests, it is necessary for CDN peers to exchange additional information with each other, and this is the role of the FCI part of request routing. Depending on the method(s) supported, this might include: o The operator's unique id (operator-id) or distinguished CDN-Domain (operator-domain);
これらのリダイレクト要求をサポートするには、CDNピアが相互に追加情報を交換する必要があり、これが要求ルーティングのFCI部分の役割です。サポートされているメソッドに応じて、これには次のものが含まれます。oオペレーターの一意のID（operator-id）または識別されたCDN-Domain（operator-domain）。
o NS records for the operator's set of externally visible Request Routers;
o オペレーターの外部から見える要求ルーターのセットのNSレコード。
o The set of requests the dCDN operator is prepared to serve (e.g., a set of client IP prefixes or geographic regions that may be served by the dCDN).
o dCDNオペレーターが提供する準備ができている要求のセット（たとえば、dCDNが提供するクライアントIPプレフィックスまたは地理的領域のセット）。
o Additional capabilities of the dCDN, such as its ability to support different CDNI Metadata requests.
o さまざまなCDNIメタデータ要求をサポートする機能など、dCDNの追加機能。
Note that the set of requests that a dCDN is willing to serve could in some cases be relatively static (e.g., a set of IP prefixes), could be exchanged off-line, or might even be negotiated as part of a peering agreement. However, it may also be more dynamic, in which case the exchange supported by FCI would be helpful. A further discussion of the Footprint & Capability Advertisement interface can be found in [FOOTPRINT-CAPABILITY].
dCDNが提供しようとする一連の要求は、場合によっては比較的静的である可能性があります（たとえば、一連のIPプレフィックス）、オフラインで交換される可能性がある、またはピアリング契約の一部として交渉される可能性さえあることに注意してください。ただし、より動的な場合もあります。その場合、FCIがサポートする交換が役立ちます。 Footprint＆Capability Advertisementインターフェースの詳細については、[FOOTPRINT-CAPABILITY]をご覧ください。
It is necessary for the Upstream CDN to have visibility into the delivery of content that it redirected to a Downstream CDN. This allows the Upstream CDN to properly bill its customers for multiple deliveries of content cached by the Downstream CDN, as well as to report accurate traffic statistics to those content providers. This is one role of the LI.
アップストリームCDNは、ダウンストリームCDNにリダイレクトしたコンテンツの配信を可視化する必要があります。これにより、アップストリームCDNは、ダウンストリームCDNによってキャッシュされたコンテンツの複数の配信に対して顧客に適切に課金し、それらのコンテンツプロバイダーに正確なトラフィック統計を報告できます。これはLIの役割の1つです。
Other operational data that may be relevant to CDNI can also be exchanged by the LI. For example, a dCDN may report the amount of content it has acquired from uCDN, and how much cache storage has been consumed by content cached on behalf of uCDN.
CDNIに関連する可能性のある他の運用データも、LIによって交換できます。たとえば、dCDNは、uCDNから取得したコンテンツの量、およびuCDNのためにキャッシュされたコンテンツによって消費されたキャッシュストレージの量を報告します。
Traffic logs are easily exchanged off-line. For example, the following traffic log is a small deviation from the Apache log file format, where entries include the following fields:
トラフィックログはオフラインで簡単に交換できます。たとえば、次のトラフィックログは、Apacheログファイル形式からの小さな逸脱であり、エントリには次のフィールドが含まれます。
o Domain - the full domain name of the origin server
o ドメイン-オリジンサーバーの完全なドメイン名
o IP address - the IP address of the client making the request
o IPアドレス-要求を行っているクライアントのIPアドレス
o End time - the ending time of the transfer
o 終了時間-転送の終了時間
o Time zone - any time zone modifier for the end time
o タイムゾーン-終了時間の任意のタイムゾーン修飾子
o Method - the transfer command itself (e.g., GET, POST, HEAD) o URL - the requested URL
oメソッド-転送コマンド自体（GET、POST、HEADなど）o URL-要求されたURL
o Version - the protocol version, such as HTTP/1.0
o バージョン-HTTP / 1.0などのプロトコルバージョン
o Response - a numeric response code indicating transfer result
o 応答-転送結果を示す数値応答コード
o Bytes Sent - the number of bytes in the body sent to the client
o 送信バイト-クライアントに送信された本文のバイト数
o Request ID - a unique identifier for this transfer
o リクエストID-この転送の一意の識別子
o User agent - the user agent, if supplied
o ユーザーエージェント-ユーザーエージェント（提供されている場合）
o Duration - the duration of the transfer in milliseconds
o 継続時間-ミリ秒単位の転送の継続時間
o Cached Bytes - the number of body bytes served from the cache
o キャッシュされたバイト-キャッシュから提供された本文のバイト数
o Referrer - the referrer string from the client, if supplied
o リファラー-クライアントからのリファラー文字列（提供されている場合）
Of these, only the Domain field is indirect in the Downstream CDN -- it is set to the CDN-Domain used by the Upstream CDN rather than the actual origin server. This field could then used to filter traffic log entries so only those entries matching the Upstream CDN are reported to the corresponding operator. Further discussion of the LI can be found in [LOGGING].
これらのうち、ドメインフィールドのみがダウンストリームCDNで間接的です-実際のオリジンサーバーではなく、アップストリームCDNで使用されるCDN-ドメインに設定されます。このフィールドを使用してトラフィックログエントリをフィルタリングし、アップストリームCDNに一致するエントリのみを対応するオペレーターに報告できます。 LIの詳細については、[LOGGING]をご覧ください。
One open question is who does the filtering. One option is that the Downstream CDN filters its own logs and passes the relevant records directly to each Upstream peer. This requires that the Downstream CDN know the set of CDN-Domains that belong to each Upstream peer. If this information is already exchanged between peers as part of another interface, then direct peer-to-peer reporting is straightforward. If it is not available, and operators do not wish to advertise the set of CDN-Domains they serve to their peers, then the second option is for each CDN to send both its non-local traffic records and the set of CDN-Domains it serves to an independent third party (i.e., a CDN Exchange), which subsequently filters, merges, and distributes traffic records on behalf of each participating CDN operator.
未解決の問題の1つは、誰がフィルタリングを行うかです。 1つのオプションは、ダウンストリームCDNが自身のログをフィルタリングし、関連するレコードを各アップストリームピアに直接渡すことです。これには、ダウンストリームCDNが各アップストリームピアに属するCDNドメインのセットを知っている必要があります。この情報が別のインターフェイスの一部としてピア間ですでに交換されている場合、直接のピアツーピアレポートは簡単です。それが利用できず、オペレーターがピアにサービスを提供するCDNドメインのセットをアドバタイズしたくない場合、2番目のオプションは、各CDNが非ローカルトラフィックレコードとCDNドメインのセットの両方を送信することです。独立したサードパーティ（CDN交換など）にサービスを提供します。これにより、参加している各CDNオペレーターに代わって、トラフィックレコードがフィルター処理、マージ、および配布されます。
A second open question is how timely traffic information should be. For example, in addition to offline traffic logs, accurate real-time traffic monitoring might also be useful, but such information requires that the Downstream CDN inform the Upstream CDN each time it serves Upstream content from its cache. The Downstream CDN can do this, for example, by sending a conditional HTTP GET request (If-Modified-Since) to the Upstream CDN each time it receives an HTTP GET request from one of its end users. This allows the Upstream CDN to record that a request has been issued for the purpose of real-time traffic monitoring. The Upstream CDN can also use this information to validate the traffic logs received later from the Downstream CDN.
2つ目の未解決の問題は、タイムリーな交通情報のあり方です。たとえば、オフライントラフィックログに加えて、正確なリアルタイムトラフィックモニタリングも役立つ場合がありますが、そのような情報では、ダウンストリームCDNがキャッシュからアップストリームコンテンツを提供するたびにアップストリームCDNに通知する必要があります。たとえば、ダウンストリームCDNは、エンドユーザーの1つからHTTP GET要求を受信するたびに、条件付きHTTP GET要求（If-Modified-Since）をアップストリームCDNに送信することでこれを行うことができます。これにより、アップストリームCDNは、リアルタイムのトラフィック監視を目的としてリクエストが発行されたことを記録できます。アップストリームCDNは、この情報を使用して、ダウンストリームCDNから後で受信したトラフィックログを検証することもできます。
There is obviously a trade-off between accuracy of such monitoring and the overhead of the Downstream CDN having to go back to the Upstream CDN for every request.
そのような監視の正確さと、要求ごとにアップストリームCDNに戻る必要があるダウンストリームCDNのオーバーヘッドとの間には、明らかにトレードオフがあります。
Another design trade-off in the LI is the degree of aggregation or summarization of data. One situation that lends itself to summarization is the delivery of HTTP Adaptive Streaming (HAS), since the large number of individual chunk requests potentially results in large volumes of logging information. This case is discussed below, but other forms of aggregation may also be useful. For example, there may be situations where bulk metrics such as bytes delivered per hour may suffice rather than the detailed per-request logs outlined above. It seems likely that a range of granularities of logging will be needed along with ways to specify the type and degree of aggregation required.
LIのもう1つの設計上のトレードオフは、データの集計または要約の程度です。要約に役立つ状況の1つは、HTTP適応ストリーミング（HAS）の配信です。これは、多数の個別のチャンク要求が大量のログ情報を潜在的に生成するためです。このケースについては以下で説明しますが、他の形式の集約も役立つ場合があります。たとえば、上記のリクエストごとの詳細なログではなく、1時間あたりに配信されるバイト数などのバルクメトリックで十分な場合があります。必要な集約のタイプと程度を指定する方法とともに、ロギングのさまざまな粒度が必要になる可能性があります。
The CDNI Control interface is initially used to bootstrap the other interfaces. As a simple example, it could be used to provide the address of the logging server in the dCDN to the uCDN in order to bootstrap the CDNI Logging interface. It may also be used, for example, to establish security associations for the other interfaces.
CDNIコントロールインターフェイスは、最初は他のインターフェイスをブートストラップするために使用されます。簡単な例として、CDNIログインターフェイスをブートストラップするために、dCDNのログサーバーのアドレスをuCDNに提供するために使用できます。また、たとえば、他のインターフェイスのセキュリティアソシエーションを確立するために使用することもできます。
The other role the CI plays is to allow the uCDN to pre-position, revalidate, or purge metadata and content on a dCDN. These operations, sometimes collectively called the "Trigger interface", are discussed further in [CONTROL-TRIGGERS].
CIが果たす他の役割は、uCDNがdCDN上のメタデータとコンテンツを事前配信、再検証、またはパージできるようにすることです。これらの操作は、総称して「トリガーインターフェース」と呼ばれることもありますが、[CONTROL-TRIGGERS]で詳しく説明されています。
The role of the CDNI Metadata interface is to enable CDNI distribution metadata to be conveyed to the Downstream CDN by the Upstream CDN. Such metadata includes geo-blocking restrictions, availability windows, access-control policies, and so on. It may also include information to facilitate acquisition of content by a dCDN (e.g., alternate sources for the content, authorization information needed to acquire the content from the source). For a full discussion of the CDNI Metadata interface, see [METADATA]
CDNIメタデータインターフェイスの役割は、CDNI配信メタデータをアップストリームCDNによってダウンストリームCDNに伝達できるようにすることです。このようなメタデータには、ジオブロッキング制限、可用性ウィンドウ、アクセス制御ポリシーなどが含まれます。また、dCDNによるコンテンツの取得を容易にするための情報（たとえば、コンテンツの代替ソース、ソースからコンテンツを取得するために必要な承認情報）を含めることもできます。 CDNIメタデータインターフェイスの詳細については、[METADATA]を参照してください。
Some distribution metadata may be partially emulated using in-band mechanisms. For example, in case of any geo-blocking restrictions or availability windows, the Upstream CDN can elect to redirect a request to the Downstream CDN only if that CDN's advertised delivery footprint is acceptable for the requested URL. Similarly, the request could be forwarded only if the current time is within the availability window. However, such approaches typically come with shortcomings such as inability to prevent from replay outside the time window or inability to make use of a Downstream CDN that covers a broader footprint than the geo-blocking restrictions.
一部の配布メタデータは、帯域内メカニズムを使用して部分的にエミュレートされる場合があります。たとえば、ジオブロッキング制限またはアベイラビリティウィンドウの場合、アップストリームCDNは、要求されたURLに対してそのCDNのアドバタイズされた配信フットプリントが受け入れられる場合にのみ、要求をダウンストリームCDNにリダイレクトすることを選択できます。同様に、現在の時刻が可用性ウィンドウ内にある場合にのみ、要求を転送できます。ただし、このようなアプローチには通常、時間枠外での再生を防ぐことができない、またはジオブロッキングの制限よりも広いフットプリントをカバーするダウンストリームCDNを利用できないなどの欠点があります。
Similarly, some forms of access control may also be performed on a per-request basis using HTTP directives. For example, being able to respond to a conditional GET request gives the Upstream CDN an opportunity to influence how the Downstream CDN delivers its content. Minimally, the Upstream CDN can invalidate (purge) content previously cached by the Downstream CDN.
同様に、一部の形式のアクセス制御は、HTTPディレクティブを使用してリクエストごとに実行することもできます。たとえば、条件付きGETリクエストに応答できることで、アップストリームCDNは、ダウンストリームCDNがコンテンツを配信する方法に影響を与える機会を与えられます。最低限、アップストリームCDNは、ダウンストリームCDNによって以前にキャッシュされたコンテンツを無効にする（パージする）ことができます。
All of these in-band techniques serve to illustrate that uCDNs have the option of enforcing some of their access control policies themselves (at the expense of increased inter-CDN signaling load), rather than delegating enforcement to dCDNs using the MI. As a consequence, the MI could provide a means for the uCDN to express its desire to retain enforcement for itself. For example, this might be done by including a "check with me" flag in the metadata associated with certain content. The realization of such in-band techniques over the various inter-CDN acquisition protocols (e.g., HTTP) requires further investigation and may require small extensions or semantic changes to the acquisition protocol.
これらのインバンド技術はすべて、MIを使用して実施をdCDNに委任するのではなく、（CDN間シグナリング負荷の増加を犠牲にして）uCDNにアクセス制御ポリシーの一部を強制するオプションがあることを示しています。その結果、MIはuCDNがそれ自体の強制を維持したいという願望を表明する手段を提供する可能性があります。たとえば、特定のコンテンツに関連付けられたメタデータに「私と確認」フラグを含めることでこれを行うことができます。さまざまなCDN間取得プロトコル（HTTPなど）を介したそのようなインバンド技術の実現には、さらに調査が必要であり、取得プロトコルに小さな拡張や意味上の変更が必要になる場合があります。
We consider HTTP Adaptive Streaming (HAS) and the impact it has on the CDNI interfaces because large objects (e.g., videos) are broken into a sequence of small, independent chunks. For each of the following, a more thorough discussion, including an overview of the trade-offs involved in alternative designs, can be found in RFC 6983.
大きなオブジェクト（ビデオなど）は一連の小さな独立したチャンクに分割されるため、HTTPアダプティブストリーミング（HAS）とそれがCDNIインターフェイスに及ぼす影響を考慮します。以下のそれぞれについて、代替設計に伴うトレードオフの概要を含む、より徹底的な議論がRFC 6983にあります。
First, with respect to Content Acquisition and File Management, which are out of scope for the CDNI interfaces but, nonetheless, relevant to the overall operation, we assume no additional measures are required to deal with large numbers of chunks. This means that the dCDN is not explicitly made aware of any relationship between different chunks, and the dCDN handles each chunk as if it were an individual and independent content item. The result is that content acquisition between uCDN and dCDN also happens on a per-chunk basis. This approach is in line with the recommendations made in RFC 6983, which also identifies potential improvements in this area that might be considered in the future.
まず、コンテンツの取得とファイル管理についてですが、これらはCDNIインターフェイスの範囲外ですが、それでも全体的な操作に関連しているため、多数のチャンクを処理するために追加の対策は必要ないと想定しています。これは、dCDNが異なるチャンク間の関係を明示的に認識せず、dCDNが各チャンクを個別の独立したコンテンツアイテムであるかのように処理することを意味します。その結果、uCDNとdCDN間のコンテンツ取得もチャンクごとに行われます。このアプローチは、RFC 6983で行われた推奨事項に沿っています。RFC6983は、今後検討される可能性があるこの領域の潜在的な改善点も示しています。
Second, with respect to request routing, we note that HAS manifest files have the potential to interfere with request routing since manifest files contain URLs pointing to the location of content chunks. To make sure that a manifest file does not hinder CDNI request routing and does not place excessive load on CDNI resources, either the use of manifest files could be limited to those containing relative URLs or the uCDN could modify the URLs in the manifest. Our approach for dealing with these issues is twofold. As a mandatory requirement, CDNs should be able to handle unmodified manifest files containing either relative or absolute URLs. To limit the number of redirects, and thus the load placed on the CDNI interfaces, as an optional feature uCDNs can use the information obtained through the CDNI Request Routing Redirection interface to modify the URLs in the manifest file. Since the modification of the manifest file is an optional uCDN-internal process, this does not require any standardization effort beyond being able to communicate chunk locations in the CDNI Request Routing Redirection interface.
次に、リクエストルーティングに関して、コンテンツチャンクの場所を指すURLがマニフェストファイルに含まれているため、HASマニフェストファイルはリクエストルーティングを妨害する可能性があることに注意してください。マニフェストファイルがCDNI要求のルーティングを妨げず、CDNIリソースに過度の負荷がかからないようにするには、マニフェストファイルの使用を相対URLを含むファイルに制限するか、uCDNがマニフェスト内のURLを変更します。これらの問題に対処するための私たちのアプローチは2つあります。必須要件として、CDNは相対URLまたは絶対URLのいずれかを含む未変更のマニフェストファイルを処理できる必要があります。リダイレクトの数を制限し、CDNIインターフェイスにかかる負荷を制限するために、オプション機能として、uCDNはCDNI要求ルーティングリダイレクトインターフェイスを介して取得した情報を使用して、マニフェストファイル内のURLを変更できます。マニフェストファイルの変更はオプションのuCDN内部プロセスであるため、CDNI要求ルーティングリダイレクトインターフェイスでチャンクの場所を通信できる以上の標準化作業は必要ありません。
Third, with respect to the CDNI Logging interface, there are several potential issues, including the large number of individual chunk requests potentially resulting in large volumes of logging information, and the desire to correlate logging information for chunk requests that correspond to the same HAS session. For the initial CDNI specification, our approach is to expect participating CDNs to support per-chunk logging (e.g., logging each chunk request as if it were an independent content request) over the CDNI Logging interface. Optionally, the LI may include a Content Collection IDentifier (CCID) and/or a Session IDentifier (SID) as part of the logging fields, thereby facilitating correlation of per-chunk logs into per-session logs for applications benefiting from such session level information (e.g., session-based analytics). This approach is in line with the recommendations made in RFC 6983, which also identifies potential improvements in this area that might be considered in the future.
3つ目は、CDNI Loggingインターフェースに関して、いくつかの潜在的な問題があります。これには、大量のログ情報をもたらす可能性のある多数の個別のチャンクリクエスト、および同じHASセッションに対応するチャンクリクエストのログ情報を相互に関連付けたいという要望が含まれます。 。最初のCDNI仕様の場合、私たちのアプローチは、参加CDNがCDNIロギングインターフェイスを介してチャンクごとのロギング（たとえば、各チャンク要求を独立したコンテンツ要求であるかのようにロギングする）をサポートすることを期待することです。必要に応じて、LIはコンテンツ収集識別子（CCID）および/またはセッション識別子（SID）をログフィールドの一部として含むことができ、それにより、チャンクごとのログをセッションごとのログに関連付けて、そのようなセッションレベルの情報から利益を得るアプリケーションを容易にします。 （例えば、セッションベースの分析）。このアプローチは、RFC 6983で行われた推奨事項に沿っています。RFC6983は、今後検討される可能性があるこの領域の潜在的な改善点も示しています。
Fourth, with respect to the CDNI Control interface, and in particular purging HAS chunks from a given CDN, our approach is to expect each CDN supports per-chunk content purge (e.g., purging of chunks as if they were individual content items). Optionally, a CDN may support content purge on the basis of a "Purge IDentifier (Purge-ID)" allowing the removal of all chunks related to a given Content Collection with a single reference. It is possible that this Purge-ID could be merged with the CCID discussed above for HAS Logging, or alternatively, they may remain distinct.
第4に、CDNI制御インターフェースに関して、特に特定のCDNからHASチャンクをパージする場合、私たちのアプローチは、各CDNがチャンクごとのコンテンツパージをサポートすることを期待することです（たとえば、チャンクを個別のコンテンツアイテムであるかのようにパージします）。オプションで、CDNは「パージIDentifier（Purge-ID）」に基づいてコンテンツのパージをサポートし、単一の参照で特定のコンテンツコレクションに関連するすべてのチャンクを削除できるようにします。このPurge-IDは、HASロギングについて上記で説明したCCIDとマージできる可能性があります。
When using HTTP redirection, content URIs may be rewritten when redirection takes place within a uCDN, from a uCDN to a dCDN, and within the dCDN. In the case of cascaded CDNs, content URIs may be rewritten at every CDN hop (e.g., between the uCDN and the dCDN acting as the transit CDN, and between the transit CDN and the dCDN serving the request). The content URI used between any uCDN/dCDN pair becomes a common handle that can be referred to without ambiguity by both CDNs in all their inter-CDN communications. This handle allows the uCDN and dCDN to correlate information exchanged using other CDNI interfaces in both the Downstream direction (e.g., when using the MI) and the Upstream direction (e.g., when using the LI).
HTTPリダイレクトを使用する場合、リダイレクトがuCDN内、uCDNからdCDN内、およびdCDN内で行われると、コンテンツURIが書き換えられることがあります。カスケードCDNの場合、コンテンツURIはすべてのCDNホップで（たとえば、トランジットCDNとして機能するuCDNとdCDNの間、およびトランジットCDNと要求を処理するdCDNの間で）書き換えられる可能性があります。 uCDN / dCDNペアの間で使用されるコンテンツURIは、すべてのCDN間通信で両方のCDNによって曖昧さなしに参照できる共通のハンドルになります。このハンドルにより、uCDNおよびdCDNは、他のCDNIインターフェースを使用して交換された情報を、ダウンストリーム方向（MIを使用する場合など）とアップストリーム方向（LIを使用する場合など）の両方で関連付けることができます。
Consider the simple case of a single uCDN/dCDN pair using HTTP redirection. We introduce the following terminology for content URIs to simplify the discussion:
HTTPリダイレクションを使用する単一のuCDN / dCDNペアの単純なケースを考えます。議論を簡単にするために、コンテンツURIについて次の用語を紹介します。
"u-URI" represents a content URI in a request presented to the uCDN;
「u-URI」は、uCDNに提示されるリクエストのコンテンツURIを表します。
"ud-URI" is a content URI acting as the common handle across uCDN and dCDN for requests redirected by the uCDN to a specific dCDN;
「ud-URI」は、uCDNによって特定のdCDNにリダイレクトされたリクエストに対して、uCDNとdCDNの共通ハンドルとして機能するコンテンツURIです。
"d-URI" represents a content URI in a request made within the delegate dCDN.
「d-URI」は、デリゲートdCDN内で行われたリクエストのコンテンツURIを表します。
In our simple pair-wise example, the "ud-URI" effectively becomes the handle that the uCDN/dCDN pair use to correlate all CDNI information. In particular, for a given pair of CDNs executing the HTTP redirection, the uCDN needs to map the u-URI to the ud-URI handle for all MI message exchanges, while the dCDN needs to map the d-URI to the ud-URI handle for all LI message exchanges.
単純なペアワイズの例では、「ud-URI」は、実質的にすべてのCDNI情報を関連付けるためにuCDN / dCDNペアが使用するハンドルになります。特に、HTTPリダイレクションを実行する特定のCDNペアについて、uCDNはすべてのMIメッセージ交換のu-URIをud-URIハンドルにマップする必要がありますが、dCDNはd-URIをud-URIにマップする必要がありますすべてのLIメッセージ交換のハンドル。
In the case of cascaded CDNs, the transit CDN will rewrite the content URI when redirecting to the dCDN, thereby establishing a new handle between the transit CDN and the dCDN, that is different from the handle between the uCDN and transit CDN. It is the responsibility of the transit CDN to manage its mapping across handles so the right handle for all pairs of CDNs is always used in its CDNI communication.
カスケードCDNの場合、トランジットCDNはdCDNにリダイレクトするときにコンテンツURIを書き換え、トランジットCDNとdCDNの間に新しいハンドルを確立します。これは、uCDNとトランジットCDNの間のハンドルとは異なります。ハンドル間のマッピングを管理するのは中継CDNの責任であり、CDNのすべてのペアの正しいハンドルが常にCDNI通信で使用されます。
In summary, all CDNI interfaces between a given pair of CDNs need to always use the "ud-URI" handle for that specific CDN pair as their content URI reference.
要約すると、CDNの特定のペア間のすべてのCDNIインターフェイスは、その特定のCDNペアの「ud-URI」ハンドルをコンテンツURI参照として常に使用する必要があります。
In this section, we describe a number of possible deployment models that may be achieved using the CDNI interfaces described above. We note that these models are by no means exhaustive and that many other models may be possible.
このセクションでは、上記のCDNIインターフェースを使用して実現できるいくつかの可能なデプロイメントモデルについて説明します。これらのモデルは完全なものではなく、他の多くのモデルが可能である可能性があることに注意してください。
Although the reference model of Figure 1 shows all CDN functions on each side of the CDNI interface, deployments can rely on entities that are involved in any subset of these functions, and therefore only support the relevant subset of CDNI interfaces. As already noted in Section 3, effective CDNI deployments can be built without necessarily implementing all the interfaces. Some examples of such deployments are shown below.
図1の参照モデルは、CDNIインターフェイスの両側にあるすべてのCDN関数を示していますが、展開はこれらの関数のサブセットに含まれるエンティティに依存する可能性があるため、CDNIインターフェイスの関連するサブセットのみをサポートします。セクション3ですでに述べたように、必ずしもすべてのインターフェースを実装しなくても、効果的なCDNIデプロイメントを構築できます。そのような配置のいくつかの例を以下に示します。
Note that, while we refer to Upstream and Downstream CDNs, this distinction applies to specific content items and transactions. That is, a given CDN may be Upstream for some transactions and Downstream for others, depending on many factors such as location of the requesting client and the particular piece of content requested.
アップストリームとダウンストリームのCDNを参照していますが、この区別は特定のコンテンツアイテムとトランザクションに適用されることに注意してください。つまり、特定のCDNは、要求しているクライアントの場所や要求されている特定のコンテンツなどの多くの要因に応じて、一部のトランザクションではアップストリームになり、他のトランザクションではダウンストリームになる場合があります。
Although the reference model illustrated in Figure 1 shows a unidirectional CDN interconnection with a single uCDN and a single dCDN, any arbitrary CDNI meshing can be built from this, such as the example meshing illustrated in Figure 11. (Support for arbitrary meshing may or may not be in the initial scope for the working group, but the model allows for it.)
図1に示す参照モデルは、単一のuCDNと単一のdCDNを使用した単方向CDN相互接続を示していますが、図11に示すメッシュの例など、任意のCDNIメッシュをこれから構築できます（任意のメッシュのサポートは、ワーキンググループの初期スコープには含まれていませんが、モデルではそれが可能です。
------------- -----------
/ CDN A \<==CDNI===>/ CDN B \
\ / \ /
------------- -----------
/\ \\ /\
|| \\ ||
CDNI \==CDNI===\\ CDNI
|| \\ ||
\/ \/ \/
------------- -----------
/ CDN C \===CDNI===>/ CDN D \
\ / \ /
------------- -----------
/\
||
CDNI
||
\/
-------------
/ CDN E \
\ /
-------------
===> CDNI interfaces, with right-hand side CDN acting as dCDN
to left-hand side CDN
<==> CDNI interfaces, with right-hand side CDN acting as dCDN
to left-hand side CDN and with left-hand side CDN acting
as dCDN to right-hand side CDN
Figure 11: CDNI Deployment Model: CDN Meshing Example
図11：CDNI配置モデル：CDNメッシュの例
Note that our terminology refers to functional roles and not economic or business roles. That is, a given organization may be operating as both a CSP and a fully fledged uCDN when we consider the functions performed, as illustrated in Figure 12.
ここでの用語は、経済的またはビジネス上の役割ではなく、機能上の役割を指していることに注意してください。つまり、図12に示すように、実行された機能を考えると、特定の組織がCSPと本格的なuCDNの両方として運用されている可能性があります。
##################################### ##################
# # # #
# Organization A # # Organization B #
# # # #
# -------- ------------- # # ----------- #
# / CSP \ / uCDN \ # # / dCDN \ #
# | | | +----+ | # # | +----+ | #
# | | | | C | | # # | | C | | #
# | | | +----+ | # # | +----+ | #
# | | | +----+ | # # | +----+ | #
# | | | | L | | # # | | L | | #
# | |*****| +----+ |===CDNI===>| +----+ | #
# | | | +----+ | # # | +----+ | #
# | | | | RR | | # # | | RR | | #
# | | | +----+ | # # | +----+ | #
# | | | +----+ | # # | +----+ | #
# | | | | D | | # # | | D | | #
# | | | +----+ | # # | +----+ | #
# \ / \ / # # \ / #
# -------- ------------- # # ----------- #
# # # #
##################################### ##################
===> CDNI interfaces, with right-hand side CDN acting as dCDN
to left-hand side CDN
**** interfaces outside the scope of CDNI
C Control component of the CDN
L Logging component of the CDN
RR Request Routing component of the CDN
D Distribution component of the CDN
Figure 12: CDNI Deployment Model: Organization Combining CSP & uCDN
図12：CDNI展開モデル：CSPとuCDNを組み合わせた組織
As another example, a content provider organization may choose to run its own Request Routing function as a way to select among multiple candidate CDN providers; in this case, the content provider may be modeled as the combination of a CSP and of a special, restricted case of a CDN. In that case, as illustrated in Figure 13, the CDNI Request Routing interfaces can be used between the restricted CDN operated by the content provider Organization and the CDN operated by the full CDN organization acting as a dCDN in the request routing control plane. Interfaces outside the scope of the CDNI work can be used between the CSP functional entities of the content provider organization and the CDN operated by the full CDN organization acting as a uCDN) in the CDNI control planes other than the request routing plane (i.e., Control, Distribution, Logging).
別の例として、コンテンツプロバイダー組織は、複数の候補CDNプロバイダーの中から選択する方法として、独自の要求ルーティング機能を実行することを選択できます。この場合、コンテンツプロバイダーは、CSPとCDNの特別な制限付きケースの組み合わせとしてモデル化できます。その場合、図13に示すように、コンテンツプロバイダー組織が運営する制限付きCDNと、要求ルーティングコントロールプレーンでdCDNとして機能する完全なCDN組織が運営するCDNの間で、CDNI要求ルーティングインターフェイスを使用できます。 CDNI作業の範囲外のインターフェイスは、コンテンツプロバイダー組織のCSP機能エンティティと、要求ルーティングプレーン（つまり、コントロール）以外のCDNIコントロールプレーンで、uCDNとして機能する完全なCDN組織によって運用されるCDNの間で使用できます。 、配布、ロギング）。
##################################### ##################
# # # #
# Organization A # # Organization B #
# # # #
# -------- ------------- # # ----------- #
# / CSP \ / uCDN(RR) \ # # / dCDN(RR) \ #
# | | | +----+ | # # | +----+ | #
# | |*****| | RR |==========CDNI=====>| RR | | #
# | | | +----+ | # RR # | +----+ | #
# | | \ / # # | | #
# | | ------------- # # |uCDN(C,L,D)| #
# | | # # | +----+ | #
# | | # # | | C | | #
# | |*******************************| +----+ | #
# | | # # | +----+ | #
# | | # # | | L | | #
# | | # # | +----+ | #
# | | # # | +----+ | #
# | | # # | | D | | #
# | | # # | +----+ | #
# \ / # # \ / #
# -------- # # ----------- #
# # # #
##################################### ##################
===> CDNI Request Routing Interface
**** interfaces outside the scope of CDNI
Figure 13: CDNI Deployment Model: Organization Combining CSP and Partial CDN
図13：CDNI展開モデル：CSPと部分的CDNを組み合わせた組織
There are two additional concepts related to, but distinct from, CDNI. The first is CDN Federation. Our view is that CDNI is the more general concept, involving two or more CDNs serving content to each other's users, while federation implies a multi-lateral interconnection arrangement, but other CDNI agreements are also possible (e.g., symmetric bilateral, asymmetric bilateral). An important conclusion is that CDNI technology should not presume (or bake in) a particular interconnection agreement, but should instead be general enough to permit alternative interconnection arrangements to evolve.
CDNIに関連するが、CDNIとは異なる2つの追加の概念があります。 1つ目はCDNフェデレーションです。私たちの見解では、CDNIはより一般的な概念であり、2つ以上のCDNが互いのユーザーにコンテンツを提供することを含みますが、フェデレーションは多国間相互接続の配置を意味しますが、他のCDNI契約も可能です（たとえば、対称二国間、非対称二国間）。重要な結論は、CDNIテクノロジーは特定の相互接続協定を推定（または焼き付け）するのではなく、代わりに相互接続の取り決めを発展させるのに十分一般的であるべきであるということです。
The second concept often used in the context of CDN Federation is CDN Exchange -- a third-party broker or exchange that is used to facilitate a CDN federation. Our view is that a CDN exchange offers valuable machinery to scale the number of CDN operators involved in a multi-lateral (federated) agreement, but that this machinery is built on top of the core CDNI mechanisms. For example, as illustrated in Figure 14, the exchange might aggregate and redistribute information about each CDN footprint and capacity, as well as collect, filter, and redistribute traffic logs that each participant needs for interconnection settlement, but inter-CDN Request Routing, inter-CDN content distribution (including inter-CDN acquisition), and inter-CDN control, which fundamentally involve a direct interaction between an Upstream CDN and a Downstream CDN -- operate exactly as in a pair-wise peering arrangement. Turning to Figure 14, we observe that in this example:
CDNフェデレーションのコンテキストでよく使用される2番目の概念は、CDN Exchange（CDNフェデレーションを容易にするために使用されるサードパーティのブローカーまたはエクスチェンジ）です。私たちの見解では、CDN交換は多国間（連合）契約に関与するCDNオペレーターの数をスケーリングするための貴重な機械を提供しますが、この機械はコアCDNIメカニズムの上に構築されています。たとえば、図14に示すように、エクスチェンジは各CDNフットプリントと容量に関する情報を集約および再配布し、各参加者が相互接続決済に必要なトラフィックログを収集、フィルタリング、再配布しますが、CDNリクエストルーティング間-CDNコンテンツ配信（CDN間の取得を含む）、およびCDN間の制御（アップストリームCDNとダウンストリームCDN間の直接の相互作用が基本的に含まれる）は、ペアワイズピアリング配置とまったく同じように動作します。図14を見ると、この例では次のことがわかります。
o each CDN supports a direct CDNI Control interface to every other CDN
o 各CDNは、他のすべてのCDNへの直接CDNI制御インターフェースをサポートします
o each CDN supports a direct CDNI Metadata interface to every other CDN
o 各CDNは、他のすべてのCDNへの直接CDNIメタデータインターフェイスをサポートします
o each CDN supports a CDNI Logging interface with the CDN Exchange
o 各CDNは、CDN ExchangeとのCDNI Loggingインターフェースをサポートします
o each CDN supports both a CDNI Request Routing interface with the CDN Exchange (for aggregation and redistribution of dynamic CDN footprint discovery information) and a direct RI to every other CDN (for actual request redirection).
o 各CDNは、CDN ExchangeとのCDNI要求ルーティングインターフェイス（動的CDNフットプリント検出情報の集約と再配布用）と他のすべてのCDNへの直接RI（実際の要求リダイレクト用）の両方をサポートします。
---------- ---------
/ CDN A \ / CDN B \
| +----+ | | +----+ |
//========>| C |<==============CDNI============>| C |<==========\\
|| | +----+ | C | +----+ | ||
|| | +----+ | | +----+ | ||
|| //=====>| D |<==============CDNI============>| D |<=======\\ ||
|| || | +----+ | M | +----+ | || ||
|| || | | /------------\ | | || ||
|| || | +----+ | | +--+ CDN Ex| | +----+ | || ||
|| || //==>| RR |<===CDNI==>|RR|<=======CDNI====>| RR |<====\\ || ||
|| || || | +----+ | RR | +--+ | RR | +----+ | || || ||
|| || || | | | /\ | | | || || ||
|| || || | +----+ | | || +---+ | | +----+ | || || ||
|| || || | | L |<===CDNI=======>| L |<=CDNI====>| L | | || || ||
|| || || | +----+ | L | || +---+ | L | +----+ | || || ||
|| || || \ / \ || /\ / \ / || || ||
|| || || ----------- --||----||-- ----------- || || ||
|| || || || || || || ||
|| || || CDNI RR || || || ||
|| || || || CDNI L || || ||
|| || || || || || || ||
|| || || ---||----||---- || || ||
|| || || / \/ || \ || || ||
|| || || | +----+ || | || || ||
|| || \\=====CDNI==========>| RR |<=============CDNI========// || ||
|| || RR | +----+ \/ | RR || ||
|| || | +----+ | || ||
|| || | | L | | || ||
|| || | +----+ | || ||
|| || | +----+ | || ||
|| \\=======CDNI===========>| D |<=============CDNI===========// ||
|| M | +----+ | M ||
|| | +----+ | ||
\\==========CDNI===========>| C |<=============CDNI==============//
C | +----+ | C
\ CDN C /
--------------
<=CDNI RR=> CDNI Request Routing Interface
<=CDNI M==> CDNI Metadata Interface
<=CDNI C==> CDNI Control Interface
<=CDNI L==> CDNI Logging Interface
Figure 14: CDNI Deployment Model: CDN Exchange
図14：CDNI展開モデル：CDN Exchange
Note that a CDN exchange may alternatively support a different set of functionality (e.g., Logging only, or Logging and full request routing, or all the functionality of a CDN including content distribution). All these options are expected to be allowed by the IETF CDNI specifications.
CDN交換では、別の機能セット（たとえば、ロギングのみ、またはロギングと完全なリクエストルーティング、またはコンテンツ配信を含むCDNのすべての機能）がサポートされる場合があります。これらのオプションはすべて、IETF CDNI仕様で許可されていると想定されています。
There are a number of trust issues that need to be addressed by a CDNI solution. Many of them are in fact similar or identical to those in a simple CDN without interconnection. In a standard CDN environment (without CDNI), the CSP places a degree of trust in a single CDN operator to perform many functions. The CDN is trusted to deliver content with appropriate quality of experience for the end user. The CSP trusts the CDN operator not to corrupt or modify the content. The CSP often relies on the CDN operator to provide reliable accounting information regarding the volume of delivered content. The CSP may also trust the CDN operator to perform actions such as timely invalidation of content and restriction of access to content based on certain criteria such as location of the user and time of day, and to enforce per-request authorization performed by the CSP using techniques such as URI signing.
CDNIソリューションで対処する必要のある信頼の問題がいくつかあります。それらの多くは、実際には、相互接続のない単純なCDNのものと類似または同一です。標準CDN環境（CDNIなし）では、CSPは単一のCDNオペレーターにある程度の信頼を置き、多くの機能を実行します。 CDNは、エンドユーザーに適切な品質のエクスペリエンスを備えたコンテンツを提供すると信頼されています。 CSPは、コンテンツを破損または変更しないようにCDNオペレーターを信頼します。多くの場合、CSPはCDNオペレーターに依存して、配信されるコンテンツの量に関する信頼できるアカウンティング情報を提供します。 CSPはまた、CDNオペレーターを信頼して、ユーザーの場所や時刻などの特定の基準に基づいてコンテンツのタイムリーな無効化やコンテンツへのアクセスの制限などのアクションを実行し、CSPによって実行される要求ごとの承認を実施することもできます。 URI署名などの手法。
A CSP also places trust in the CDN not to distribute any information that is confidential to the CSP (e.g., how popular a given piece of content is) or confidential to the end user (e.g., which content has been watched by which user).
CSPはまた、CDNを信頼して、CSPに対して機密情報（特定のコンテンツの人気度など）やエンドユーザーに機密情報（たとえば、どのコンテンツがどのユーザーによって視聴されたか）を配布しないようにします。
A CSP does not necessarily have to place complete trust in a CDN. A CSP will in some cases take steps to protect its content from improper distribution by a CDN, e.g., by encrypting it and distributing keys in some out of band way. A CSP also depends on monitoring (possibly by third parties) and reporting to verify that the CDN has performed adequately. A CSP may use techniques such as client-based metering to verify that accounting information provided by the CDN is reliable. HTTP conditional requests may be used to provide the CSP with some checks on CDN operation. In other words, while a CSP may trust a CDN to perform some functions in the short term, the CSP is able, in most cases, to verify whether these actions have been performed correctly and to take action (such as moving the content to a different CDN) if the CDN does not live up to expectations.
CSPは、必ずしもCDNを完全に信頼する必要はありません。 CSPは、場合によっては、コンテンツをCDNによる不適切な配布から保護する手段を講じます。たとえば、コンテンツを暗号化し、帯域外の方法でキーを配布します。 CSPは、CDNが適切に実行されたことを確認するために、監視（おそらく第三者による）およびレポートにも依存しています。 CSPは、クライアントベースのメータリングなどの手法を使用して、CDNによって提供されるアカウンティング情報が信頼できることを確認します。 HTTP条件付き要求を使用して、CSPにCDN操作のいくつかのチェックを提供できます。つまり、CSPはCDNを信頼して短期的にいくつかの機能を実行しますが、ほとんどの場合、CSPはこれらのアクションが正しく実行されたかどうかを確認し、アクション（コンテンツの移動など）を実行できます。 CDNが異なる場合）CDNが期待に応えられない場合。
One of the trust issues raised by CDNI is transitive trust. A CDN that has a direct relationship with a CSP can now "outsource" the delivery of content to another (Downstream) CDN. That CDN may in term outsource delivery to yet another Downstream CDN, and so on.
CDNIが提起する信頼の問題の1つは、推移的な信頼です。 CSPと直接的な関係を持つCDNは、コンテンツの配信を別の（ダウンストリーム）CDNに「アウトソーシング」できるようになりました。そのCDNは、配信をさらに別のダウンストリームCDNにアウトソーシングする場合もあります。
The top-level CDN in such a chain of delegation is responsible for ensuring that the requirements of the CSP are met. Failure to do so is presumably just as serious as in the traditional single CDN case. Hence, an Upstream CDN is essentially trusting a Downstream CDN to perform functions on its behalf in just the same way as a CSP trusts a single CDN. Monitoring and reporting can similarly be used to verify that the Downstream CDN has performed appropriately. However, the introduction of multiple CDNs in the path between CSP and end user complicates the picture. For example, third-party monitoring of CDN performance (or other aspects of operation, such as timely invalidation) might be able to identify the fact that a problem occurred somewhere in the chain but not point to the particular CDN at fault.
このような一連の委任における最上位のCDNは、CSPの要件が確実に満たされるようにする責任があります。これを怠ると、おそらく、従来の単一CDNの場合と同じくらい深刻になります。したがって、CSPが単一のCDNを信頼するのと同じ方法で、上流CDNは本質的に下流CDNを信頼して、その代わりに機能を実行します。同様に、監視とレポートを使用して、ダウンストリームCDNが適切に実行されたことを確認できます。ただし、CSPとエンドユーザー間のパスに複数のCDNを導入すると、状況が複雑になります。たとえば、CDNパフォーマンス（またはタイムリーな無効化などの操作の他の側面）のサードパーティによる監視では、問題がチェーンのどこかで発生したが、障害のある特定のCDNを指し示していないという事実を識別できる場合があります。
In summary, we assume that an Upstream CDN will invest a certain amount of trust in a Downstream CDN, but that it will verify that the Downstream CDN is performing correctly, and take corrective action (including potentially breaking off its relationship with that CDN) if behavior is not correct. We do not expect that the trust relationship between a CSP and its "top level" CDN will differ significantly from that found today in single CDN situations. However, it does appear that more sophisticated tools and techniques for monitoring CDN performance and behavior will be required to enable the identification of the CDN at fault in a particular delivery chain.
要約すると、アップストリームCDNはダウンストリームCDNに一定の信頼を投資するが、ダウンストリームCDNが正しく実行されていることを確認し、修正アクション（そのCDNとの関係を切断する可能性を含む）を行うと想定します。動作が正しくありません。 CSPとその「トップレベル」のCDNの間の信頼関係が、今日の単一のCDN状況で見られるものと大きく異なることはありません。ただし、特定の配信チェーンで障害のあるCDNを識別できるようにするには、CDNのパフォーマンスと動作を監視するためのより高度なツールと手法が必要となるようです。
We expect that the detailed designs for the specific interfaces for CDNI will need to take the transitive trust issues into account. For example, explicit confirmation that some action (such as content removal) has taken place in a Downstream CDN may help to mitigate some issues of transitive trust.
CDNIの特定のインターフェイスの詳細な設計では、推移的な信頼の問題を考慮する必要があると考えています。たとえば、ダウンストリームCDNで何らかのアクション（コンテンツの削除など）が行われたことを明示的に確認すると、推移的な信頼の問題を軽減するのに役立ちます。
In general, a CDN has the opportunity to collect detailed information about the behavior of end users, e.g., by logging which files are being downloaded. While the concept of interconnected CDNs as described in this document doesn't necessarily allow any given CDN to gather more information on any specific user, it potentially facilitates sharing of this data by a CDN with more parties. As an example, the purpose of the CDNI Logging interface is to allow a dCDN to share some of its log records with a uCDN, both for billing purposes as well as for sharing traffic statistics with the Content Provider on whose behalf the content was delivered. The fact that the CDNI interfaces provide mechanisms for sharing such potentially sensitive user data, shows that it is necessary to include in these interface appropriate privacy and confidentiality mechanisms. The definition of such mechanisms is dealt with in the respective CDN interface documents.
一般に、CDNには、ダウンロードされているファイルをログに記録するなど、エンドユーザーの行動に関する詳細情報を収集する機会があります。このドキュメントで説明されている相互接続されたCDNの概念では、特定のCDNが特定のユーザーに関するより多くの情報を収集できるとは限りませんが、CDNがより多くの関係者とこのデータを共有できる可能性があります。例として、CDNIロギングインターフェイスの目的は、dCDNがそのログレコードの一部をuCDNと共有できるようにすることです。これは、課金の目的と、コンテンツを配信したコンテンツプロバイダーとのトラフィック統計情報の共有の両方を目的としています。 CDNIインターフェイスがそのような潜在的に機密性の高いユーザーデータを共有するためのメカニズムを提供するという事実は、これらのインターフェイスに適切なプライバシーおよび機密性メカニズムを含める必要があることを示しています。このようなメカニズムの定義は、それぞれのCDNインターフェイスドキュメントで扱われています。
While there are a variety of security issues introduced by a single CDN, we are concerned here specifically with the additional issues that arise when CDNs are interconnected. For example, when a single CDN has the ability to distribute content on behalf of a CSP, there may be concerns that such content could be distributed to parties who are not authorized to receive it, and there are mechanisms to deal with such concerns. Our focus in this section is on how CDNI introduces new security issues not found in the single CDN case. For a more detailed analysis of the security requirements of CDNI, see Section 9 of [RFC7337].
単一のCDNによって引き起こされるさまざまなセキュリティの問題がありますが、ここでは特にCDNが相互接続されたときに発生する追加の問題に関心があります。たとえば、単一のCDNがCSPに代わってコンテンツを配信する機能を持っている場合、そのようなコンテンツは、その受信を許可されていない当事者に配信される可能性があるという懸念があり、そのような懸念に対処するメカニズムがあります。このセクションでは、CDNIが単一のCDNのケースにはない新しいセキュリティ問題を導入する方法に焦点を当てています。 CDNIのセキュリティ要件の詳細な分析については、[RFC7337]のセクション9をご覧ください。
Many of the security issues that arise in CDNI are related to the transitivity of trust (or lack thereof) described in Section 6. As noted above, the design of the various interfaces for CDNI must take account of the additional risks posed by the fact that a CDN with whom a CSP has no direct relationship is now potentially distributing content for that CSP. The mechanisms used to mitigate these risks may be similar to those used in the single CDN case, but their suitability in this more complex environment must be validated.
CDNIで発生するセキュリティ問題の多くは、セクション6で説明されている信頼の推移性（または信頼性の欠如）に関連しています。前述のように、CDNIのさまざまなインターフェースの設計では、 CSPと直接の関係がないCDNが、そのCSPのコンテンツを配信している可能性があります。これらのリスクを軽減するために使用されるメカニズムは、単一のCDNケースで使用されるメカニズムと類似している可能性がありますが、このより複雑な環境での適切性を検証する必要があります。
CDNs today offer a variety of means to control access to content, such as time-of-day restrictions, geo-blocking, and URI signing. These mechanisms must continue to function in CDNI environments, and this consideration is likely to affect the design of certain CDNI interfaces (e.g., metadata, request routing). For more information on URI signing in CDNI, see [URI-SIGNING].
今日のCDNは、時刻制限、ジオブロッキング、URI署名など、コンテンツへのアクセスを制御するさまざまな手段を提供します。これらのメカニズムはCDNI環境でも機能し続ける必要があり、この考慮事項は特定のCDNIインターフェース（メタデータ、リクエストルーティングなど）の設計に影響を与える可能性があります。 CDNIでのURI署名の詳細については、[URI-SIGNING]を参照してください。
Just as with a single CDN, each peer CDN must ensure that it is not used as an "open proxy" to deliver content on behalf of a malicious CSP. Whereas a single CDN typically addresses this problem by having CSPs explicitly register content (or origin servers) that are to be served, simply propagating this information to peer Downstream CDNs may be problematic because it reveals more information than the Upstream CDN is willing to specify. (To this end, the content acquisition step in the earlier examples force the dCDN to retrieve content from the uCDN rather than go directly to the origin server.)
単一のCDNと同様に、各ピアCDNは、悪意のあるCSPに代わってコンテンツを配信する「オープンプロキシ」として使用されないようにする必要があります。単一のCDNは通常、配信されるコンテンツ（または配信元サーバー）をCSPに明示的に登録させることでこの問題に対処しますが、この情報をピアダウンストリームCDNに単に伝達することは、アップストリームCDNが指定するよりも多くの情報を明らかにするため、問題になる可能性があります。 （このために、前の例のコンテンツ取得手順では、dCDNがオリジンサーバーに直接アクセスするのではなく、uCDNからコンテンツを取得するように強制します。）
There are several approaches to this problem. One is for the uCDN to encode a signed token generated from a shared secret in each URL routed to a dCDN, and for the dCDN to validate the request based on this token. Another one is to have each Upstream CDN advertise the set of CDN-Domains they serve, where the Downstream CDN checks each request against this set before caching and delivering the associated object. Although straightforward, this approach requires operators to reveal additional information, which may or may not be an issue.
この問題にはいくつかのアプローチがあります。 1つは、uCDNがdCDNにルーティングされた各URLの共有シークレットから生成された署名済みトークンをエンコードし、dCDNがこのトークンに基づいてリクエストを検証することです。もう1つは、各アップストリームCDNがサービスするCDNドメインのセットをアドバタイズすることです。ダウンストリームCDNは、関連付けられたオブジェクトをキャッシュして配信する前に、このセットに対して各リクエストをチェックします。このアプローチは簡単ですが、オペレーターが追加情報を明らかにする必要があります。これは問題となる場合も、そうでない場合もあります。
It is noted in [RFC7337] that all CDNI interfaces must be able to operate securely over insecure IP networks. Since it is expected that the CDNI interfaces will be implemented using existing application protocols such as HTTP or Extensible Messaging and Presence Protocol (XMPP), we also expect that the security mechanisms available to those protocols may be used by the CDNI interfaces. Details of how these interfaces are secured will be specified in the relevant interface documents.
[RFC7337]では、すべてのCDNIインターフェースが安全でないIPネットワーク上で安全に動作できる必要があることが指摘されています。 CDNIインターフェースはHTTPやExtensible Messaging and Presence Protocol（XMPP）などの既存のアプリケーションプロトコルを使用して実装されることが予想されるため、これらのプロトコルで利用可能なセキュリティメカニズムがCDNIインターフェースで使用される可能性もあります。これらのインターフェースの保護方法の詳細は、関連するインターフェースのドキュメントで指定されます。
Digital Rights Management (DRM), also sometimes called digital restrictions management, is often employed for content distributed via CDNs. In general, DRM relies on the CDN to distribute encrypted content, with decryption keys distributed to users by some other means (e.g., directly from the CSP to the end user). For this reason, DRM is considered out of scope [RFC6707] and does not introduce additional security issues for CDNI.
デジタル著作権管理（DRM）は、デジタル制限管理とも呼ばれ、CDNを介して配信されるコンテンツによく使用されます。一般に、DRMはCDNに依存して暗号化されたコンテンツを配信し、復号化キーは他の方法で（たとえば、直接CSPからエンドユーザーに）ユーザーに配信されます。このため、DRMは範囲外[RFC6707]と見なされ、CDNIの追加のセキュリティ問題は発生しません。
The following individuals contributed to this document:
以下の個人がこの文書に貢献しました：
o Matt Caulfield
o マット・コールフィールド
o Francois Le Faucheur
o フランソワ・ル・フォシェール
o Aaron Falk
o アーロン・フォーク
o David Ferguson
o デビッドファーガソン
o John Hartman
o ジョン・ハートマン
o Ben Niven-Jenkins
o ベンニベンジェンキンス
o Kent Leung
o ケント・レオン
The authors would like to thank Huw Jones and Jinmei Tatuya for their helpful input to this document. In addition, the authors would like to thank Stephen Farrell, Ted Lemon, and Alissa Cooper for their reviews, which have helped to improve this document.
著者は、この文書への有益な情報提供に対してHuw JonesとJinmei Tatuyaに感謝します。さらに、著者は、このドキュメントの改善に貢献してくれたレビューについて、Stephen Farrell、Ted Lemon、およびAlissa Cooperに感謝します。
[CONTROL-TRIGGERS] Murray, R. and B. Niven-Jenkins, "CDNI Control Interface / Triggers", Work in Progress, July 2014.
[CONTROL-TRIGGERS]マレー、R.、B。ニベンジェンキンス、「CDNIコントロールインターフェース/トリガー」、進行中の作業、2014年7月。
[FOOTPRINT-CAPABILITY] Seedorf, J., Peterson, J., Previdi, S., Brandenburg, R., and K. Ma, "CDNI Request Routing: Footprint and Capabilities Semantics", Work in Progress, July 2014.
[FOOTPRINT-CAPABILITY] Seedorf、J.、Peterson、J.、Previdi、S.、Brandenburg、R。、およびK. Ma、「CDNI Request Routing：Footprint and Capabilities Semantics」、Work in Progress、2014年7月。
[LOGGING] Faucheur, F., Ed., Bertrand, G., Ed., Oprescu, I., Ed., and R. Peterkofsky, "CDNI Logging Interface", Work in Progress, July 2014.
[ロギング] Faucheur、F。、編、Bertrand、G。、編、Oprescu、I。、編、R。Peterkofsky、「CDNI Logging Interface」、Work in Progress、2014年7月。
[METADATA] Niven-Jenkins, B., Murray, R., Caulfield, M., Leung, K., and K. Ma, "CDN Interconnection Metadata", Work in Progress, July 2014.
[METADATA] Niven-Jenkins、B.、Murray、R.、Caulfield、M.、Leung、K。、およびK. Ma、「CDN Interconnection Metadata」、Work in Progress、2014年7月。
[REDIRECTION] Niven-Jenkins, B., Ed. and R. Brandenburg, Ed., "Request Routing Redirection Interface for CDN Interconnection", Work in Progress, April 2014.
[リダイレクト] Niven-Jenkins、B.、Ed。およびR.ブランデンブルク編、「CDN相互接続のためのリクエストルーティングリダイレクトインターフェイス」、進行中の作業、2014年4月。
[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月。
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", RFC 6707, September 2012.
[RFC6707] Niven-Jenkins、B.、Le Faucheur、F。、およびN. Bitar、「Content Distribution Network Interconnection（CDNI）Problem Statement」、RFC 6707、2012年9月。
[RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, K., and G. Watson, "Use Cases for Content Delivery Network Interconnection", RFC 6770, November 2012.
[RFC6770] Bertrand、G.、Stephan、E.、Burbridge、T.、Eardley、P.、Ma、K。、およびG. Watson、「Use Cases for Content Delivery Network Interconnection」、RFC 6770、2012年11月。
[RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F., and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware Content Distribution Network Interconnection (CDNI)", RFC 6983, July 2013.
[RFC6983] van Brandenburg、R.、van Deventer、O.、Le Faucheur、F。、およびK. Leung、「HTTP-Adaptive-Streaming-Aware Content Distribution Network Interconnection（CDNI）のモデル」、RFC 6983、2013年7月。
[RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution Network Interconnection (CDNI) Requirements", RFC 7337, August 2014.
[RFC7337] Leung、K.、Ed。 Y.リー、編、「コンテンツ配布ネットワーク相互接続（CDNI）の要件」、RFC 7337、2014年8月。
[URI-SIGNING] Leung, K., Faucheur, F., Downey, B., Brandenburg, R., and S. Leibrand, "URI Signing for CDN Interconnection (CDNI)", Work in Progress, March 2014.
[URI署名] Leung、K.、Faucheur、F.、Downey、B.、Brandenburg、R。、およびS. Leibrand、「CDN相互接続（CDNI）のURI署名」、進行中の作業、2014年3月。
Authors' Addresses
著者のアドレス
Larry Peterson Akamai Technologies, Inc. 8 Cambridge Center Cambridge, MA 02142 USA
Larry Peterson Akamai Technologies、Inc. 8 Cambridge Center Cambridge、MA 02142 USA
EMail: lapeters@akamai.com
Bruce Davie VMware, Inc. 3401 Hillview Ave. Palo Alto, CA 94304 USA
Bruce Davie VMware、Inc. 3401 Hillview Ave. Palo Alto、CA 94304 USA
EMail: bdavie@vmware.com
Ray van Brandenburg (editor) TNO Brassersplein 2 Delft 2612CT the Netherlands
レイ・ファン・ブランデンブルク（編集者）TNOブラッサースプレイン2デルフト2612CTオランダ
Phone: +31-88-866-7000
EMail: ray.vanbrandenburg@tno.nl