コンテンツ配信ネットワークの相互接続

コンテンツ配信ネットワーク相互接続(CDNI) は、独立した 2 つのコンテンツ配信ネットワーク(CDN) を相互接続するために必要なインターフェイスとメカニズムのセットで、これにより、一方が他方に代わってコンテンツを配信できるようになります。相互接続された CDN は、コンテンツ サービス プロバイダー (CSP)、CDN、およびエンド ユーザーに、フットプリントの拡張、インフラストラクチャ コストの削減、可用性の向上など、多くのメリットをもたらします。その多くのユース ケースの中でも、小規模な CDN を相互接続し、CSP がグローバル CSP の CDN と競合できるサービスを提供できるようにします。

CDN には、配信コストの削減、体感品質 (QoE) の向上、配信の堅牢性の向上など、多くの利点があるため、キャッシュ可能なコンテンツの大規模なコンテンツ配信で CDN が普及しています。このため、CDN プロバイダーはインフラストラクチャを拡張しており、多くのインターネット サービス プロバイダー (ISP)/ネットワーク サービス プロバイダー (NSP) は、CDN プロバイダーとの間でビジネスおよび技術契約が結ばれている場合は、自社使用またはリース用に独自の CDN を導入済みまたは導入中です。要求ルーティング、配信、取得、課金システム、プロトコルが明確に定義されたスタンドアロン CDN は、遅かれ早かれフットプリント、リソース、または機能の制限に直面する可能性があります。CDNI は、場所や接続ネットワークに関係なく、個別の CDN を活用して、CSP からエンド ユーザーへのコンテンツのエンドツーエンド配信を提供することを目標としています。

下の図に示すように、2 つの CDN の相互接続を考えてみましょう。ISP-A は権威ある上流 CDN (uCDN) を展開し、CSP と技術およびビジネス上の取り決めを結んでいます。CDN-A は CSP に代わってサービスを提供する権限を持っているため、ISP-B のネットワーク内のユーザーは CDN-A (1) にコンテンツを要求します。uCDN は、要求を自ら処理することも、たとえば dCDN がユーザー機器 (UE) に近い場合は、要求を下流 CDN (dCDN) にリダイレクトすることもできます。要求がリダイレクトされた場合、相互接続された CDN は要求されたコンテンツを dCDN に提供する必要があります。コンテンツが uCDN で利用できない場合は、まず CSP (2) から取得し、次に dCDN の代理に送信します (3)。リダイレクト後の UE は dCDN (4) にコンテンツを要求し、最後に要求されたコンテンツが代理から配信されます。

この例では、4 つの関係者すべてが相互接続から恩恵を受けることができます。エンド ユーザーは、サービス品質 (QoS) の向上という恩恵を受けることができます。CSP は、uCDN と 1 つのビジネスおよび技術契約を結ぶだけで済むため恩恵を受けます。uCDN は、大規模な CDN を展開する必要がないため恩恵を受けます。dCDN は配信に対していくらかの報酬を受け取ります。適切な dCDN の選択、サロゲートの選択、サロゲートに送信するコンテンツを取得する手順を担当する手順とアルゴリズムは異なる場合がありますが、dCDN は uCDN に代わってコンテンツを提供します。

以下はCDNIが提示されたユースケースの不完全なリストです。^[1]ユースケースは標準化アプローチ間で収束しているようです（標準化状況のセクションを参照）。

フットプリントとは、CDNがコンテンツを配信できる地域として定義されます。CDNIを導入することで、非グローバルCDNプロバイダーは、CSPに地理的フットプリントを拡大し、

• 配信の品質を損なうこと。
• コンテンツが地理的またはトポロジ的に離れた代理サーバーから提供される場合、追加の転送コストが発生します。
• 当該地域で正当化されない代理サービスの展開および運用（例：高い投資コスト、低い配送量）

相互接続は、さまざまな場所に多数の CDN を所有し、それらを相互運用可能にしたいと考えている大規模な CDN プロバイダーにとって魅力的かもしれません。

