[要約] RFC 6770は、コンテンツデリバリーネットワーク（CDN）の相互接続に関する使用事例を提供するものであり、CDN間のトラフィックの効率化とパフォーマンスの向上を目的としています。
Internet Engineering Task Force (IETF) G. Bertrand, Ed.
Request for Comments: 6770 E. Stephan
Obsoletes: 3570 France Telecom - Orange
Category: Informational T. Burbridge
ISSN: 2070-1721 P. Eardley
BT
K. Ma
Azuki Systems, Inc.
G. Watson
Alcatel-Lucent (Velocix)
November 2012
Use Cases for Content Delivery Network Interconnection
コンテンツ配信ネットワーク相互接続の使用例
Abstract
概要
Content Delivery Networks (CDNs) are commonly used for improving the End User experience of a content delivery service while keeping cost at a reasonable level. This document focuses on use cases that correspond to identified industry needs and that are expected to be realized once open interfaces and protocols supporting the interconnection of CDNs are specified and implemented. This document can be used to motivate the definition of the requirements to be supported by CDN Interconnection (CDNI) interfaces. It obsoletes RFC 3570.
コンテンツ配信ネットワーク（CDN）は、コストを妥当なレベルに保ちながら、コンテンツ配信サービスのエンドユーザーエクスペリエンスを向上させるために一般的に使用されます。このドキュメントは、特定された業界のニーズに対応し、CDNの相互接続をサポートするオープンインターフェイスとプロトコルが指定および実装されると実現されることが期待される使用例に焦点を当てています。このドキュメントは、CDN相互接続（CDNI）インターフェースによってサポートされる要件の定義を動機付けるために使用できます。 RFC 3570は廃止されました。
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/rfc6770.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6770で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Rationale for CDN Interconnection . . . . . . . . . . . . 4
2. Footprint Extension Use Cases . . . . . . . . . . . . . . . . 6
2.1. Geographic Extension . . . . . . . . . . . . . . . . . . . 6
2.2. Inter-Affiliates Interconnection . . . . . . . . . . . . . 6
2.3. ISP Handling of Third-Party Content . . . . . . . . . . . 7
2.4. Nomadic Users . . . . . . . . . . . . . . . . . . . . . . 7
3. Offload Use Cases . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Overload Handling and Dimensioning . . . . . . . . . . . . 8
3.2. Resiliency . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Failure of Content Delivery Resources . . . . . . . . 9
3.2.2. Content Acquisition Resiliency . . . . . . . . . . . . 10
4. Capability Use Cases . . . . . . . . . . . . . . . . . . . . . 11
4.1. Device and Network Technology Extension . . . . . . . . . 11
4.2. Technology and Vendor Interoperability . . . . . . . . . . 12
4.3. QoE and QoS Improvement . . . . . . . . . . . . . . . . . 12
5. Enforcement of Content Delivery Policy . . . . . . . . . . . . 12
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Content Service Providers' Delivery Policies . . . . 14
A.1. Content Delivery Policy Enforcement . . . . . . . . . . . 14
A.2. Secure Access . . . . . . . . . . . . . . . . . . . . . . 15
A.3. Branding . . . . . . . . . . . . . . . . . . . . . . . . . 15
Content Delivery Networks (CDNs) are commonly used for improving the End User experience of a content delivery service while keeping cost at a reasonable level. This document focuses on use cases that correspond to identified industry needs and that are expected to be realized once open interfaces and protocols supporting the interconnection of CDNs are specified and implemented. The document can be used to motivate the definition of the requirements (as documented in [CDNI-REQ]) to be supported by the set of CDN Interconnection (CDNI) interfaces defined in [RFC6707].
コンテンツ配信ネットワーク（CDN）は、コストを妥当なレベルに保ちながら、コンテンツ配信サービスのエンドユーザーエクスペリエンスを向上させるために一般的に使用されます。このドキュメントは、特定された業界のニーズに対応し、CDNの相互接続をサポートするオープンインターフェイスとプロトコルが指定および実装されると実現されることが期待される使用例に焦点を当てています。このドキュメントを使用して、[RFC6707]で定義されているCDN相互接続（CDNI）インターフェースのセットでサポートされる要件（[CDNI-REQ]に記載）の定義を動機付けることができます。
[RFC3570] describes slightly different terminologies and models for "Content Internetworking (CDI)". This document obsoletes RFC 3570 to avoid confusion.
[RFC3570]は、「コンテンツインターネットワーキング（CDI）」のわずかに異なる用語とモデルについて説明しています。このドキュメントは、混乱を避けるためにRFC 3570を廃止します。
This document identifies the main motivations for a CDN Provider to interconnect its CDN:
このドキュメントでは、CDNプロバイダーがCDNを相互接続する主な動機を特定します。
o CDN Footprint Extension Use Cases (Section 2)
o CDN Footprint Extensionの使用例（セクション2）
o CDN Offload Use Cases (Section 3)
o CDNオフロードの使用例（セクション3）
o CDN Capability Use Cases (Section 4)
o CDN機能の使用例（セクション4）
Then, the document highlights the need for interoperability in order to exchange and enforce content delivery policies (Section 5).
次に、このドキュメントでは、コンテンツ配信ポリシーを交換および適用するための相互運用性の必要性を強調しています（セクション5）。
In this document, the first letter of each CDNI-specific term is capitalized. We adopt the terminology described in [RFC6707].
このドキュメントでは、各CDNI固有の用語の最初の文字が大文字になっています。 [RFC6707]で説明されている用語を採用しています。
We extend this terminology with the following term:
この用語を次の用語に拡張します。
Access CDN:
CDNにアクセス：
A CDN that includes Surrogates in the same administrative network as the End User. Such a CDN can use accurate information on the End User's network context to provide additional Content Delivery Services to Content Service Providers.
エンドユーザーと同じ管理ネットワークに代理を含むCDN。このようなCDNは、エンドユーザーのネットワークコンテキストに関する正確な情報を使用して、コンテンツサービスプロバイダーに追加のコンテンツ配信サービスを提供できます。
o CDN: Content Delivery Network, also known as Content Distribution Network
o CDN：Content Delivery Network、別名Content Distribution Network
o CSP: Content Service Provider o dCDN: downstream CDN
o CSP：コンテンツサービスプロバイダーo dCDN：ダウンストリームCDN
o DNS: Domain Name System
o DNS：ドメインネームシステム
o EU: End User
o EU：エンドユーザー
o ISP: Internet Service Provider
o ISP：インターネットサービスプロバイダー
o NSP: Network Service Provider
o NSP：ネットワークサービスプロバイダー
o QoE: Quality of Experience
o QoE：体験の質
o QoS: Quality of Service
o QoS：サービスの品質
o uCDN: upstream CDN
o uCDN：アップストリームCDN
o URL: Uniform Resource Locator
o URL：Uniform Resource Locator
o WiFi: Wireless local area network (WLAN) based on IEEE 802.11
o WiFi：IEEE 802.11に基づくワイヤレスローカルエリアネットワーク（WLAN）
Content Delivery Networks (CDNs) are used to deliver content because they can:
コンテンツ配信ネットワーク（CDN）は、次のことができるため、コンテンツの配信に使用されます。
o improve the experience for the End User; for instance delivery has lower latency (decreased round-trip-time and higher throughput between the user and the delivery server) and better robustness (ability to use multiple delivery servers),
o エンドユーザーのエクスペリエンスを改善する。たとえば、配信ではレイテンシが低く（ユーザーと配信サーバー間の往復時間が短縮され、スループットが高い）、堅牢性が高い（複数の配信サーバーを使用できる）
o reduce the network operator's costs; for instance, lower delivery cost (reduced bandwidth usage) for cacheable content,
o ネットワークオペレーターのコストを削減します。たとえば、キャッシュ可能なコンテンツの配信コストの削減（帯域幅の使用量の削減）、
o reduce the Content Service Provider's (CSP) internal infrastructure costs, such as data center capacity, space, and electricity consumption, as popular content is delivered externally through the CDN rather than through the CSP's own servers.
o 人気のあるコンテンツはCSPのサーバーではなくCDNを介して外部に配信されるため、データサービスの容量、スペース、電力消費などのコンテンツサービスプロバイダー（CSP）の内部インフラストラクチャコストを削減できます。
Indeed, many Network Service Providers (NSPs) and Enterprise Service Providers are deploying or have deployed their own CDNs. Despite the potential benefits of interconnecting CDNs, today each CDN is a stand-alone network. The objective of CDN Interconnection is to overcome this restriction; the interconnected CDNs should be able to collectively behave as a single delivery infrastructure.
実際、多くのネットワークサービスプロバイダー（NSP）とエンタープライズサービスプロバイダーが独自のCDNを展開しているか、展開しています。 CDNを相互接続することの潜在的な利点にもかかわらず、今日、各CDNはスタンドアロンネットワークです。 CDN相互接続の目的は、この制限を克服することです。相互接続されたCDNは、単一の配信インフラストラクチャとして集合的に動作できる必要があります。
An example is depicted in Figure 1, where two CDN Providers establish a CDN Interconnection. The Content Service Provider CSP-1 reaches an agreement with CDN Provider 'A' for the delivery of its content. Independently, CDN Provider 'A' and CDN Provider 'B' agree to interconnect their CDNs.
図1に例を示します。2つのCDNプロバイダーがCDN相互接続を確立します。コンテンツサービスプロバイダーCSP-1は、コンテンツの配信についてCDNプロバイダー 'A'と合意しました。独立して、CDNプロバイダー「A」とCDNプロバイダー「B」は、CDNを相互接続することに同意します。
When a given User Agent requests content from CSP-1, CDN-A may consider that delivery by CDN-B is appropriate, for instance, because CDN-B is an Access CDN and the user is directly attached to it. Through the CDN Interconnection arrangements put in place between CDN-A and CDN-B (as a result of the CDN Interconnection agreement established between CDN Provider 'A' and CDN Provider 'B'), CDN-A can redirect the request to CDN-B and the content is actually delivered to the User Agent by CDN-B.
特定のユーザーエージェントがCSP-1からコンテンツを要求すると、CDN-BはAccess CDNであり、ユーザーはそれに直接接続されているため、CDN-AはCDN-Bによる配信が適切であると見なす場合があります。 CDN-AとCDN-Bの間に配置されたCDN相互接続の取り決めを通じて（CDNプロバイダー「A」とCDNプロバイダー「B」の間で確立されたCDN相互接続合意の結果として）、CDN-Aは要求をCDN-にリダイレクトできますBおよびコンテンツは、実際にはCDN-Bによってユーザーエージェントに配信されます。
The End User benefits from this arrangement through a better Quality of Experience (QoE, see [RFC6390]), because the content is delivered from a nearby Surrogate (e.g., lower latency, bottlenecks avoided). CDN Provider 'A' benefits because it does not need to deploy such an extensive CDN, while CDN Provider 'B' may receive some compensation for the delivery. CSP-1 benefits because it only needs to make one business agreement and one technical arrangement with CDN Provider 'A', but its End Users get a service quality as though CSP-1 had also gone to the trouble of making a business agreement and technical arrangement with CDN Provider 'B'.
エンドユーザーは、コンテンツが近くのサロゲートから配信されるため（たとえば、レイテンシの低下、ボトルネックの回避など）、エクスペリエンスの質（QoE、[RFC6390]を参照）が向上することで、この配置からメリットを得ます。 CDNプロバイダー 'A'は、そのような大規模なCDNを展開する必要がないため、CDNプロバイダー 'B'が配信に対していくらかの補償を受けることができるため、メリットがあります。 CSP-1はCDNプロバイダー 'A'と1つのビジネスアグリーメントと1つの技術的アレンジメントを作成するだけでよいのでメリットがありますが、そのエンドユーザーはCSP-1がビジネスアグリーメントと技術的なトラブルを経験したかのようにサービス品質を得ますCDNプロバイダー「B」との取り決め。
+-------+ +-------+
| CSP-1 | | CSP-2 |
+-------+ +-------+
| |
,--,--,--./ ,--,--,--.
,-' `-. ,-' `-.
(CDN Provider 'A')=====(CDN Provider 'B')
`-. (CDN-A) ,-' `-. (CDN-B) ,-'
`--'--'--' `--'--'--'
|
+----------+
| End User |
+----------+
=== CDN Interconnection
Figure 1
図1
To extend the example, another Content Service Provider, CSP-2, may also reach an agreement with CDN Provider 'A'. However, CSP-2 may not want its content to be distributed by CDN Provider B; for example, CSP-2 may not want to distribute its content in the area where CDN Provider 'B' operates. This example illustrates that policy considerations are an important part of CDNI.
この例を拡張するために、別のコンテンツサービスプロバイダーであるCSP-2もCDNプロバイダー 'A'と合意に達する可能性があります。ただし、CSP-2はそのコンテンツがCDNプロバイダーBによって配布されることを望まない場合があります。たとえば、CSP-2は、CDNプロバイダー「B」が動作するエリアでコンテンツを配布したくない場合があります。この例は、ポリシーに関する考慮事項がCDNIの重要な部分であることを示しています。
Footprint extension is expected to be a major use case for CDN Interconnection.
フットプリントの拡張は、CDN相互接続の主要なユースケースになると予想されます。
In this use case, the CDN Provider wants to extend the geographic distribution that it can offer to its CSPs:
この使用例では、CDNプロバイダーは、CSPに提供できる地理的分布を拡張したいと考えています。
o without compromising the quality of delivery.
o 配信の品質を損なうことなく。
o without incurring additional transit and other network costs that would result from serving content from geographically or topologically remote Surrogates.
o 地理的またはトポロジー上離れたサロゲートからコンテンツを提供することに起因する追加のトランジットおよびその他のネットワークコストを発生させることなく。
o without incurring the cost of deploying and operating Surrogates and the associated CDN infrastructure that may not be justified in the corresponding geographic region (e.g., because of relatively low delivery volume, or conversely because of the high investments that would be needed to satisfy the high volume).
o サロゲートおよび対応する地理的地域で正当化されない可能性のある関連するCDNインフラストラクチャの展開と運用のコストが発生しない（たとえば、配信量が比較的少ないため、または逆に、大容量を満たすために必要な投資が高いため） ）。
If there are several CDN Providers that have a geographically limited footprint (e.g., restricted to one country), or do not serve all End Users in a geographic area, then interconnecting their CDNs enables these CDN Providers to provide their services beyond their own footprint.
地理的に限られたフットプリント（たとえば、1つの国に制限されている）を持つCDNプロバイダーが複数ある場合、または地理的エリア内のすべてのエンドユーザーにサービスを提供しない場合、それらのCDNを相互接続すると、これらのCDNプロバイダーは独自のフットプリントを超えてサービスを提供できます。
As an example, suppose a French CSP wants to distribute its TV programs to End Users located in France and various countries in North Africa. It asks a French CDN Provider to deliver the content. The French CDN Provider's network only covers France, so it makes an agreement with another CDN Provider that covers North Africa. Overall, from the CSP's perspective, the French CDN Provider provides a CDN service for both France and North Africa.
たとえば、フランスのCSPがテレビ番組をフランスと北アフリカのさまざまな国にいるエンドユーザーに配信したいとします。フランスのCDNプロバイダーにコンテンツの配信を依頼します。フランスのCDNプロバイダーのネットワークはフランスのみをカバーしているため、北アフリカをカバーする別のCDNプロバイダーと契約します。全体として、CSPの観点から見ると、フランスのCDNプロバイダーはフランスと北アフリカの両方にCDNサービスを提供しています。
In addition to video, this use case applies to other types of content such as automatic software updates (browser updates, operating system patches, virus database update, etc.).
ビデオに加えて、この使用例は、自動ソフトウェア更新（ブラウザーの更新、オペレーティングシステムのパッチ、ウイルスデータベースの更新など）などの他のタイプのコンテンツに適用されます。
The previous section describes the case of geographic extension between CDNs operated by different entities. A large CDN Provider may have several subsidiaries that each operate their own CDN (which may rely on different CDN technologies, see Section 4.2). In certain
前のセクションでは、さまざまなエンティティが運営するCDN間の地理的拡張のケースについて説明しました。大規模なCDNプロバイダーには、それぞれ独自のCDNを運用する複数の子会社がある場合があります（異なるCDNテクノロジーに依存している場合があります。セクション4.2を参照）。確かに
circumstances, the CDN Provider needs to make these CDNs interoperate to provide consistent service to its customers on the whole collective footprint.
状況によっては、CDNプロバイダーはこれらのCDNを相互運用して、全体的なフットプリント全体で一貫したサービスを顧客に提供する必要があります。
Consider an ISP carrying to its subscribers a lot of content that comes from a third-party CSP and that is injected into the ISP's network by an Authoritative CDN Provider. There are mutual benefits to the ISP (acting as an Access CDN), the Authoritative CDN, and the CSP that would make a case for establishing a CDNI agreement. For example:
ISPがサブスクライバーにサードパーティのCSPから提供され、Authoritative CDNプロバイダーによってISPのネットワークに注入される多くのコンテンツを運ぶことを検討してください。 ISP（アクセスCDNとして機能）、権威CDN、およびCSPには、CDNI契約の確立を主張する相互利益があります。例えば：
o allowing the CSP to offer improved QoE and QoE services to subscribers, for example, reduced content startup time or increased video quality and resolution of adaptive streaming content.
o CSPが改善されたQoEおよびQoEサービスをサブスクライバーに提供できるようにします。たとえば、コンテンツの起動時間を短縮したり、ビデオ品質とアダプティブストリーミングコンテンツの解像度を高めたりします。
o allowing the Authoritative CDN to reduce hardware capacity and footprint, by using the ISP caching and delivery capacity.
o Authoritative CDNがISPキャッシングおよび配信容量を使用することにより、ハードウェア容量とフットプリントを削減できるようにします。
o allowing the ISP to reduce traffic load on some segments of the network by caching inside of the ISP network.
o ISPネットワーク内のキャッシュにより、ISPがネットワークの一部のセグメントのトラフィック負荷を軽減できるようにします。
o allowing the ISP to influence and/or control the traffic ingress points.
o ISPがトラフィックの進入ポイントに影響を与えたり制御したりできるようにします。
o allowing the ISP to derive some incremental revenue for transport of the traffic and to monetize QoE services.
o ISPがトラフィックを転送するための収益を増やし、QoEサービスを収益化できるようにします。
In this scenario, a CSP wishes to allow End Users who move between access networks to continue to access their content. The motivation of this case is to allow nomadic End Users to maintain access to content with a consistent QoE across a range of devices and/or geographic regions.
このシナリオでは、CSPは、アクセスネットワーク間を移動するエンドユーザーがコンテンツに引き続きアクセスできるようにしたいと考えています。このケースの動機は、遊牧民のエンドユーザーが、さまざまなデバイスや地理的領域にわたって一貫したQoEでコンテンツへのアクセスを維持できるようにすることです。
This use case covers situations like:
このユースケースは、次のような状況をカバーしています。
o End Users moving between different access networks, which may be located within the same geographic region or different geographic regions.
o 同じ地理的領域または異なる地理的領域内にある異なるアクセスネットワーク間を移動するエンドユーザー。
o End Users switching between different devices or delivery technologies, as discussed in Section 4.
o セクション4で説明するように、エンドユーザーが異なるデバイスまたは配信テクノロジを切り替える。
Consider the following example, illustrated in Figure 2: End User A has a subscription to a broadband service from ISP A, her "home ISP". ISP A hosts CDN-A. Ordinarily, when End User A accesses content via ISP A (her "home ISP"), the content is delivered from CDN-A, which in this example is within ISP A's network.
図2に示されている次の例について考えてみます。エンドユーザーAは、彼女の "ホームISP"であるISP Aからのブロードバンドサービスに加入しています。 ISP AはCDN-Aをホストします。通常、エンドユーザーAがISP A（彼女の "ホームISP"）を介してコンテンツにアクセスすると、コンテンツはCDN-A（この例ではISP Aのネットワーク内）から配信されます。
However, while End User A is not connected to ISP A's network, for example, because it is connected to a WiFi provider or mobile network, End User A can also access the same content. In this case, End User A may benefit from accessing the same content delivered by an alternate CDN (CDN-B), in this case, hosted in the network of the WiFi or mobile provider (ISP B), rather than from CDN-A in ISP A's network.
ただし、エンドユーザーAは、たとえばWiFiプロバイダーまたはモバイルネットワークに接続されているため、ISP Aのネットワークに接続されていませんが、エンドユーザーAは同じコンテンツにアクセスできます。この場合、エンドユーザーAは、CDN-Aからではなく、WiFiまたはモバイルプロバイダー（ISP B）のネットワークでホストされている代替CDN（CDN-B）によって配信された同じコンテンツにアクセスすることでメリットを得られます。 ISP Aのネットワーク内。
+-------+
|Content|
+-------+
|
,--,--,--. ,--,--,--.
,-' ISP A `-. ,-' ISP B `-.
( (CDN-A) )=====( (CDN-B) )
`-. ,-' `-. ,-'
`--'--'--' `--'--'--'
| |
+------------+ +---------------+
+ EU A (home)| | EU A (nomadic)|
+------------+ +---------------+
=== CDN Interconnection
Figure 2
図2
Though the content of CSP A is not accessible by typical End Users of CDN-B, End User A is able to gain access to her "home" content (i.e., the content of CSP A) through the alternate CDN (CDN-B).
CSP AのコンテンツにはCDN-Bの一般的なエンドユーザーはアクセスできませんが、エンドユーザーAは代替CDN（CDN-B）を介して "ホーム"コンテンツ（つまり、CSP Aのコンテンツ）にアクセスできます。 。
Depending on the CSP's content delivery policies (see Appendix A.1), a user moving to a different geographic region may be subject to geo-blocking content delivery restrictions. In this case, he/she may not be allowed to access some pieces of content.
CSPのコンテンツ配信ポリシー（付録A.1を参照）によっては、別の地理的領域に移動するユーザーは、ジオブロッキングコンテンツ配信の制限を受ける場合があります。この場合、一部のコンテンツへのアクセスが許可されない場合があります。
A CDN is likely to be dimensioned to support an expected maximum traffic load. However, unexpected spikes in content popularity (flash crowd) may drive load beyond the expected peak. The prime recurrent time peaks of content distribution may differ between two CDNs. Taking advantage of the different traffic peak times, a CDN may interconnect with another CDN to increase its effective capacity during the peak of traffic. This brings dimensioning savings to the CDNs, as they can use each other's resources during their respective peaks of activity.
CDNは、予想される最大トラフィック負荷をサポートするように設計されている可能性があります。ただし、コンテンツの人気の急上昇（フラッシュクラウド）により、予想されるピークを超えて負荷がかかる場合があります。コンテンツ配信の主要な再発時間のピークは、2つのCDN間で異なる場合があります。さまざまなトラフィックのピーク時間を利用して、CDNは別のCDNと相互接続して、トラフィックのピーク時にその実効容量を増やすことができます。これにより、CDNはそれぞれの活動のピーク時に互いのリソースを使用できるため、寸法を節約できます。
Offload also applies to planned situations in which a CDN Provider needs CDN capacity in a particular region during a short period of time. For example, a CDN can offload traffic to another CDN for the duration of a specific maintenance operation or for the distribution of a special event, as in the scenario depicted in Figure 3. For instance, consider a TV channel that is the distributor for a major event, such as a celebrity's wedding or a major sport competition, and this TV channel has contracted particular CDNs for the delivery. The CDNs (CDN-A and CDN-B) that the TV channel uses for delivering the content related to this event are likely to experience a flash crowd during the event and will need to offload traffic, while other CDNs (CDN-C) will support a more typical traffic load and be able to handle the offloaded traffic.
オフロードは、CDNプロバイダーが特定のリージョンで短期間にCDN容量を必要とする計画的な状況にも適用されます。たとえば、CDNは、図3に示すシナリオのように、特定のメンテナンス操作の期間中、または特別なイベントの配信中にトラフィックを別のCDNにオフロードできます。たとえば、有名人の結婚式や主要なスポーツ大会などの主要なイベント。このテレビチャンネルでは、配信用に特定のCDNを契約しています。このイベントに関連するコンテンツを配信するためにTVチャネルが使用するCDN（CDN-AおよびCDN-B）は、イベント中にフラッシュクラウドを経験する可能性が高く、トラフィックをオフロードする必要がありますが、他のCDN（CDN-C）はより一般的なトラフィック負荷をサポートし、オフロードされたトラフィックを処理できるようにします。
In this use case, the Delivering CDN on which requests are offloaded should be able to handle the offloaded requests. Therefore, the uCDN might require information on the dCDNs to be aware of the amount of traffic it can offload to each dCDN.
この使用例では、要求がオフロードされる配信CDNは、オフロードされた要求を処理できる必要があります。したがって、uCDNでは、各dCDNにオフロードできるトラフィック量を認識するために、dCDNに関する情報が必要になる場合があります。
+------------+
| TV Channel |
+------------+
| \
,-,--,-. \ ,-,--,-. ,-,--,-.
,' `. ,' `. ,' CDN-C `.
( CDN-A ) ( CDN-B )==( offload )
`. ,' `. ,' `. ,'
`-'--'-' `-'--'-' `-'--'-'
=== CDN Interconnection
Figure 3
図3
It is important for CDNs to be able to guarantee service continuity during partial failures (e.g., failure of some Surrogates). In partial failure scenarios, a CDN Provider has at least three options: 1. if possible, use internal mechanisms to redirect traffic onto surviving equipment,
CDNが部分的な障害（一部のサロゲートの障害など）中にサービスの継続性を保証できることが重要です。部分的な障害シナリオでは、CDNプロバイダーには少なくとも3つのオプションがあります。1。可能な場合は、内部メカニズムを使用してトラフィックを生き残っている機器にリダイレクトします。
2. depending on traffic management policies, forward some requests to the CSP's origin servers, and/or
2. トラフィック管理ポリシーに応じて、一部の要求をCSPのオリジンサーバーに転送します。
3. redirect some requests toward another CDN, which must be able to serve the redirected requests.
3. 一部の要求を別のCDNにリダイレクトします。このCDNは、リダイレクトされた要求を処理できる必要があります。
The last option is a use case for CDNI.
最後のオプションは、CDNIの使用例です。
Source content acquisition may be handled in one of two ways:
ソースコンテンツの取得は、次の2つの方法のいずれかで処理されます。
o CSP origin, where a CDN acquires content directly from the CSP's origin server, or
o CDNがCSPの配信元サーバーから直接コンテンツを取得するCSP配信元、または
o CDN origin, where a downstream CDN acquires content from a Surrogate within an upstream CDN.
o ダウンストリームCDNがアップストリームCDN内のサロゲートからコンテンツを取得するCDNオリジン。
The ability to support content acquisition resiliency is an important use case for interconnected CDNs. When the content acquisition source fails, the CDN might switch to another content acquisition source. Similarly, when several content acquisition sources are available, a CDN might balance the load between these multiple sources.
コンテンツ取得の復元力をサポートする機能は、相互接続されたCDNの重要な使用例です。コンテンツ取得ソースに障害が発生すると、CDNが別のコンテンツ取得ソースに切り替わることがあります。同様に、複数のコンテンツ取得ソースが利用可能な場合、CDNはこれらの複数のソース間で負荷を分散する場合があります。
Though other server and/or DNS load-balancing techniques may be employed in the network, interconnected CDNs may have a better understanding of origin-server availability, and be better equipped to both distribute load between origin servers and attempt content acquisition from alternate content sources when acquisition failures occur. When normal content acquisition fails, a CDN may need to try other content source options, for example:
他のサーバーやDNSロードバランシング技術をネットワークで使用することもできますが、相互接続されたCDNは、オリジンサーバーの可用性をよりよく理解し、オリジンサーバー間で負荷を分散し、代替コンテンツソースからのコンテンツ取得を試行するための設備が整っている場合があります。取得失敗が発生したとき。通常のコンテンツ取得が失敗した場合、CDNは他のコンテンツソースオプションを試す必要がある場合があります。次に例を示します。
o an upstream CDN may acquire content from an alternate CSP origin server,
o アップストリームのCDNは、代替のCSPオリジンサーバーからコンテンツを取得します。
o a downstream CDN may acquire content from an alternate Surrogate within an upstream CDN,
o ダウンストリームCDNは、アップストリームCDN内の代替サロゲートからコンテンツを取得できます。
o a downstream CDN may acquire content from an alternate upstream CDN, or
o ダウンストリームCDNが代替のアップストリームCDNからコンテンツを取得する、または
o a downstream CDN may acquire content directly from the CSP's origin server.
o ダウンストリームCDNは、CSPのオリジンサーバーから直接コンテンツを取得する場合があります。
Though content acquisition protocols are beyond the scope of CDNI, the selection of content acquisition sources should be considered and facilitated.
コンテンツ取得プロトコルはCDNIの範囲外ですが、コンテンツ取得ソースの選択を検討して促進する必要があります。
In this use case, the CDN Provider may have the right geographic footprint, but may wish to extend the supported range of devices and User Agents or the supported range of delivery technologies. In this case, a CDN Provider may interconnect with a CDN that offers services that:
この使用例では、CDNプロバイダーは適切な地理的フットプリントを持っている可能性がありますが、サポートされるデバイスとユーザーエージェントの範囲、またはサポートされる配信テクノロジーの範囲を拡張したい場合があります。この場合、CDNプロバイダーは、次のサービスを提供するCDNと相互接続できます。
o the CDN Provider is not willing to provide, or
o CDNプロバイダーが提供する意思がない、または
o its own CDN is not able to support.
o 独自のCDNはサポートできません。
The following examples illustrate this use case:
次の例は、この使用例を示しています。
1. CDN-A cannot support a specific delivery protocol. For instance, CDN-A may interconnect with CDN-B to serve a proportion of its traffic that requires HTTPS [RFC2818]. CDN-A may use CDN-B's footprint (which may overlap with its own) to deliver HTTPS without needing to deploy its own infrastructure. This case could also be true of other formats, delivery protocols (e.g., the Real Time Messaging Protocol (RTMP), the Real Time Streaming Protocol (RTSP), etc.), and features (specific forms of authorization such as tokens, per session encryption, etc.).
1. CDN-Aは特定の配信プロトコルをサポートできません。たとえば、CDN-AはCDN-Bと相互接続して、HTTPS [RFC2818]を必要とするトラフィックの一部を処理します。 CDN-Aは、CDN-Bのフットプリント（独自のものと重複する場合がある）を使用して、独自のインフラストラクチャを展開する必要なくHTTPSを配信できます。このケースは、他のフォーマット、配信プロトコル（リアルタイムメッセージングプロトコル（RTMP）、リアルタイムストリーミングプロトコル（RTSP）など）、および機能（セッションごとのトークンなどの特定の形式の承認）にも当てはまる可能性があります。暗号化など）。
2. CDN-A has a footprint covering traditional fixed-line broadband and wants to extend coverage to mobile devices. In this case, CDN-A may contract and interconnect with CDN-B, who has both:
2. CDN-Aには、従来の固定回線ブロードバンドをカバーするフットプリントがあり、カバレッジをモバイルデバイスに拡張したいと考えています。この場合、CDN-Aは、次の両方を持つCDN-Bと契約および相互接続します。
* a physical footprint inside the mobile network,
* モバイルネットワーク内の物理的なフットプリント、
* the ability to deliver content over a protocol that is required by specific mobile devices.
* 特定のモバイルデバイスに必要なプロトコルを介してコンテンツを配信する機能。
3. CDN-A only supports IPv4 within its infrastructure but wants to deliver content over IPv6. CDN-B supports both IPv4 and IPv6 within its infrastructure. CDN-A interconnects with CDN-B to serve out its content over native IPv6 connections.
3. CDN-Aはインフラストラクチャ内でIPv4のみをサポートしていますが、IPv6を介してコンテンツを配信したいと考えています。 CDN-Bは、インフラストラクチャ内でIPv4とIPv6の両方をサポートしています。 CDN-AはCDN-Bと相互接続して、ネイティブIPv6接続を介してコンテンツを提供します。
These cases can apply to many CDN features that a given CDN Provider may not be able to support or not be willing to invest in, and thus, that the CDN Provider would delegate to another CDN.
これらのケースは、特定のCDNプロバイダーがサポートできない、または投資する意思がないため、CDNプロバイダーが別のCDNに委任する多くのCDN機能に適用できます。
A CDN Provider may deploy a new CDN to run alongside its existing CDN as a simple way of migrating its CDN service to a new technology. In addition, a CDN Provider may have a multi-vendor strategy for its CDN deployment. Finally, a CDN Provider may want to deploy a separate CDN for a particular CSP or a specific network. In all these circumstances, CDNI benefits the CDN Provider, as it simplifies or automates some inter-CDN operations (e.g., migrating the request routing function progressively).
CDNプロバイダーは、CDNサービスを新しいテクノロジーに移行する簡単な方法として、既存のCDNと一緒に実行する新しいCDNをデプロイできます。さらに、CDNプロバイダーは、そのCDN展開のためのマルチベンダー戦略を持っている場合があります。最後に、CDNプロバイダーは、特定のCSPまたは特定のネットワークに個別のCDNを展開する場合があります。これらすべての状況で、CDNIはCDNプロバイダーにメリットをもたらします。これは、CDNプロバイダーが一部のCDN間操作（たとえば、リクエストルーティング機能を徐々に移行する）を簡略化または自動化するためです。
Some CSPs are willing to pay a premium for enhanced delivery of content to their End Users. In some cases, even if the CDN Provider could deliver the content to the End Users, it would not meet the CSP's service-level requirements. As a result, the CDN Provider may establish a CDN Interconnection agreement with another CDN Provider that can provide the expected QoE to the End User, e.g., via an Access CDN that is able to deliver content from Surrogates located closer to the End User and with the required service level.
一部のCSPは、エンドユーザーへのコンテンツの配信を強化するために割増料金を払います。場合によっては、CDNプロバイダーがコンテンツをエンドユーザーに配信できても、CSPのサービスレベル要件を満たさないことがあります。その結果、CDNプロバイダーは、エンドユーザーに期待されるQoEをエンドユーザーに提供できる別のCDNプロバイダーとのCDN相互接続契約を確立する場合があります。たとえば、エンドユーザーに近いサロゲートからコンテンツを配信できるアクセスCDNを介して必要なサービスレベル。
An important aspect common to all the above use cases is that CSPs typically want to enforce content delivery policies. A CSP may want to define content delivery policies that specify when, how, and/or to whom the CDN delivers content. These policies apply to all interconnected CDNs (uCDNs and dCDNs) in the same or similar way that a CSP can define content delivery policies for content delivered by a single, non-interconnected CDN. Appendix A provides examples of CSP-defined policies.
上記のすべてのユースケースに共通する重要な側面は、CSPは通常、コンテンツ配信ポリシーを適用したいということです。 CSPは、CDNがコンテンツをいつ、どのように、誰に配信するかを指定するコンテンツ配信ポリシーを定義したい場合があります。これらのポリシーは、CSPが単一の相互接続されていないCDNによって配信されるコンテンツのコンテンツ配信ポリシーを定義できるのと同じ方法または類似の方法で、相互接続されたすべてのCDN（uCDNおよびdCDN）に適用されます。付録Aは、CSP定義のポリシーの例を示しています。
The authors would like to thank Kent Leung, Francois Le Faucheur, Ben Niven-Jenkins, and Scott Wainner for lively discussions, as well as for their reviews and comments on the mailing list.
著者は、活発な議論、ならびにメーリングリストでのレビューとコメントを提供してくれたKent Leung、Francois Le Faucheur、Ben Niven-Jenkins、Scott Wainnerに感謝します。
They also thank the contributors of the EU FP7 OCEAN and ETICS projects for valuable inputs.
また、貴重な情報を提供してくれたEU FP7 OCEANおよびETICSプロジェクトの貢献者にも感謝します。
Finally, the authors acknowledge the work of the former CDI working group. This document obsoletes [RFC3570] to avoid confusion.
最後に、著者は、以前のCDIワーキンググループの作業を認めます。このドキュメントは混乱を避けるために[RFC3570]を廃止しました。
This document focuses on the motivational use cases for CDN Interconnection and does not analyze the associated threats. Those threats are discussed in [RFC6707]. Appendix A.2 of this document provides example security policies that CSPs might impose on CDNs to mitigate the threats.
このドキュメントでは、CDN相互接続の動機付けのユースケースに焦点を当て、関連する脅威を分析しません。これらの脅威については、[RFC6707]で説明されています。このドキュメントの付録A.2は、脅威を軽減するためにCSPがCDNに課す可能性があるセキュリティポリシーの例を示しています。
[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月。
[CDNI-REQ] Leung, K. and Y. Lee, "Content Distribution Network Interconnection (CDNI) Requirements", Work in Progress, June 2012.
[CDNI-REQ] Leung、K. and Y. Lee、 "Content Distribution Network Interconnection（CDNI）Requirements"、Work in Progress、2012年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818] Rescorla、E。、「HTTP over TLS」、RFC 2818、2000年5月。
[RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content Internetworking (CDI) Scenarios", RFC 3570, July 2003.
[RFC3570] Rzewski、P.、Day、M。、およびD. Gilletti、「Content Internetworking（CDI）Scenarios」、RFC 3570、2003年7月。
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, October 2011.
[RFC6390] Clark、A。およびB. Claise、「新しいパフォーマンスメトリック開発を検討するためのガイドライン」、BCP 170、RFC 6390、2011年10月。
CSPs commonly apply different delivery policies to given sets of content assets delivered through CDNs. Interconnected CDNs need to support these policies. This appendix presents examples of CSPs' delivery policies and their consequences on CDNI operations.
CSPは通常、CDNを通じて配信されるコンテンツアセットの特定のセットに異なる配信ポリシーを適用します。相互接続されたCDNはこれらのポリシーをサポートする必要があります。この付録では、CSPの配信ポリシーの例とCDNI運用への影響について説明します。
The content distribution policies that a CSP attaches to a content asset may depend on many criteria. For instance, distribution policies for audiovisual content often combine constraints of varying levels of complexity and sophistication, for example:
CSPがコンテンツアセットに添付するコンテンツ配布ポリシーは、多くの基準に依存する場合があります。たとえば、視聴覚コンテンツの配信ポリシーは、さまざまなレベルの複雑さと高度さの制約を組み合わせることがよくあります。次に例を示します。
o temporal constraints (e.g., available for 24 hours, available 28 days after DVD release, etc.),
o 時間的制約（24時間利用可能、DVDリリース後28日利用可能など）、
o user agent platform constraints (e.g., mobile device platforms, desktop computer platforms, set-top-box platforms, etc.),
o ユーザーエージェントプラットフォームの制約（モバイルデバイスプラットフォーム、デスクトップコンピュータープラットフォーム、セットトップボックスプラットフォームなど）、
o resolution-based constraints (e.g., high definition vs. standard definition encodings),
o 解像度ベースの制約（高解像度エンコーディングと標準解像度エンコーディングなど）、
o user agent identification or authorization,
o ユーザーエージェントの識別または承認
o access network constraints (e.g., per NSP), and
o ネットワークの制約にアクセスする（例：NSPごと）
o IP geo-blocking constraints (e.g., for a given coverage area).
o IPジオブロッキング制約（たとえば、特定のカバレッジエリア）。
CSPs may use sophisticated policies in accordance with their business model. However, the enforcement of those policies does not necessarily require that the delivery network understand the policy rationales or how policies apply to specific content assets. Content delivery policies may be distilled into simple rules that can be commonly enforced across all dCDNs. These rules may influence dCDN delegation and Surrogate selection decisions, for instance, to ensure that the specific rules (e.g., time-window, geo-blocking, pre-authorization validation) can indeed be enforced by the Delivering CDN. In turn, this can guarantee to the CSP that content delivery policies are properly applied.
CSPは、ビジネスモデルに従って高度なポリシーを使用できます。ただし、これらのポリシーを実施するために、配信ネットワークがポリシーの根拠や特定のコンテンツアセットにポリシーを適用する方法を理解している必要はありません。コンテンツ配信ポリシーは、すべてのdCDNに一般的に適用できる単純なルールに抽出される場合があります。これらのルールは、dCDN委任と代理選択の決定に影響を与える可能性があります。たとえば、特定のルール（タイムウィンドウ、ジオブロッキング、事前承認の検証など）が実際に配信CDNによって確実に実施されるようにします。これにより、コンテンツ配信ポリシーが適切に適用されていることをCSPに保証できます。
+-----+
| CSP | Policies driven by business (e.g., available only
+-----+ in the UK and only from July 1st to September 1st)
\
\ Translate policies into
\simple rules (e.g., provide an authorization token)
\
V
+-----+
| CDN | Apply simple rules (e.g., check an
+-----+ authorization token and enforce geo-blocking)
\
\ Distribute simple rules
V
+-----+
| CDN | Apply simple rules
+-----+
Figure 4
図4
Many protocols exist for delivering content to End Users. CSPs may dictate a specific protocol or set of protocols that are acceptable for delivery of their content, especially in the case where a secured content transmission is required (e.g., must use HTTPS). CSPs may also perform a per-request authentication/authorization decision and then have the CDNs enforce that decision (e.g., must validate URL signing, etc.).
エンドユーザーにコンテンツを配信するための多くのプロトコルが存在します。 CSPは、特に安全なコンテンツ送信が必要な場合（HTTPSを使用する必要がある場合など）は、コンテンツの配信に許容される特定のプロトコルまたはプロトコルのセットを指示する場合があります。 CSPは、要求ごとの認証/承認の決定を実行し、CDNにその決定を強制させることもできます（たとえば、URL署名を検証する必要があります）。
Preserving the branding of the CSP throughout delivery is often important to the CSP. CSPs may desire to offer content services under their own name, even when the associated CDN service involves other CDN Providers. For instance, a CSP may desire to ensure that content is delivered with URIs appearing to the End Users under the CSP's own domain name, even when the content delivery involves separate CDN Providers. The CSP may wish to prevent the delivery of its content by specific dCDNs that lack support for such branding preservation features.
多くの場合、CSPの配信中のブランディングを維持することは、CSPにとって重要です。 CSPは、関連するCDNサービスが他のCDNプロバイダーに関係している場合でも、独自の名前でコンテンツサービスを提供したい場合があります。たとえば、コンテンツ配信に別個のCDNプロバイダーが含まれている場合でも、CSPは、コンテンツがURIとともにエンドユーザーにCSP独自のドメイン名で配信されるようにすることを望む場合があります。 CSPは、このようなブランディングの保存機能をサポートしていない特定のdCDNによるコンテンツの配信を防止したい場合があります。
Analogous cases exist when the uCDN wants to offer CDN services under its own branding even if dCDNs are involved, and so it restricts the delivery delegation to a chain that preserves its brand visibility.
uCDNがdCDNが含まれている場合でも、独自のブランドでCDNサービスを提供したい場合も同様です。そのため、配信の委任は、ブランドの可視性を維持するチェーンに制限されます。
Authors' Addresses
著者のアドレス
Gilles Bertrand (editor) France Telecom - Orange 38-40 rue du General Leclerc Issy les Moulineaux, 92130 FR Phone: +33 1 45 29 89 46 EMail: gilles.bertrand@orange.com
Gilles Bertrand（編集者）France Telecom-Orange 38-40 rue du General Leclerc Issy les Moulineaux、92130 FR電話：+33 1 45 29 89 46メール：gilles.bertrand@orange.com
Stephan Emile France Telecom - Orange 2 avenue Pierre Marzin Lannion F-22307 FR EMail: emile.stephan@orange.com
Stephan Emile France Telecom-Orange 2 avenue Pierre Marzin Lannion F-22307 FR Eメール：emile.stephan@orange.com
Trevor Burbridge BT B54 Room 70, Adastral Park, Martlesham Ipswich, IP5 3RE UK EMail: trevor.burbridge@bt.com
Trevor Burbridge BT B54 Room 70、Adastral Park、Martlesham Ipswich、IP5 3RE UKメール：trevor.burbridge@bt.com
Philip Eardley BT B54 Room 77, Adastral Park, Martlesham Ipswich, IP5 3RE UK EMail: philip.eardley@bt.com
Philip Eardley BT B54 Room 77、Adastral Park、Martlesham Ipswich、IP5 3RE UKメール：philip.eardley@bt.com
Kevin J. Ma Azuki Systems, Inc. 43 Nagog Park Acton, MA 01720 USA Phone: +1 978-844-5100 EMail: kevin.ma@azukisystems.com
Kevin J. Ma Azuki Systems、Inc. 43 Nagog Park Acton、MA 01720 USA電話：+1 978-844-5100メール：kevin.ma@azukisystems.com
Grant Watson Alcatel-Lucent (Velocix) 3 Ely Road Milton, Cambridge CB24 6AA UK EMail: gwatson@velocix.com
Grant Watson Alcatel-Lucent（Velocix）3 Ely Road Milton、Cambridge CB24 6AA UKメール：gwatson@velocix.com