CDNI フットプリント拡張は、CDN プロバイダーが多数の人気コンテンツを少数の ISP のネットワークに配信する場合にも役立ちます。その場合、そのような CDN を相互接続すると、エンド ユーザーに QoS と QoE が向上し、ISP ネットワークの入力トラフィックが削減されて制御できるようになり、uCDN のハードウェア容量とフットプリントが削減され、ISP がいくらかの収益を得ることができます。

さらに、相互接続されたネットワークにより、移動の多いエンド ユーザーは、さまざまなデバイスや地理的領域にわたって一貫した QoE でコンテンツにアクセスできるようになります。

CDNI は、予期しないトラフィックの急増 (CDN が想定したピークを超えるフラッシュ クラウドなど) を uCDN と dCDN の間で分散できるため、過負荷処理に非常に役立ちます。CDN がリソースを共有すると、ディメンショニングによる節約のメリットが得られます。このようなメカニズムが適切に機能するには、uCDN はオフロードできるトラフィックの量に関する情報を dCDN からリアルタイムで受け取る必要があります。一方、メンテナンスや特別イベントの配布などの計画されたイベントの場合は、静的なリソース予約で十分です。

さらに、CDNI は、コンテンツの配信と取得の失敗に対する回復力を提供する手段を提供します。これを導入すると、CSP のサロゲートとオリジン サーバーが利用できない場合に、配信要求を別の CDN にリダイレクトできます。同様に、導入された CDNI では、デフォルトの取得ソースに障害が発生した場合、相互接続内の他のソース (代替 uCDN など) を使用できます。これにより、コンテンツ取得ソース間の負荷分散が実現します。

CDN がサポートできない場合、または CDN プロバイダーが提供を希望しない場合、CDNI はサポートされるデバイスとネットワーク テクノロジの範囲を拡張する手段となります。たとえば、CDN プロバイダーは、HTTP ストリーミングと IPv4 のみをサポートしながら、サービスのポートフォリオを HTTP アダプティブ ストリーミングと IPv6 に拡張したい場合があります。この拡張は、要求されたプロトコルを提供できる CDN に相互接続することで実現できます。同様に、相互接続により、固定回線 CDN プロバイダーはサービスをモバイル デバイスに拡張できます。

CDN プロバイダーがさまざまなテクノロジーで多数のネットワークを運用している場合、マルチベンダー戦略を採用している場合、または多数の CSP に個別のネットワークを展開している場合、相互接続により、一部の CDN 間操作が簡素化または自動化され、テクノロジーとベンダーの相互運用性の確立が容易になります。

もう 1 つのユースケースとしては、エンド ユーザーに近い代理ネットワークとの相互接続オプションが存在する場合、CDN プロバイダーの QoS と QoE が向上することが挙げられます。

インターネット技術特別調査委員会（IETF）（標準化状況のセクションを参照）^{[1] [2]}は、図2に示すように、技術的な観点からCDNのペアを相互接続するために必要な5つのインタフェースを定義しています。インタフェースは、アプリケーション層で動作するコントロールプレーンインタフェースであり、新しいプロトコルを定義するのではなく、HTTPなどの既存のプロトコルを再利用または活用することを目的としています。このCDNIモデルでは、コンテンツの取得、配信、要求のインタフェースとメカニズムは定義されていません。これは、今日のCDNは、コンテンツの取得にHTTP、FTP、rsyncなど、標準化されたプロトコルをすでに使用しているためです。相互接続により、ライン、メッシュ、スタートトポロジなど、さまざまなトポロジで多数のCDNを接続できます。CDNIを展開するには、CSPとuCDNの間、およびuCDNとdCDNの間に追加のビジネス契約を確立する必要があることに注意することが重要です。この記事の執筆時点では、インタフェースの詳細な操作と交換されるオブジェクトの構造は標準化プロセス中です。^{[2] [3] [4] [5] [6] [7] [8]}定義されたインターフェースについて簡単に説明すると次のようになります。

CI は、2 つの CDN 間の相互接続を開始し、他の CDNI インターフェイスをブートストラップするように設計されています。たとえば、制御インターフェイスを使用して、ログ記録インターフェイスをブートストラップするためにログ記録サーバーのアドレスを提供したり、他のインターフェイスのセキュリティ アソシエーションを確立したりできます。また、uCDN が dCDN 上のメタデータとコンテンツを事前配置、再検証、または消去できるようにすることもできます。

特定のユーザー リクエストに対して、配信 dCDN をリダイレクトして選択します。このインターフェイスは、処理されたリクエストのループ防止および検出メカニズムを提供します。

後続のユーザー要求に対する dCDN 選択をサポートするために、機能とフットプリントに関するルーティング情報の非同期交換を有効にします。RI および FCI インターフェイスの結合は、要求インターフェイスを示します。

dCDN が uCDN からのコンテンツ メタデータを提供できるようにします。メタデータには、必要な認証、ジオブロッキング、利用可能期間、委任のホワイト リストとブラック リストに関する情報が含まれる場合があります。この情報により、たとえば、配信を特定の国に制限したり、成人向けのコンテンツを深夜のみに提供したりできます。収集されたメタデータは、後で CDNI リダイレクトやユーザー コンテンツ要求の応答に使用されます。

相互接続を介してコンテンツ配信および配信アクティビティの詳細を交換できます。リアルタイム交換はトラフィック監視に使用でき、オフライン交換はエンドユーザーへの課金や相互接続された CDN 間の課金に使用できます。

dCDN の選択には、主にフットプリントと機能に関する情報が使用されます。フットプリントは、IP サブネット、自律システム (AS) 番号、または国、州、コードの組み合わせを使用して指定できます。^[9]機能は、CDN が対応できる、または対応できない機能、サービス、状態を記述し、ネットワークと管理の機能、キャッシュとリソースに関する情報が含まれます。ネットワーク情報では、QoS またはサポートされているストリーミング帯域幅の詳細が開示される場合があります。管理機能では、確立された制限とポリシーが通知される場合があります。キャッシュに関するデータは、負荷と使用可能なリソースに関する情報を通知する場合があります。リソース情報では、特定のデバイス タイプにビデオをストリーミングする機能など、サポートされている配信テクノロジとコンテンツ タイプが指定される場合があります。

フットプリントと機能に関する情報が与えられた場合、uCDN は最初にフットプリントに基づいて、次に機能に基づいて dCDN の初期選択に進むことができます。ただし、このような手順では、最適ではない、または誤った決定につながる可能性があります。たとえば、フットプリントに基づいて dCDN を選択した場合、要求された配信テクノロジを提供できません。したがって、より承認された手順では、フットプリント情報を機能要件の一部にする必要があります。

BGPなどのフットプリント、HTTPなどの機能、またはアプリケーション層トラフィック最適化（ALTO）などのフットプリントと機能の両方に関する情報交換には、さまざまなプロトコルが検討されています。^[10]

CDN では、ユーザー リクエストのリダイレクトに、主に HTTP リダイレクトと DNS リダイレクトという 2 つのメカニズムが使用されます。

HTTP メソッドは、アクセスする新しい URL を含む HTTP リダイレクト応答 (例: 302) を使用します。新しい URL のサーバー名を変更するオプションの他に、URL には元のサーバー名を含めることができ、これによりインバンド通信の手段が提供されます。さらに、リダイレクト メカニズムは、クライアントの IP アドレス、要求されたコンテンツ タイプ、またはターゲット サロゲートの選択にユーザー エージェントの情報を使用できます。残念ながら、URL のドメインを変更すると、Web ブラウザーは Cookie を送信しなくなります。

DNS リダイレクトは、HTTP メソッドと比較すると、エンド ユーザーに対して完全に透過的です。単純な DNS リダイレクトでは、名前の権威 DNS サーバーがクライアントの特性に基づいて IP アドレスを返します。結果として返される IP アドレスは、他の要因の中でも、エンド ユーザーのローカリゼーションまたは代理サーバーの負荷によって異なります。権威サーバーが CNAME 応答を返す別の DNS リダイレクト メソッドもあります。これにより、ピアは新しい名前を使用して名前検索を再開する必要があります。キャッシュされた DNS 応答の場合にリダイレクトの鮮度を保つために、time-to-live パラメーターの適切な値が設定されます。このメソッドの欠点は、DNS キャッシュによってエンド ユーザーの IP アドレスが隠されることです。

HTTP ベースと DNS ベースの両方のリダイレクト方法は、CDNI で反復的または再帰的に実行できます。再帰リダイレクトは、UE リダイレクトが 1 つだけなのでエンド ユーザーにとってより透過的ですが、相互接続の実現には他の依存関係があります。相互接続された CDN の数が 2 を超える場合は、単一の UE リダイレクトが望ましい場合があります。

下の図に示すシーケンス図は、CDNI と反復 DNS リダイレクト操作の詳細を示しています。図示の例では、UE はアドレスcdn.csp.com/fooからコンテンツをダウンロードします。このコンテンツは主に、アドレスcsp.comを持つ CSP に代わって CDN-A によって配信されます。

1. リクエストのリダイレクトの前に、CDN-B (dCDN) はサポートされているフットプリントと機能に関する情報を発表します。
2. UE は、コンテンツをダウンロードする CSP のドメイン内のサーバーcdn.csp.comの DNS ルックアップを実行します。
3. ドメインcdn.csp.comにサービスを提供する CDN-A (uCDN) のリクエスト ルーターは、リクエストを処理し、リクエストの送信元 IP アドレスに基づいて、エンド ユーザーに dCDN の方が適していることを認識します。したがって、dCDN で照会を実行し、このリクエストを処理する意思と能力があるかどうかを判断します。
4. dCDN がリクエストを処理できる場合、uCDN のリクエスト ルーターは DNS CNAME 応答を返します。この応答には、dCDN と元のドメインを示す新しいドメイン (例: b.cdn.csp.com)と、この新しいドメインを dCDN のリクエスト ルーターにマップする NS レコードが含まれます。
5. UE は新しいドメイン ( b.cdn.csp.com )を使用して DNS ルックアップを実行します。dCDN のリクエスト ルーターは、適切な配信ノードの IP アドレスでこのリクエストに応答します。
6. UE は、dCDN の配信ノードにコンテンツ/fooを要求します。この時点で、配信ノードは UE の実際の IP アドレスと要求されたコンテンツの情報を受け取ります。前の手順でのリダイレクトが正しくなかった場合、配信ノードは HTTP リダイレクトを実行できます。
7. コンテンツ/fooのメタデータがdCDN で利用できない場合は、メタデータ インターフェイスを使用して uCDN からメタデータを要求します。
8. リクエストが処理される場合、つまりメタデータ制限が満たされ、キャッシュ ミスが発生した場合、dCDN の配信ノードは取得プロセスを開始する必要があります。配信ノードは、内部ドメイン アドレスop-b-acq.op-a.netの DNS ルックアップを実行します。uCDN は、リクエストが UE からではなく dCDN からのものであることを認識し、uCDN の配信ノードの IP アドレスを返します。
9. コンテンツ/fooは、uCDN の配信ノードから dCDN の配信ノードに配信されます。
10. コンテンツ/foo は、dCDN の配信ノードから UE に配信されます。
11. しばらくすると、uCDN は dCDN にコンテンツ/foo を削除するように指示し、再び配信されないようにすることがあります。
12. コンテンツが配信されると、配信アクションのログが uCDN に提供されます。

CDNI仕様で対処されている場合、HTTPアダプティブストリーミング（HAS）^[11]のサポートが特に実現されます。大きなオブジェクトは、チャンク間に関係がないかのように認識される、ビデオなどの一連の小さな独立したチャンクに分割されます。その結果、コンテンツの取得とチャンクの消去はチャンクごとに実行されます。CDNIの負荷を軽減するために、仕様では、相対的なUniform Resource Locator（URL）を許可するか、HAS経由で配布されるリソースのマニフェストファイル内の絶対URLを変更します。

CDNI のセキュリティはオプションであり、そのサポートは CDN の機能として導入されています。CDNI のセキュリティには、コンテンツの機密保護、認証されたピア通信、およびデータ発信元の認証が含まれます。CDN 間のリンクの信頼性が疑われる場合、データ発信元の認証は非常に重要です。セキュリティは、CDNI に展開されているプロトコルの安全なバージョン (HTTPS など) に切り替えることで強化されます。通常、CDNI が安全なプロトコルを介して確立されている場合、コンテンツの取得と配信にも安全なプロトコルが使用されます。

セキュリティに関するさらなる問題としては、異なる国間で交換されるログに関するエンドユーザーのプライバシー要件や、CDN 間での配信課金のログの信頼性などが挙げられます。セキュリティ侵害がどのような結果をもたらすかは、インターフェースとその機能によって異なります。たとえば、制御インターフェースが破損すると他のインターフェースが破損する可能性があり、ログ インターフェースが破損すると課金の不正が可能になります。

IETF、欧州電気通信標準化機構 (ETSI)、Alliance for Telecommunications Industry Solutions (ATIS)、Open ContEnt Aware Networks (OCEAN) など、多くの組織やプロジェクトが CDNI インターフェースとメソッドの標準化に取り組んできました。または現在も取り組んでいます。定義されたインターフェースと用語の仕様には、いくつかの不一致や相違点があります。

ETSI仕様^{[12] [13]}では、3つのCDNIインターフェースについて説明している。最初のインターフェースである相互接続制御は、ETSIの制御インターフェースとログインターフェースの結合にマッピングされる。次のインターフェースである要求およびコンテンツ制御は、ETSIの要求ルーティングインターフェースとメタデータインターフェースの結合にマッピングされる。3番目はコンテンツインターフェースの配布である。

OCEANフレームワークは、提案されたCDNIのオープンインターフェースとプロセスを網羅的に規定しています。^{[14] [15]}これらの文書では、追加のビジネス、取得、内部メタデータインターフェースが定義されています。さらに、ETSIによって定義されたメタデータインターフェースは、さらに2つの特殊なインターフェースに分割されており、これらを組み合わせると、9つのインターフェースを持つ参照モデルが作成されます。

有料のATIS標準と技術レポートでは、CDNIのユースケースの仕様と高レベルの要件が定義されています。無料で入手できる概要によると、これらの仕様は、他の側面の中でも、2つのCDNプロバイダーの相互接続^[16]をカバーしています。これは、 2つのCDNプロバイダー間でコンテンツを配信するための手段としてマルチキャストを使用するための基盤として^[17]、複数のCDNプロバイダーを結合してCDNフェデレーションを形成するための基盤として^{[18]です。}

• コンテンツ配信ネットワーク
• 相互接続
• 連盟（情報技術）
• 負荷分散（コンピューティング）
• 国コード
• URLリダイレクト
• CNAMEレコード
• HTTP 経由のダイナミック アダプティブ ストリーミング

• S. Puopolo、M. Latouche、F. Le Faucheur、J. Defour。コンテンツ配信ネットワーク (CDN) フェデレーション: SP がコンテンツを求める消費者獲得の戦いに勝つ方法、2011 年。
• A. Pathan および R. Buyya。コンテンツ配信ネットワークの分類と調査。技術レポート、GRIDS-TR-2007-4、グリッド コンピューティングおよび分散システム研究所、メルボルン大学、オーストラリア、2007 年 2 月。

• コンテンツ配信ネットワーク相互接続 (cdni)
• OpenCDN | CDN フェデレーション | EdgeCast
• SwiftServe - 透過的なキャッシュとコンテンツ配信ネットワーク (CDN) テクノロジー
• マルチ CDN フェデレーション | Cedexis - リアルタイムの意思決定のためのリアルタイム データ アーカイブ 2017-09-22ウェイバック マシン
• CDN 戦略ブログ、CDN ニュース、CDN 業界ニュース、コンテンツ配信ネットワーク戦略 2013-10-28 にWayback Machineでアーカイブ
• マルチ CDN とは何ですか? また、どのように機能しますか?