[要約] RFC 8008は、CDN間のリクエストルーティングに関する標準化されたセマンティクスを提供するものであり、CDNのフットプリントと機能に関する情報を交換するためのプロトコルを定義しています。このRFCの目的は、異なるCDN間でのリクエストルーティングの効率化と相互運用性の向上です。
Internet Engineering Task Force (IETF) J. Seedorf
Request for Comments: 8008 HFT Stuttgart - Univ. of Applied Sciences
Category: Standards Track J. Peterson
ISSN: 2070-1721 Neustar
S. Previdi
Cisco
R. van Brandenburg
TNO
K. Ma
Ericsson
December 2016
Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics
コンテンツ配信ネットワーク相互接続（CDNI）リクエストルーティング：フットプリントと機能のセマンティクス
Abstract
概要
This document captures the semantics of the "Footprint and Capabilities Advertisement" part of the Content Delivery Network Interconnection (CDNI) Request Routing interface, i.e., the desired meaning of "Footprint" and "Capabilities" in the CDNI context and what the "Footprint & Capabilities Advertisement interface (FCI)" offers within CDNI. The document also provides guidelines for the CDNI FCI protocol. It further defines a Base Advertisement Object, the necessary registries for capabilities and footprints, and guidelines on how these registries can be extended in the future.
このドキュメントは、コンテンツ配信ネットワーク相互接続（CDNI）リクエストルーティングインターフェイスの「フットプリントと機能のアドバタイズメント」部分のセマンティクス、つまりCDNIコンテキストでの「フットプリント」と「機能」の望ましい意味、および「フットプリントと機能機能広告インターフェイス（FCI）」はCDNI内で提供されます。このドキュメントには、CDNI FCIプロトコルのガイドラインも記載されています。さらに、ベースアドバタイズメントオブジェクト、機能とフットプリントに必要なレジストリ、およびこれらのレジストリを将来拡張する方法に関するガイドラインを定義します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これは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). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション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/rfc8008.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8008で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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 and Scope ..........................................4
1.1. Terminology ................................................5
2. Design Decisions for Footprint and Capabilities .................6
2.1. Advertising Limited Coverage ...............................6
2.2. Capabilities and Dynamic Data ..............................7
2.3. Advertisement versus Queries ...............................8
2.4. Avoiding or Handling "Cheating" dCDNs ......................8
3. Focusing on Capabilities with Footprint Restrictions ............9
4. Footprint and Capabilities Extension ............................9
5. Capability Advertisement Object ................................11
5.1. Base Advertisement Object .................................12
5.2. Encoding ..................................................12
5.3. Delivery Protocol Capability Object .......................13
5.3.1. Delivery Protocol Capability Object Serialization ..13
5.4. Acquisition Protocol Capability Object ....................14
5.4.1. Acquisition Protocol Capability Object
Serialization ......................................14
5.5. Redirection Mode Capability Object ........................15
5.5.1. Redirection Mode Capability Object Serialization ...15
5.6. CDNI Logging Capability Object ............................16
5.6.1. CDNI Logging Capability Object Serialization .......17
5.7. CDNI Metadata Capability Object ...........................18
5.7.1. CDNI Metadata Capability Object Serialization ......19
6. IANA Considerations ............................................20
6.1. CDNI Payload Types ........................................20
6.1.1. CDNI FCI DeliveryProtocol Payload Type .............20
6.1.2. CDNI FCI AcquisitionProtocol Payload Type ..........20
6.1.3. CDNI FCI RedirectionMode Payload Type ..............20
6.1.4. CDNI FCI Logging Payload Type ......................21
6.1.5. CDNI FCI Metadata Payload Type .....................21
6.2. "CDNI Capabilities Redirection Modes" Registry ............21
7. Security Considerations ........................................22
8. References .....................................................23
8.1. Normative References ......................................23
8.2. Informative References ....................................24
Appendix A. Main Use Case to Consider .............................25
Appendix B. Semantics for Footprint Advertisement .................25
Appendix C. Semantics for Capabilities Advertisement ..............27
Acknowledgments ...................................................30
Authors' Addresses ................................................30
The CDNI working group is working on a set of protocols to enable the interconnection of multiple CDNs. These CDNI protocols can serve multiple purposes, as discussed in [RFC6770] -- for instance, to extend the reach of a given CDN to areas in the network that are not covered by that particular CDN.
CDNIワーキンググループは、複数のCDNの相互接続を可能にする一連のプロトコルに取り組んでいます。これらのCDNIプロトコルは、[RFC6770]で説明されているように、複数の目的に使用できます。たとえば、特定のCDNの到達範囲を、その特定のCDNでカバーされていないネットワーク内のエリアに拡張できます。
The goal of this document is to achieve a clear understanding about the semantics associated with the CDNI Request Routing Footprint & Capabilities Advertisement interface (from now on referred to as the FCI) [RFC7336], in particular the type of information a downstream CDN (dCDN) "advertises" regarding its footprint and capabilities. To narrow down undecided aspects of these semantics, this document tries to establish a common understanding of what the FCI needs to offer and accomplish in the context of CDNI.
このドキュメントの目的は、CDNIリクエストルーティングフットプリントと機能アドバタイズメントインターフェイス（以降、FCIと呼ばれる）[RFC7336]に関連するセマンティクス、特にダウンストリームCDN（dCDN）のタイプについて明確に理解することです。 ）フットプリントと機能について「宣伝」します。これらのセマンティクスの未決定の側面を絞り込むために、このドキュメントでは、FCIがCDNIのコンテキストで提供および達成する必要のあるものについての共通の理解を確立しようとします。
Deciding on specific protocols to use for the FCI is explicitly outside the scope of this document. However, we provide guidelines for such FCI protocols.
FCIで使用する特定のプロトコルを決定することは、このドキュメントの範囲外であることは明白です。ただし、そのようなFCIプロトコルのガイドラインを提供します。
We make the following general assumptions in this document:
このドキュメントでは、次の一般的な前提を想定しています。
o The CDNs participating in the CDN interconnection have already performed a bootstrap process, i.e., they have connected to each other, either directly or indirectly, and can exchange information amongst each other.
o CDN相互接続に参加しているCDNは、すでにブートストラッププロセスを実行しています。つまり、直接または間接的に相互に接続しており、相互に情報を交換できます。
o The upstream CDN (uCDN) receives footprint advertisements and/or capability advertisements from a set of dCDNs. Footprint advertisements and capability advertisements need not use the same underlying protocol.
o アップストリームCDN（uCDN）は、一連のdCDNからフットプリント広告および/または機能広告を受信します。フットプリントアドバタイズメントと機能アドバタイズメントは、同じ基本プロトコルを使用する必要はありません。
o The uCDN receives the initial Request Routing message from the endpoint requesting the resource.
o uCDNは、リソースを要求するエンドポイントから初期要求ルーティングメッセージを受信します。
The CDNI problem statement [RFC6707] describes the Request Routing interface as "[enabling] a Request Routing function in an Upstream CDN to query a Request Routing function in a Downstream CDN to determine if the Downstream CDN is able (and willing) to accept the delegated Content Request." In addition, [RFC6707] says "the CDNI Request Routing interface is also expected to enable a Downstream CDN to provide to the Upstream CDN (static or dynamic) information (e.g., resources, footprint, load) to facilitate selection of the Downstream CDN by the Upstream CDN Request Routing system when processing subsequent Content Requests from User Agents." It thus considers "resources" and "load" as capabilities to be advertised by the dCDN.
CDNI問題ステートメント[RFC6707]は、要求ルーティングインターフェイスを「[有効化]アップストリームCDNの要求ルーティング関数がダウンストリームCDNの要求ルーティング関数にクエリして、ダウンストリームCDNが委任されたコンテンツ要求。」さらに、[RFC6707]は、「CDNIリクエストルーティングインターフェイスは、ダウンストリームCDNがアップストリームCDN（静的または動的）情報（リソース、フットプリント、負荷など）に提供して、ダウンストリームCDNの選択を容易にすることも期待されています。ユーザーエージェントからの後続のコンテンツ要求を処理するときのアップストリームCDN要求ルーティングシステム。」したがって、「リソース」と「ロード」は、dCDNによってアドバタイズされる機能と見なされます。
The range of different footprint definitions and possible capabilities is very broad. Attempting to define a comprehensive advertisement solution quickly becomes intractable. The CDNI requirements document [RFC7337] lists the specific requirements for the CDNI FCI in order to disambiguate footprints and capabilities with respect to CDNI. This document defines a common understanding of what the terms "footprint" and "capabilities" mean in the context of CDNI and details the semantics of the footprint advertisement mechanism and the capability advertisement mechanism.
さまざまなフットプリントの定義と可能な機能の範囲は非常に広いです。包括的な広告ソリューションを定義しようとすると、すぐに手に負えなくなります。 CDNI要件ドキュメント[RFC7337]には、CDNIに関するフットプリントと機能を明確にするためのCDNI FCIの特定の要件がリストされています。このドキュメントでは、CDNIのコンテキストで「フットプリント」と「機能」という用語が何を意味するかについての一般的な理解を定義し、フットプリント広告メカニズムと機能広告メカニズムのセマンティクスについて詳しく説明します。
This document reuses the terminology defined in [RFC6707].
このドキュメントは、[RFC6707]で定義された用語を再利用します。
Additionally, the following terms are used throughout this document and are defined as follows:
さらに、このドキュメント全体で次の用語が使用され、次のように定義されています。
o Footprint: a description of a CDN's coverage area, i.e., the area from which client requests may originate for content and to which the CDN is willing to deliver content. Note: There are many ways to describe a footprint -- for example, by address range (e.g., IPv4 CIDR or IPv6 CIDR (Classless Inter-Domain Routing), network ID (e.g., Autonomous System Number (ASN)), nation boundaries (e.g., country code), or GPS coordinates. This document does not define or endorse the quality or suitability of any particular footprint description method; rather, it only defines a method for transporting known footprint descriptions in Footprint and Capabilities Advertisement messages.
o フットプリント：CDNのカバレッジエリアの説明、つまり、クライアントの要求がコンテンツを発信する可能性があり、CDNがコンテンツを配信する用意があるエリア。注：フットプリントを説明する方法は多数あります。たとえば、アドレス範囲（IPv4 CIDRまたはIPv6 CIDR（クラスレスドメイン間ルーティング）、ネットワークID（自律システム番号（ASN）など）、国境（たとえば、国コード）、またはGPS座標。このドキュメントは、特定のフットプリント記述方法の品質または適合性を定義または承認するのではなく、フットプリントおよび機能広告メッセージで既知のフットプリント記述を転送する方法のみを定義します。
o Capability: a feature of a dCDN upon whose support a uCDN relies when making delegation decisions. Support for a given feature can change over time and can be restricted to a limited portion of a dCDN's footprint. Note: There are many possible dCDN features that could be of interest to a uCDN. This document does not presume to define them all; rather, it describes a scheme for defining new capabilities and how to transport them in Footprint and Capabilities Advertisement messages.
o 機能：委任の決定を行うときにuCDNのサポートに依存するdCDNの機能。特定の機能のサポートは時間の経過とともに変化し、dCDNのフットプリントの限られた部分に制限される場合があります。注：uCDNに関連する可能性のある多くの可能なdCDN機能があります。このドキュメントでは、それらすべてを定義することを想定していません。むしろ、新しい機能を定義するためのスキームと、それらをFootprint and Capabilities Advertisementメッセージで転送する方法について説明しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
A large part of the difficulty in discussing the FCI lies in understanding what exactly is meant when trying to define a footprint in terms of "coverage" or "reachability". While the operators of CDNs pick strategic locations to situate Surrogates, a Surrogate with a public IPv4 address is reachable by any endpoint on the Internet, unless some policy enforcement precludes the use of the Surrogate.
FCIの説明における困難の大部分は、「カバレッジ」または「到達可能性」の観点からフットプリントを定義しようとするときに正確に何が意味されるかを理解することにあります。 CDNの事業者は代理を配置するために戦略的な場所を選択しますが、ポリシーの施行により代理の使用が禁止されていない限り、パブリックIPv4アドレスを持つ代理はインターネット上の任意のエンドポイントから到達可能です。
Some CDNs aspire to cover the entire world; we refer to these as global CDNs. The footprint advertised by such a CDN in the CDNI environment would, from a coverage or reachability perspective, presumably cover all prefixes. Potentially more interesting for CDNI use cases, however, are CDNs that claim a more limited coverage area but seek to interconnect with other CDNs in order to create a single CDN fabric that shares resources.
一部のCDNは全世界をカバーすることを目指しています。これらをグローバルCDNと呼びます。 CDNI環境でこのようなCDNによってアドバタイズされるフットプリントは、カバレッジまたは到達可能性の観点から、おそらくすべてのプレフィックスをカバーします。ただし、CDNIのユースケースにとって潜在的に興味深いのは、より限定的なカバレッジエリアを主張しながら、リソースを共有する単一のCDNファブリックを作成するために他のCDNと相互接続することを求めるCDNです。
Furthermore, not all capabilities need to be footprint-restricted. Depending upon the use case, the optimal semantics of "footprints with capability attributes" vs. "capabilities with footprint restrictions" are not clear.
さらに、すべての機能をフットプリントに制限する必要はありません。ユースケースによっては、「機能属性を持つフットプリント」と「フットプリント制限を持つ機能」の最適なセマンティクスが明確ではありません。
The key to understanding the semantics of footprint advertisements and capability advertisements lies in understanding why a dCDN would advertise a limited coverage area and how a uCDN would use such advertisements to decide among one of several dCDNs. The following section will discuss some of the trade-offs and design decisions that need to be made for the CDNI FCI.
フットプリント広告と機能広告のセマンティクスを理解する鍵は、dCDNが限られたカバレッジエリアをアドバタイズする理由と、uCDNがそのような広告を使用していくつかのdCDNの1つを決定する方法を理解することです。次のセクションでは、CDNI FCIに必要なトレードオフと設計上の決定について説明します。
The basic use case that would motivate a dCDN to advertise limited coverage is that the CDN was built to cover only a particular portion of the Internet. For example, an ISP could purpose-build a CDN to serve only their own customers by situating Surrogates in close topological proximity to high concentrations of their subscribers. The ISP knows the prefixes it has allocated to end users and thus can easily construct a list of prefixes that its Surrogates were positioned to serve.
dCDNが限定的なカバレッジを宣伝する動機となる基本的な使用例は、CDNがインターネットの特定の部分のみをカバーするように構築されていることです。たとえば、ISPは、サロゲートをトポロジの近くで、加入者が集中している場所に配置することにより、自分の顧客のみにサービスを提供するCDNを目的に構築できます。 ISPは、エンドユーザーに割り当てたプレフィックスを知っているため、サロゲートが提供するように配置されたプレフィックスのリストを簡単に作成できます。
When such a purpose-built CDN interconnects with other CDNs and advertises its footprint to a uCDN, however, the original intended coverage of the CDN might not represent its actual value to the interconnection of CDNs. Consider an ISP-A and ISP-B that both field their own CDNs, which they interconnect via CDNI. A given user E, who is a customer of ISP-B, might happen to be topologically closer to a Surrogate fielded by ISP-A, if E happens to live in a region where ISP-B has few customers and ISP-A has many. In this case, is it ISP-A's CDN that "covers" E? If ISP-B's CDN has a failure condition, is it up to the uCDN to understand that ISP-A's Surrogates are potentially available as backups, and if so, how does ISP-A advertise itself as a "standby" for E? What about the case where CDNs advertising to the same uCDN express overlapping coverage (for example, mixing global and limited CDNs)?
ただし、そのような専用のCDNが他のCDNと相互接続し、そのフットプリントをuCDNにアドバタイズする場合、CDNの当初の意図されたカバレッジは、CDNの相互接続に対する実際の価値を表さない場合があります。 CDNIを介して相互接続する独自のCDNを処理するISP-AとISP-Bについて考えてみます。 ISP-Bの顧客が少なく、ISP-Aの顧客が多い地域にEが住んでいる場合、ISP-Bの顧客である特定のユーザーEは、トポロジー的にISP-Aが配置する代理に近い可能性があります。 。この場合、Eを「カバー」するのはISP-AのCDNですか？ ISP-BのCDNに障害状態がある場合、ISP-Aのサロゲートがバックアップとして潜在的に利用可能であることを理解するのはuCDNの責任であり、その場合、ISP-AはEの「スタンバイ」としてそれ自体をどのようにアドバタイズしますか？同じuCDNにアドバタイズするCDNが重複するカバレッジを表現する場合はどうですか（たとえば、グローバルCDNと制限付きCDNの混在）。
The answers to these questions greatly depend on how much information the uCDN wants to use to select a dCDN. If a uCDN has three dCDNs to choose from that "cover" the IP address of user E, obviously the uCDN might be interested in knowing how optimal the coverage is from each of the dCDNs. Coverage need not be binary (i.e., either provided or not provided); dCDNs could advertise a coverage "score", for example, and provided that they all reported scores fairly on the same scale, uCDNs could use that information to make their topological optimality decision. Alternately, dCDNs could advertise the IP addresses of their Surrogates rather than prefix "coverage" and let the uCDN decide for itself (based on its own topological intelligence) which dCDN has better resources to serve a given user.
これらの質問に対する答えは、uCDNがdCDNを選択するために使用する情報の量に大きく依存します。 uCDNにユーザーEのIPアドレスを「カバー」するために選択する3つのdCDNがある場合、uCDNは、各dCDNからのカバレッジがどの程度最適かを知ることに関心がある可能性があります。カバレッジはバイナリである必要はありません（つまり、提供されるか提供されないかのどちらか）;たとえば、dCDNはカバレッジの「スコア」をアドバタイズし、すべてが同じスケールで公平にスコアを報告した場合、uCDNはその情報を使用してトポロジーの最適性を決定できます。代わりに、dCDNは接頭辞「カバレッジ」ではなくサロゲートのIPアドレスをアドバタイズし、uCDNに（独自のトポロジインテリジェンスに基づいて）与えられたユーザーにサービスを提供するためのより良いリソースを決定することができます。
In summary, the semantics of advertising a footprint depend on whether (1) such qualitative metrics for expressing a footprint (such as the coverage "score" mentioned above) are included as part of the CDNI FCI or (2) the focus is just on a "binary" footprint.
要約すると、フットプリントをアドバタイズするセマンティクスは、（1）フットプリントを表現するためのそのような定性的メトリック（上記のカバレッジ「スコア」など）がCDNI FCIの一部として含まれているか、または（2）フォーカスがちょうど「バイナリ」フットプリント。
In cases where the apparent footprints of dCDNs overlap, uCDNs might also want to rely on other factors to evaluate the respective merits of dCDNs. These include facts related to the Surrogates themselves, the network where the Surrogate is deployed, the nature of the resource sought, and the administrative policies of the respective networks.
dCDNの明らかなフットプリントが重複している場合、uCDNは、dCDNのそれぞれのメリットを評価するために他の要因に依存することもできます。これらには、代理人自体、代理人が配置されているネットワーク、求められるリソースの性質、および各ネットワークの管理ポリシーに関連する事実が含まれます。
In the absence of network-layer impediments to reaching Surrogates, the choice to limit coverage is, by necessity, an administrative policy. Much policy needs to be agreed upon before CDNs can interconnect, including questions of membership, compensation, volumes, and so on. A uCDN certainly will factor these sorts of considerations into its decision to select a dCDN, but there is probably little need for dCDNs to actually advertise them through an interface -- they will be settled out-of-band as a precondition for interconnection.
サロゲートへの到達に対するネットワーク層の障害がない場合、カバレッジを制限する選択は、必然的に、管理ポリシーになります。メンバーシップ、報酬、ボリュームなどの質問を含む、CDNが相互接続する前に、多くのポリシーについて合意する必要があります。 uCDNは確かにこれらの種類の考慮事項を考慮してdCDNを選択することを決定しますが、dCDNがインターフェースを介して実際にアドバタイズする必要はおそらくありません-相互接続の前提条件として帯域外で解決されます。
Other facts about the dCDN would be expressed through the interface to the uCDN. Some capabilities of a dCDN are static, and some are highly dynamic. Expressing the total storage built into its Surrogates, for example, changes relatively rarely, whereas the amount of storage in use at any given moment is highly volatile. Network bandwidth similarly could be expressed either as total bandwidth available to a Surrogate or based on the current state of the network. A Surrogate can at one moment lack a particular resource in storage but have it the next.
dCDNに関するその他の事実は、uCDNへのインターフェースを通じて表現されます。 dCDNの一部の機能は静的であり、一部は非常に動的です。たとえば、サロゲートに組み込まれているストレージの合計を表すことは比較的まれですが、特定の瞬間に使用されているストレージの量は非常に不安定です。同様に、ネットワーク帯域幅は、サロゲートで使用可能な合計帯域幅として、またはネットワークの現在の状態に基づいて表現できます。サロゲートは、ストレージに特定のリソースが不足している場合がありますが、次のリソースがあります。
The semantics of the capabilities interface will depend on how much of the dCDN state needs to be pushed to the uCDN and, qualitatively, how often that information needs to be updated.
機能インターフェースのセマンティクスは、どれだけのdCDN状態をuCDNにプッシュする必要があるか、そして定性的には、その情報を更新する必要がある頻度に依存します。
In a CDNI environment, each dCDN shares some of its state with the uCDN. The uCDN uses this information to build a unified picture of all of the dCDNs available to it. In architectures that share detailed capability information, the uCDN could perform the entire Request Routing operation down to selecting a particular Surrogate in the dCDN. However, when the uCDN needs to deal with many potential dCDNs, this approach does not scale, especially for dCDNs with thousands or tens of thousands of Surrogates; the volume of updates to the footprint and the capability information becomes onerous.
CDNI環境では、各dCDNはその状態の一部をuCDNと共有します。 uCDNはこの情報を使用して、利用可能なすべてのdCDNの統一された状況を構築します。詳細な機能情報を共有するアーキテクチャでは、uCDNはリクエストルーティング操作全体を実行して、dCDNの特定のサロゲートを選択できます。ただし、uCDNが多くの潜在的なdCDNを処理する必要がある場合、このアプローチはスケーリングしません。特に、数千または数万のサロゲートを持つdCDNの場合はそうではありません。フットプリントと機能情報の更新量が面倒になります。
Were the volume of FCI updates from dCDNs to exceed the volume of requests to the uCDN, it might make more sense for the uCDN to query dCDNs upon receiving requests (as is the case in the recursive redirection mode described in [RFC7336]), instead of receiving advertisements and tracking the state of dCDNs. The advantage of querying dCDNs would be that much of the dynamic data that dCDNs cannot share with the uCDN would now be factored into the uCDN's decision. dCDNs need not replicate any state to the uCDN -- uCDNs could effectively operate in a stateless mode.
dCDNからのFCI更新の量がuCDNへの要求の量を超えると、代わりにuCDNが要求を受信したときにdCDNをクエリする方が理にかなっている可能性があります（[RFC7336]で説明されている再帰リダイレクトモードの場合と同様）。広告を受け取り、dCDNの状態を追跡する。 dCDNを照会することの利点は、dCDNがuCDNと共有できない動的データの多くが、uCDNの決定に考慮されるようになることです。 dCDNは状態をuCDNに複製する必要はありません-uCDNはステートレスモードで効果的に動作できます。
The semantics of both footprint advertisements and capability advertisements depend on the service model here: are there cases where a synchronous query/response model would work better for the uCDN decision than a state replication model?
フットプリントアドバタイズメントと機能アドバタイズメントの両方のセマンティクスは、ここでのサービスモデルに依存します。同期クエリ/応答モデルが状態レプリケーションモデルよりもuCDN決定に適しているケースはありますか？
In a situation where more than one dCDN is willing to serve a given end user request, it might be attractive for a dCDN to "cheat" in the sense that the dCDN provides inaccurate information to the uCDN in order to convince the uCDN to select it over "competing" dCDNs. It could therefore be desirable to take away the incentive for dCDNs to cheat (in information advertised) as much as possible. One option is to make the information the dCDN advertises somehow verifiable for the uCDN. On the other hand, a "cheating" dCDN might be avoided or handled by the fact that there will be strong contractual agreements between a uCDN and a dCDN, so that a dCDN would risk severe penalties or legal consequences when caught cheating.
複数のdCDNが特定のエンドユーザー要求に対応する用意がある状況では、dCDNが不正確な情報をuCDNに提供してuCDNに選択を説得するという意味で、dCDNが「チート」するのは魅力的です。 「競合する」dCDNについて。したがって、dCDNが（宣伝されている情報で）不正行為をするインセンティブをできるだけ取り除くことが望ましいかもしれません。 1つのオプションは、dCDNがアドバタイズする情報を何らかの方法でuCDNについて検証可能にすることです。一方、「不正行為」dCDNは、uCDNとdCDNの間に強力な契約上の合意があるために回避または処理される可能性があるため、dCDNは不正行為を見つけた場合に重大なペナルティまたは法的責任を負う可能性があります。
Overall, the information a dCDN advertises (in the long run) needs to be somehow qualitatively verifiable by the uCDN, though possibly through non-real-time out-of-band audits. It is probably an overly strict requirement to mandate that such verification be possible "immediately", i.e., during the Request Routing process itself. If the uCDN can detect a cheating dCDN at a later stage, it might suffice for the uCDN to "de-incentivize" cheating because it would negatively affect the long-term business relationship with a particular dCDN.
全体として、dCDNが（長期的に）アドバタイズする情報は、おそらく非リアルタイムの帯域外監査を通じて、uCDNによって何らかの形で質的に検証可能である必要があります。そのような検証が「すぐに」、つまり要求ルーティングプロセス自体の間に可能であることを義務付けることは、おそらく過度に厳格な要件です。 uCDNが不正なdCDNを後の段階で検出できる場合、特定のdCDNとの長期的なビジネス関係に悪影響を及ぼすため、uCDNが不正を「非インセンティブ化」するだけで十分な場合があります。
Given the design considerations listed in the previous section, it seems reasonable to assume that in most cases it is the uCDN that makes the decision to select a certain dCDN for Request Routing based on information the uCDN has received from this particular dCDN. It can be assumed that cheating dCDNs will be dealt with via means outside the scope of CDNI and that the information advertised between CDNs is accurate. In addition, excluding the use of qualitative information (e.g., Surrogate proximity, delivery latency, Surrogate load) to predict the quality of delivery would further simplify the use case, allowing it to better focus on the basic functionality of the FCI.
前のセクションに記載されている設計上の考慮事項を考慮すると、ほとんどの場合、uCDNがこの特定のdCDNから受け取った情報に基づいて、要求ルーティング用の特定のdCDNを選択する決定を下すのはuCDNであると想定するのは妥当なようです。不正なdCDNはCDNIの範囲外の手段で処理され、CDN間でアドバタイズされる情報は正確であると想定できます。さらに、配信の品質を予測するために定性的な情報（サロゲート近接、配信レイテンシ、サロゲート負荷など）の使用を除外すると、ユースケースがさらに簡素化され、FCIの基本機能にさらに集中できるようになります。
Furthermore, understanding that in most cases contractual agreements will define the basic coverage used in delegation decisions, the primary focus of the FCI is on providing updates to the basic capabilities and coverage by the dCDNs. As such, the FCI has chosen the semantics of "capabilities with footprint restrictions".
さらに、ほとんどの場合、契約上の合意が委任決定で使用される基本的なカバレッジを定義することを理解すると、FCIの主な焦点は、dCDNによる基本的な機能とカバレッジの更新を提供することです。そのため、FCIは「フットプリント制限のある機能」のセマンティクスを選択しました。
Other optional "coverage/reachability" footprint types or "resource" footprint types may be defined by future specifications. To facilitate this, a clear process for specifying optional footprint types in an IANA registry is specified in the "CDNI Metadata Footprint Types" registry (defined in the CDNI Metadata interface document [RFC8006]).
その他のオプションの「カバレッジ/到達可能性」フットプリントタイプまたは「リソース」フットプリントタイプは、将来の仕様で定義される可能性があります。これを容易にするために、IANAレジストリでオプションのフットプリントタイプを指定する明確なプロセスが、「CDNIメタデータフットプリントタイプ」レジストリ（CDNIメタデータインターフェースドキュメント[RFC8006]で定義）で指定されています。
This document also registers CDNI Payload Types [RFC7736] for the initial capability types (see Section 6):
このドキュメントでは、初期機能タイプのCDNIペイロードタイプ[RFC7736]も登録しています（セクション6を参照）。
o Delivery Protocol (for delivering content to the end user)
o 配信プロトコル（コンテンツをエンドユーザーに配信するため）
o Acquisition Protocol (for acquiring content from the uCDN or origin server)
o 取得プロトコル（uCDNまたはオリジンサーバーからコンテンツを取得するため）
o Redirection Mode (e.g., DNS redirection vs. HTTP redirection as discussed in [RFC7336])
o リダイレクションモード（[RFC7336]で説明されているDNSリダイレクションとHTTPリダイレクションなど）
o CDNI Logging (i.e., supported CDNI Logging fields)
o CDNI Logging（つまり、サポートされているCDNI Loggingフィールド）
o CDNI Metadata (i.e., supported GenericMetadata types)
o CDNIメタデータ（つまり、サポートされているGenericMetadataタイプ）
Each Payload Type is prefaced with "FCI.". Updates to capability objects MUST indicate the version of the capability object in a newly registered Payload Type, e.g., by appending ".v2". Each capability type MAY have a list of valid values. Future specifications that define a given capability MUST define any necessary registries (and the rules for adding new entries to the registry) for the values advertised for a given capability type.
各ペイロードタイプは「FCI。」で始まります。機能オブジェクトの更新は、新しく登録されたペイロードタイプの機能オブジェクトのバージョンを、たとえば「.v2」を追加することによって示す必要があります。各機能タイプには、有効な値のリストが含まれる場合があります。特定の機能を定義する将来の仕様では、特定の機能タイプでアドバタイズされる値に対して必要なレジストリ（およびレジストリに新しいエントリを追加するためのルール）を定義する必要があります。
The "CDNI Logging record-types" registry [RFC7937] defines all known record-types, including "mandatory-to-implement" record-types. Advertising support for mandatory-to-implement record-types would be redundant. CDNs SHOULD NOT advertise support for mandatory-to-implement record-types.
「CDNI Logging record-types」レジストリ[RFC7937]は、「実装が必須」のレコードタイプを含む、すべての既知のレコードタイプを定義します。必須から実装へのレコードタイプの広告サポートは冗長になります。 CDNは、必須から実装へのレコードタイプのサポートをアドバタイズすべきではありません（SHOULD NOT）。
The "CDNI Logging Field Names" registry [RFC7937] defines all known CDNI Logging fields. CDNI Logging fields may be reused by different record-types and be mandatory-to-implement in some record-types, but they may be optional in other record-types. CDNs MUST advertise support for optional CDNI Logging fields within the context of a specific record-type. For a given record-type, CDNs SHOULD NOT advertise support for mandatory-to-implement CDNI Logging fields. The following CDNI Logging fields are defined as optional for the "cdni_http_request_v1" record-type [RFC7937]:
「CDNI Logging Field Names」レジストリ[RFC7937]は、すべての既知のCDNI Loggingフィールドを定義します。 CDNI Loggingフィールドは、さまざまなレコードタイプで再利用でき、一部のレコードタイプでは実装が必須ですが、他のレコードタイプではオプションである場合があります。 CDNは、特定のレコードタイプのコンテキスト内でオプションのCDNIログフィールドのサポートを通知する必要があります。特定のレコードタイプについて、CDNは、必須から実装へのCDNIログフィールドのサポートをアドバタイズすべきではありません（SHOULD NOT）。次のCDNI Loggingフィールドは、 "cdni_http_request_v1"レコードタイプ[RFC7937]のオプションとして定義されています。
o s-ccid
o s-ccid
o s-sid
o s-sid
[RFC8006] requires that CDNs be able to parse all the defined metadata objects but does not require dCDNs to support enforcement of non-structural GenericMetadata objects. Advertising support for "mandatory-to-enforce" GenericMetadata types MUST be provided. Advertising support for non-mandatory-to-enforce GenericMetadata types SHOULD be provided. Advertisement of non-mandatory-to-enforce GenericMetadata MAY be necessary, e.g., to signal temporary outages and subsequent recovery. It is expected that structural metadata will be supported at all times.
[RFC8006]では、CDNが定義済みのすべてのメタデータオブジェクトを解析できる必要がありますが、非構造的なGenericMetadataオブジェクトの適用をサポートするためにdCDNは必要ありません。 「強制する」GenericMetadataタイプの広告サポートを提供する必要があります。 GenericMetadataタイプを強制する必要のない広告サポートを提供する必要があります。強制的なGenericMetadataの適用の通知は、たとえば、一時的な停止とその後の回復を知らせるために必要になる場合があります。構造メタデータは常にサポートされることが期待されています。
The notion of optional footprint types and capability types implies that certain implementations might not support all kinds of footprints and capabilities. Therefore, any FCI solution protocol MUST define how the support for optional footprint types and capability types will be negotiated between a uCDN and a dCDN that use the particular FCI protocol. In particular, any FCI solution protocol MUST specify how to handle failure cases or non-supported footprint or capability types.
オプションのフットプリントタイプと機能タイプの概念は、特定の実装がすべての種類のフットプリントと機能をサポートしない可能性があることを意味します。したがって、どのFCIソリューションプロトコルでも、特定のFCIプロトコルを使用するuCDNとdCDNの間で、オプションのフットプリントタイプと機能タイプのサポートをネゴシエートする方法を定義する必要があります。特に、すべてのFCIソリューションプロトコルは、障害ケースまたはサポートされていないフットプリントまたは機能タイプの処理方法を指定する必要があります。
In general, a uCDN MAY ignore capabilities or footprint types it does not understand; in this case, it only selects a suitable dCDN based on the types of capabilities and footprints it understands. Similarly, if a dCDN does not use an optional capability or footprint that is, however, supported by a uCDN, this causes no problem for FCI functionality because the uCDN decides on the remaining capabilities/footprint information that is being conveyed by the dCDN.
一般に、uCDNは理解できない機能またはフットプリントタイプを無視する場合があります。この場合、理解できる機能のタイプとフットプリントに基づいて、適切なdCDNのみを選択します。同様に、dCDNがオプションの機能またはフットプリントを使用しない場合でも、uCDNでサポートされている場合、uCDNがdCDNによって伝えられる残りの機能/フットプリント情報を決定するため、FCI機能に問題はありません。
To support extensibility, the FCI defines a generic base object (similar to the CDNI Metadata interface GenericMetadata object) [RFC8006] to facilitate a uniform set of mandatory parsing requirements for all future FCI objects.
拡張性をサポートするために、FCIは汎用ベースオブジェクト（CDNIメタデータインターフェイスGenericMetadataオブジェクトに類似）[RFC8006]を定義して、将来のすべてのFCIオブジェクトの必須の解析要件の統一されたセットを容易にします。
Future object definitions (e.g., regarding the CDNI Metadata or CDNI Logging interfaces) will build off the base object defined here but will be specified in separate documents.
将来のオブジェクト定義（たとえば、CDNIメタデータまたはCDNIロギングインターフェイスに関する）は、ここで定義された基本オブジェクトを基に構築されますが、個別のドキュメントで指定されます。
Note: In the following sections, the term "mandatory-to-specify" is used to convey which properties MUST be included when serializing a given capability object. When mandatory-to-specify is defined as "Yes" for an individual property, it means that if the object containing that property is included in an FCI message, then the mandatory-to-specify property MUST also be included.
注：次のセクションでは、「指定が必須」という用語は、特定の機能オブジェクトをシリアル化するときにどのプロパティを含める必要があるかを示すために使用されます。個別に指定する必要があるプロパティが「はい」として定義されている場合、そのプロパティを含むオブジェクトがFCIメッセージに含まれている場合、指定する必要があるプロパティも含める必要があります。
The FCIBase object is an abstraction for managing individual CDNI capabilities in an opaque manner.
FCIBaseオブジェクトは、個々のCDNI機能を不透明な方法で管理するための抽象概念です。
Property: capability-type
プロパティ：機能タイプ
Description: CDNI capability object type.
説明：CDNI機能オブジェクトタイプ。
Type: FCI-specific CDNI Payload Type (from the "CDNI Payload Types" registry [RFC7736])
タイプ：FCI固有のCDNIペイロードタイプ（「CDNIペイロードタイプ」レジストリ[RFC7736]から）
Mandatory-to-Specify: Yes.
指定が必須：はい。
Property: capability-value
プロパティ：能力値
Description: CDNI capability object.
説明：CDNI機能オブジェクト。
Type: Format/Type is defined by the value of the capability-type property above
タイプ：形式/タイプは、上記のケーパビリティタイププロパティの値によって定義されます
Mandatory-to-Specify: Yes.
指定が必須：はい。
Property: footprints
プロパティ：フットプリント
Description: CDNI capability footprint.
説明：CDNI機能のフットプリント。
Type: List of CDNI Footprint objects (from the "CDNI Metadata Footprint Types" registry [RFC8006])
タイプ：CDNIフットプリントオブジェクトのリスト（「CDNIメタデータフットプリントタイプ」レジストリ[RFC8006]から）
Mandatory-to-Specify: No.
指定が必須：いいえ。
CDNI FCI objects MUST be encoded using JSON [RFC7159] and MUST also follow the recommendations of I-JSON (Internet JSON) [RFC7493]. FCI objects are composed of a dictionary of (key,value) pairs where the keys are the property names and the values are the associated property values.
CDNI FCIオブジェクトはJSON [RFC7159]を使用してエンコードする必要があり、またI-JSON（インターネットJSON）[RFC7493]の推奨事項に従う必要があります。 FCIオブジェクトは、（キー、値）ペアのディクショナリで構成されます。キーはプロパティ名で、値は関連するプロパティ値です。
The keys of the dictionary are the names of the properties associated with the object and are therefore dependent on the specific object being encoded (i.e., dependent on the CDNI Payload Type of the capability or the CDNI Metadata Footprint Type of the footprint). Likewise, the values associated with each property (dictionary key) are dependent on the specific object being encoded (i.e., dependent on the CDNI Payload Type of the capability or the CDNI Metadata Footprint Type of the footprint).
ディクショナリのキーは、オブジェクトに関連付けられたプロパティの名前であるため、エンコードされる特定のオブジェクトに依存します（つまり、機能のCDNIペイロードタイプまたはフットプリントのCDNIメタデータフットプリントタイプに依存します）。同様に、各プロパティ（辞書キー）に関連付けられた値は、エンコードされる特定のオブジェクトに依存します（つまり、機能のCDNIペイロードタイプまたはフットプリントのCDNIメタデータフットプリントタイプに依存します）。
Dictionary keys (properties) in JSON are case sensitive. By convention, any dictionary key (property) defined by this document MUST be lowercase.
JSONの辞書キー（プロパティ）は大文字と小文字を区別します。慣例により、このドキュメントで定義されている辞書キー（プロパティ）はすべて小文字でなければなりません。
The Delivery Protocol capability object is used to indicate support for one or more of the protocols listed in the "CDNI Metadata Protocol Types" registry (defined in [RFC8006]).
Delivery Protocol機能オブジェクトは、「CDNI Metadata Protocol Types」レジストリ（[RFC8006]で定義）にリストされている1つ以上のプロトコルのサポートを示すために使用されます。
Property: delivery-protocols
プロパティ：配信プロトコル
Description: List of supported CDNI delivery protocols.
説明：サポートされているCDNI配信プロトコルのリスト。
Type: List of protocol types (from the "CDNI Metadata Protocol Types" registry [RFC8006])
タイプ：プロトコルタイプのリスト（「CDNIメタデータプロトコルタイプ」レジストリ[RFC8006]から）
Mandatory-to-Specify: Yes.
指定が必須：はい。
The following shows an example of Delivery Protocol capability object serialization for a CDN that supports only HTTP/1.1 without Transport Layer Security (TLS) for content delivery.
以下は、コンテンツ配信用のトランスポート層セキュリティ（TLS）なしでHTTP / 1.1のみをサポートするCDNの配信プロトコル機能オブジェクトのシリアル化の例を示しています。
{
"capabilities": [
{
"capability-type": "FCI.DeliveryProtocol",
"capability-value": {
"delivery-protocols": [
"http/1.1",
]
},
"footprints": [
<Footprint objects>
]
}
]
}
The Acquisition Protocol capability object is used to indicate support for one or more of the protocols listed in the "CDNI Metadata Protocol Types" registry (defined in [RFC8006]).
Acquisition Protocol機能オブジェクトは、「CDNI Metadata Protocol Types」レジストリ（[RFC8006]で定義）にリストされている1つ以上のプロトコルのサポートを示すために使用されます。
Property: acquisition-protocols
プロパティ：取得プロトコル
Description: List of supported CDNI acquisition protocols.
説明：サポートされているCDNI取得プロトコルのリスト。
Type: List of protocol types (from the "CDNI Metadata Protocol Types" registry [RFC8006])
タイプ：プロトコルタイプのリスト（「CDNIメタデータプロトコルタイプ」レジストリ[RFC8006]から）
Mandatory-to-Specify: Yes.
指定が必須：はい。
The following shows an example of Acquisition Protocol capability object serialization for a CDN that supports HTTP/1.1 with or without TLS for content acquisition.
以下は、コンテンツ取得のためにTLSの有無にかかわらずHTTP / 1.1をサポートするCDNのAcquisition Protocol機能オブジェクトのシリアル化の例を示しています。
{
"capabilities": [
{
"capability-type": "FCI.AcquisitionProtocol",
"capability-value": {
"acquisition-protocols": [
"http/1.1",
"https/1.1"
]
},
"footprints": [
<Footprint objects>
]
}
]
}
The Redirection Mode capability object is used to indicate support for one or more of the modes listed in the "CDNI Capabilities Redirection Modes" registry (see Section 6.2).
リダイレクトモード機能オブジェクトは、「CDNI機能リダイレクトモード」レジストリ（セクション6.2を参照）にリストされているモードの1つ以上のサポートを示すために使用されます。
Property: redirection-modes
プロパティ：redirection-modes
Description: List of supported CDNI redirection modes.
説明：サポートされているCDNIリダイレクションモードのリスト。
Type: List of redirection modes (from the "CDNI Capabilities Redirection Modes" registry, defined in Section 6.2)
タイプ：リダイレクトモードのリスト（セクション6.2で定義された「CDNI機能リダイレクトモード」レジストリから）
Mandatory-to-Specify: Yes.
指定が必須：はい。
The following shows an example of Redirection Mode capability object serialization for a CDN that supports only iterative (i.e., not recursive) redirection with HTTP and DNS.
以下は、HTTPおよびDNSを使用した反復（つまり、再帰的ではない）リダイレクトのみをサポートするCDNのリダイレクトモード機能オブジェクトのシリアル化の例を示しています。
{
"capabilities": [
{
"capability-type": "FCI.RedirectionMode",
"capability-value": {
"redirection-modes": [
"DNS-I",
"HTTP-I"
]
}
"footprints": [
<Footprint objects>
]
}
]
}
The CDNI Logging capability object is used to indicate support for CDNI Logging record-types, as well as CDNI Logging fields that are marked as optional for the specified record-types [RFC7937].
CDNI Logging機能オブジェクトは、CDNI Loggingレコードタイプのサポート、および指定されたレコードタイプのオプションとしてマークされているCDNI Loggingフィールド[RFC7937]のサポートを示すために使用されます。
Property: record-type
プロパティ：レコードタイプ
Description: Supported CDNI Logging record-type.
説明：サポートされているCDNI Loggingレコードタイプ。
Type: String corresponding to an entry from the "CDNI Logging record-types" registry [RFC7937]
タイプ：「CDNI Logging record-types」レジストリからのエントリに対応する文字列[RFC7937]
Mandatory-to-Specify: Yes.
指定が必須：はい。
Property: fields
プロパティ：フィールド
Description: List of supported CDNI Logging fields that are optional for the specified record-type.
説明：指定されたレコードタイプでオプションである、サポートされているCDNIログフィールドのリスト。
Type: List of strings corresponding to entries from the "CDNI Logging Field Names" registry [RFC7937]
タイプ：「CDNI Logging Field Names」レジストリのエントリに対応する文字列のリスト[RFC7937]
Mandatory-to-Specify: No. Default is that all optional fields are supported. Omission of this field MUST be interpreted as "all optional fields are supported". An empty list MUST be interpreted as "no optional fields are supported". Otherwise, if a list of fields is provided, the fields in that list MUST be interpreted as "the only optional fields that are supported".
必須指定：いいえ。デフォルトでは、すべてのオプションフィールドがサポートされます。このフィールドの省略は、「すべてのオプションのフィールドがサポートされている」と解釈する必要があります。空のリストは、「オプションのフィールドはサポートされていません」と解釈する必要があります。そうでなければ、フィールドのリストが提供される場合、そのリスト内のフィールドは、「サポートされる唯一のオプションのフィールド」として解釈されなければなりません（MUST）。
The following shows an example of CDNI Logging capability object serialization for a CDN that supports the optional Content Collection ID CDNI Logging field (but not the optional Session ID CDNI Logging field) for the "cdni_http_request_v1" record-type.
以下は、「cdni_http_request_v1」レコードタイプのオプションのコンテンツコレクションID CDNIログフィールド（オプションのセッションID CDNIログフィールドではない）をサポートするCDNのCDNIログ機能オブジェクトのシリアル化の例を示しています。
{
"capabilities": [
{
"capability-type": "FCI.Logging",
"capability-value": {
"record-type": "cdni_http_request_v1",
"fields": ["s-ccid"]
},
"footprints": [
<Footprint objects>
]
}
]
}
The next example shows the CDNI Logging capability object serialization for a CDN that supports all optional fields for the "cdni_http_request_v1" record-type.
次の例は、「cdni_http_request_v1」レコードタイプのすべてのオプションフィールドをサポートするCDNのCDNI Logging機能オブジェクトのシリアル化を示しています。
{
"capabilities": [
{
"capability-type": "FCI.Logging",
"capability-value": {
"record-type": "cdni_http_request_v1"
},
"footprints": [
<Footprint objects>
]
}
]
}
The final example shows the CDNI Logging capability object
serialization for a CDN that supports none of the optional fields for
the "cdni_http_request_v1" record-type.
{
"capabilities": [
{
"capability-type": "FCI.Logging",
"capability-value": {
"record-type": "cdni_http_request_v1",
"fields": []
},
"footprints": [
<Footprint objects>
]
}
]
}
The CDNI Metadata capability object is used to indicate support for CDNI GenericMetadata types [RFC8006].
CDNIメタデータ機能オブジェクトは、CDNI GenericMetadataタイプ[RFC8006]のサポートを示すために使用されます。
Property: metadata
プロパティ：メタデータ
Description: List of supported CDNI GenericMetadata types.
説明：サポートされているCDNI GenericMetadataタイプのリスト。
Type: List of strings corresponding to entries from the "CDNI Payload Types" registry [RFC7736] that correspond to CDNI GenericMetadata objects
タイプ：CDNI GenericMetadataオブジェクトに対応する「CDNI Payload Types」レジストリ[RFC7736]のエントリに対応する文字列のリスト
Mandatory-to-Specify: Yes. An empty list MUST be interpreted as "no GenericMetadata types are supported", i.e., "only structural metadata and simple types are supported"; otherwise, the list must be interpreted as containing "the only GenericMetadata types that are supported" (in addition to structural metadata and simple types) [RFC8006].
指定が必須：はい。空のリストは、「GenericMetadataタイプはサポートされていない」、つまり「構造化メタデータと単純タイプのみがサポートされている」と解釈する必要があります。それ以外の場合、リストは「サポートされている唯一のGenericMetadataタイプ」（構造メタデータと単純タイプに加えて）[RFC8006]を含むものとして解釈する必要があります。
The following shows an example of CDNI Metadata capability object serialization for a CDN that supports only the SourceMetadata GenericMetadata type (i.e., it can acquire and deliver content but cannot enforce any security policies, e.g., time, location, or protocol Access Control Lists (ACLs)).
以下は、SourceMetadata GenericMetadataタイプのみをサポートするCDNのCDNIメタデータ機能オブジェクトのシリアル化の例を示しています（つまり、コンテンツを取得および配信できますが、セキュリティポリシー（時間、場所、プロトコルなど）を適用できませんアクセス制御リスト（ACL） ））。
{
"capabilities": [
{
"capability-type": "FCI.Metadata",
"capability-value": {
"metadata": ["MI.SourceMetadata"]
},
"footprints": [
<Footprint objects>
]
}
]
}
The next example shows the CDNI Metadata capability object serialization for a CDN that supports only structural metadata (i.e., it can parse metadata as a transit CDN but cannot enforce security policies or deliver content).
次の例は、構造メタデータのみをサポートするCDNのCDNIメタデータ機能オブジェクトのシリアル化を示しています（つまり、トランジットCDNとしてメタデータを解析できますが、セキュリティポリシーを適用したりコンテンツを配信したりすることはできません）。
{
"capabilities": [
{
"capability-type": "FCI.Metadata",
"capability-value": {
"metadata": []
},
"footprints": [
<Footprint objects>
]
}
]
}
This document registers the following CDNI Payload Types under the IANA "CDNI Payload Types" registry:
このドキュメントでは、IANAの「CDNIペイロードタイプ」レジストリの下に次のCDNIペイロードタイプを登録しています。
+-------------------------+---------------+
| Payload Type | Specification |
+-------------------------+---------------+
| FCI.DeliveryProtocol | RFC 8008 |
| FCI.AcquisitionProtocol | RFC 8008 |
| FCI.RedirectionMode | RFC 8008 |
| FCI.Logging | RFC 8008 |
| FCI.Metadata | RFC 8008 |
+-------------------------+---------------+
Purpose: The purpose of this Payload Type is to distinguish FCI advertisement objects for supported delivery protocols
目的：このペイロードタイプの目的は、サポートされている配信プロトコルのFCI広告オブジェクトを区別することです
Interface: FCI
インターフェース：FCI
Encoding: see Section 5.3
エンコーディング：セクション5.3を参照
Purpose: The purpose of this Payload Type is to distinguish FCI advertisement objects for supported acquisition protocols
目的：このペイロードタイプの目的は、サポートされている取得プロトコルのFCI広告オブジェクトを区別することです
Interface: FCI
インターフェース：FCI
Encoding: see Section 5.4
エンコーディング：セクション5.4を参照
Purpose: The purpose of this Payload Type is to distinguish FCI advertisement objects for supported redirection modes
目的：このペイロードタイプの目的は、サポートされているリダイレクトモードのFCI広告オブジェクトを区別することです
Interface: FCI
インターフェース：FCI
Encoding: see Section 5.5
エンコーディング：セクション5.5を参照
Purpose: The purpose of this Payload Type is to distinguish FCI advertisement objects for supported CDNI Logging record-types and optional CDNI Logging field names
目的：このペイロードタイプの目的は、サポートされているCDNIログのレコードタイプとオプションのCDNIログフィールド名のFCI広告オブジェクトを区別することです
Interface: FCI
インターフェース：FCI
Encoding: see Section 5.6
エンコーディング：セクション5.6を参照
Purpose: The purpose of this Payload Type is to distinguish FCI advertisement objects for supported CDNI GenericMetadata types
目的：このペイロードタイプの目的は、サポートされているCDNI GenericMetadataタイプのFCI広告オブジェクトを区別することです
Interface: FCI
インターフェース：FCI
Encoding: see Section 5.7
エンコーディング：セクション5.7を参照
IANA has created a new "CDNI Capabilities Redirection Modes" registry in the "Content Delivery Network Interconnection (CDNI) Parameters" registry. The "CDNI Capabilities Redirection Modes" namespace defines the valid redirection modes that can be advertised as supported by a CDN. Additions to the "CDNI Capabilities Redirection Modes" namespace conform to the IETF Review policy as defined in [RFC5226].
IANAは、「コンテンツ配信ネットワーク相互接続（CDNI）パラメータ」レジストリに新しい「CDNI機能リダイレクトモード」レジストリを作成しました。 「CDNI機能リダイレクトモード」名前空間は、CDNでサポートされているものとしてアドバタイズできる有効なリダイレクトモードを定義します。 「CDNI Capabilities Redirection Modes」名前空間への追加は、[RFC5226]で定義されているIETFレビューポリシーに準拠しています。
The following table defines the initial redirection modes:
次の表は、初期リダイレクトモードを定義しています。
+------------------+----------------------------------+----------+
| Redirection Mode | Description | RFC |
+------------------+----------------------------------+----------+
| DNS-I | Iterative DNS-based Redirection | RFC 8008 |
| DNS-R | Recursive DNS-based Redirection | RFC 8008 |
| HTTP-I | Iterative HTTP-based Redirection | RFC 8008 |
| HTTP-R | Recursive HTTP-based Redirection | RFC 8008 |
+------------------+----------------------------------+----------+
This specification describes the semantics for capabilities and footprint advertisement objects across interconnected CDNs. It does not, however, specify a concrete protocol for transporting those objects. Specific security mechanisms can only be selected for concrete protocols that instantiate these semantics. This document does, however, place some high-level security constraints on such protocols.
この仕様では、相互接続されたCDN全体の機能とフットプリント広告オブジェクトのセマンティクスについて説明します。ただし、これらのオブジェクトを転送するための具体的なプロトコルは指定されていません。特定のセキュリティメカニズムは、これらのセマンティクスをインスタンス化する具体的なプロトコルに対してのみ選択できます。ただし、このドキュメントでは、そのようなプロトコルにいくつかの高レベルのセキュリティ制約を課しています。
All protocols that implement these capabilities and footprint advertisement objects are REQUIRED to provide integrity and authentication services. Without authentication and integrity, an attacker could trivially deny service by forging a footprint advertisement from a dCDN that claims the network has no footprint or capability. This would prevent the uCDN from delegating any requests to the dCDN. Since a preexisting relationship between all dCDNs and uCDNs is assumed by CDNI, the exchange of any necessary credentials could be conducted before the FCI is brought online. The authorization decision to accept advertisements would also follow this preexisting relationship and any contractual obligations that it stipulates.
整合性と認証サービスを提供するには、これらの機能とフットプリント広告オブジェクトを実装するすべてのプロトコルが必要です。認証と整合性がない場合、攻撃者は、ネットワークにフットプリントまたは機能がないと主張するdCDNからフットプリントアドバタイズを偽造することにより、サービスを簡単に拒否する可能性があります。これにより、uCDNが要求をdCDNに委任できなくなります。すべてのdCDNとuCDNの間の既存の関係はCDNIが想定しているため、FCIがオンラインになる前に、必要な資格情報の交換を行うことができます。広告を受け入れるという承認の決定も、この既存の関係とそれが規定する契約上の義務に従います。
All protocols that implement these capabilities and footprint advertisement objects are REQUIRED to provide confidentiality services. Some dCDNs are willing to share information about their footprints or capabilities with a uCDN but not with other, competing dCDNs. For example, if a dCDN incurs an outage that reduces footprint coverage temporarily, that event could be information the dCDN would want to share confidentially with the uCDN.
これらの機能とフットプリント広告オブジェクトを実装するすべてのプロトコルは、機密性サービスを提供するために必要です。一部のdCDNは、そのフットプリントまたは機能に関する情報をuCDNと共有することをいとわないが、他の競合するdCDNとは共有しません。たとえば、dCDNが停止してフットプリントのカバレッジが一時的に減少する場合、そのイベントは、dCDNがuCDNと秘密に共有したい情報である可能性があります。
As specified in this document, the security requirements of the FCI could be met by transport-layer security mechanisms coupled with domain certificates as credentials (e.g., TLS transport for HTTP as per [RFC2818] and [RFC7230], with usage guidance from [RFC7525]) between CDNs. There is no apparent need for further object-level security in this framework, as the trust relationships it defines are bilateral relationships between uCDNs and dCDNs rather than transitive relationships.
このドキュメントで指定されているように、FCIのセキュリティ要件は、資格情報としてドメイン証明書と結合されたトランスポート層セキュリティメカニズム（たとえば、[RFC2818]と[RFC7230]によるHTTPのTLSトランスポート、および[RFC7525 ]）CDN間。このフレームワークでは、オブジェクトレベルのセキュリティをさらに強化する必要はありません。それが定義する信頼関係は、推移的な関係ではなく、uCDNとdCDN間の双方向の関係であるためです。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7159]ブレイ、T。、編、「JavaScript Object Notation（JSON）データ交換フォーマット」、RFC 7159、DOI 10.17487 / RFC7159、2014年3月、<http://www.rfc-editor.org/info/ rfc7159>。
[RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., "Framework for Content Distribution Network Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, August 2014, <http://www.rfc-editor.org/info/rfc7336>.
[RFC7336] Peterson、L.、Davie、B。、およびR. van Brandenburg、編、「Framework for Content Distribution Network Interconnection（CDNI）」、RFC 7336、DOI 10.17487 / RFC7336、2014年8月、<http：// www.rfc-editor.org/info/rfc7336>。
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, <http://www.rfc-editor.org/info/rfc7493>.
[RFC7493]ブレイ、T。、編、「The I-JSON Message Format」、RFC 7493、DOI 10.17487 / RFC7493、2015年3月、<http://www.rfc-editor.org/info/rfc7493>。
[RFC7937] Le Faucheur, F., Ed., Bertrand, G., Ed., Oprescu, I., Ed., and R. Peterkofsky, "Content Distribution Network Interconnection (CDNI) Logging Interface", RFC 7937, DOI 10.17487/RFC7937, August 2016, <http://www.rfc-editor.org/info/rfc7937>.
[RFC7937] Le Faucheur、F.、Ed。、Bertrand、G.、Ed。、Oprescu、I.、Ed。、and R. Peterkofsky、 "Content Distribution Network Interconnection（CDNI）Logging Interface"、RFC 7937、DOI 10.17487 / RFC7937、2016年8月、<http://www.rfc-editor.org/info/rfc7937>。
[RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, "Content Delivery Network Interconnection (CDNI) Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, <http://www.rfc-editor.org/info/rfc8006>.
[RFC8006] Niven-Jenkins、B.、Murray、R.、Caulfield、M。、およびK. Ma、「Content Delivery Network Interconnection（CDNI）Metadata」、RFC 8006、DOI 10.17487 / RFC8006、2016年12月、<http： //www.rfc-editor.org/info/rfc8006>。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.
[RFC2818] Rescorla、E。、「HTTP Over TLS」、RFC 2818、DOI 10.17487 / RFC2818、2000年5月、<http://www.rfc-editor.org/info/rfc2818>。
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", RFC 6707, DOI 10.17487/RFC6707, September 2012, <http://www.rfc-editor.org/info/rfc6707>.
[RFC6707] Niven-Jenkins、B.、Le Faucheur、F。、およびN. Bitar、「Content Distribution Network Interconnection（CDNI）Problem Statement」、RFC 6707、DOI 10.17487 / RFC6707、2012年9月、<http：// www .rfc-editor.org / info / rfc6707>。
[RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley, P., Ma, K., and G. Watson, "Use Cases for Content Delivery Network Interconnection", RFC 6770, DOI 10.17487/RFC6770, November 2012, <http://www.rfc-editor.org/info/rfc6770>.
[RFC6770] Bertrand、G.、Ed。、Stephan、E.、Burbridge、T.、Eardley、P.、Ma、K.、and G. Watson、 "Use Cases for Content Delivery Network Interconnection"、RFC 6770、DOI 10.17487 / RFC6770、2012年11月、<http://www.rfc-editor.org/info/rfc6770>。
[RFC7230] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230] Fielding、R.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing"、RFC 7230、DOI 10.17487 / RFC7230、June 2014、<http：/ /www.rfc-editor.org/info/rfc7230>。
[RFC7337] Leung, K., Ed., and Y. Lee, Ed., "Content Distribution Network Interconnection (CDNI) Requirements", RFC 7337, DOI 10.17487/RFC7337, August 2014, <http://www.rfc-editor.org/info/rfc7337>.
[RFC7337] Leung、K。、編、およびY. Lee、編、「Content Distribution Network Interconnection（CDNI）Requirements」、RFC 7337、DOI 10.17487 / RFC7337、2014年8月、<http：//www.rfc- editor.org/info/rfc7337>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<http://www.rfc-editor.org/info/rfc7525>。
[RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, December 2015, <http://www.rfc-editor.org/info/rfc7736>.
[RFC7736] Ma、K。、「Content Delivery Network Interconnection（CDNI）Media Type Registration」、RFC 7736、DOI 10.17487 / RFC7736、2015年12月、<http://www.rfc-editor.org/info/rfc7736>。
Focusing on a main use case that contains a simple (yet somewhat challenging), realistic, and generally imaginable scenario can help narrow down the requirements for the CDNI FCI. To this end, the following (simplified) use case can help clarify the semantics of footprints and capabilities for CDNI. In particular, the intention of the use case is to clarify what information needs to be exchanged on the CDNI FCI, what types of information need to be supported in a mandatory fashion (and which types can be considered optional), and what types of information need to be updated with respect to a priori established CDNI contracts.
シンプルな（ただし、やや難しい）現実的で一般的に想像可能なシナリオを含む主要なユースケースに焦点を合わせると、CDNI FCIの要件を絞り込むのに役立ちます。このため、次の（簡略化された）使用例は、CDNIのフットプリントと機能のセマンティクスを明確にするのに役立ちます。特に、ユースケースの目的は、CDNI FCIで交換する必要がある情報、必須の方法でサポートする必要がある情報のタイプ（およびオプションと見なすことができるタイプ）、および情報のタイプを明確にすることです。事前に確立されたCDNI契約に関して更新する必要があります。
Use case: A given uCDN has several dCDNs. It selects one dCDN for delivery protocol A and footprint 1 and another dCDN for delivery protocol B and footprint 1. The dCDN that serves delivery protocol B has a further, transitive (level-2) dCDN that serves delivery protocol B in a subset of footprint 1 where the first-level dCDN cannot serve delivery protocol B itself. What happens if capabilities change in the transitive level-2 dCDN that might affect how the uCDN selects a level-1 dCDN (e.g., in case the level-2 dCDN cannot serve delivery protocol B anymore)? How will these changes be conveyed to the uCDN? In particular, what information does the uCDN need to be able to select a new first-level dCDN, for either all of footprint 1 or only the subset of footprint 1 that the transitive level-2 dCDN served on behalf of the first-level dCDN?
使用例：特定のuCDNには複数のdCDNがあります。配信プロトコルAとフットプリント1に1つのdCDNを選択し、配信プロトコルBとフットプリント1に別のdCDNを選択します。配信プロトコルBを提供するdCDNには、フットプリントのサブセットで配信プロトコルBを提供するさらに推移的な（レベル2）dCDNがあります。第1レベルのdCDNが配信プロトコルB自体を処理できない1。 uCDNがレベル1 dCDNを選択する方法に影響を与える可能性がある推移的なレベル2 dCDNの機能が変更された場合（たとえば、レベル2 dCDNが配信プロトコルBを提供できなくなった場合）はどうなりますか？これらの変更はuCDNにどのように伝えられますか？特に、uCDNが新しい第1レベルのdCDNを選択できるようにするために必要な情報は、フットプリント1のすべて、または推移レベル2 dCDNが第1レベルのdCDNに代わって提供したフットプリント1のサブセットのみです。 ？
Roughly speaking, "footprint" can be defined as a dCDN's "ability and willingness to serve". However, in addition to simple ability and willingness to serve, the uCDN could want additional information before deciding which dCDN to select, e.g., "how well" a given dCDN can actually serve a given end user request. The dCDN's ability and willingness to serve SHOULD be distinguished from the subjective qualitative measurement of how well it can serve a given end user request. One can imagine that such additional information is implicitly associated with a given footprint, due to contractual agreements, Service Level Agreements (SLAs), business relationships, or past perceptions of dCDN quality. As an alternative, such additional information could also be explicitly included with the given footprint.
大まかに言えば、「フットプリント」はdCDNの「サービスする能力と意欲」として定義できます。ただし、提供する単純な能力と意欲に加えて、uCDNは、どのdCDNを選択するかを決定する前に、特定のdCDNが実際に特定のエンドユーザーの要求にどの程度対応できるかなどの追加情報を必要とする場合があります。 dCDNの機能と提供する意欲は、特定のエンドユーザーの要求にどの程度対応できるかについての主観的な定性的測定と区別する必要があります（SHOULD）。そのような追加情報は、契約上の合意、サービスレベル契約（SLA）、ビジネス関係、またはdCDN品質の過去の認識により、特定のフットプリントに暗黙的に関連付けられていると想像できます。別の方法として、そのような追加情報を特定のフットプリントに明示的に含めることもできます。
It is reasonable to assume that a significant part of the actual footprint advertisement will occur out-of-band, prior to any CDNI FCI advertisement, with footprints defined in contractual agreements between participating CDNs. The reason for this assumption is that any contractual agreement is likely to contain specifics about the dCDN coverage (footprint) to which the contractual agreement applies. In particular, additional information to judge the delivery quality associated with a given dCDN footprint might be defined in contractual agreements, outside of the CDNI FCI. Further, one can assume that dCDN contractual agreements about the delivery quality associated with a given footprint will probably be based on high-level aggregated statistics and will not be too detailed.
実際のフットプリント広告の大部分は、CDNI FCIアドバタイズメントの前にアウトオブバンドで発生し、フットプリントは参加するCDN間の契約で定義されていると想定するのが妥当です。この仮定の理由は、契約上の合意には、契約上の合意が適用されるdCDNカバレッジ（フットプリント）に関する詳細が含まれる可能性が高いためです。特に、特定のdCDNフットプリントに関連する配信品質を判断するための追加情報は、CDNI FCI以外の契約で定義される場合があります。さらに、特定のフットプリントに関連する配信品質に関するdCDN契約上の合意は、おそらく高レベルの集計統計に基づいており、あまり詳細ではないものと想定できます。
Given that a large part of the footprint advertisement will be defined in contractual agreements, the semantics of CDNI footprint advertisement refer to answering the following question: what exactly still needs to be advertised by the CDNI FCI? For instance, updates about temporal failures of part of a footprint can be useful information to convey via the CDNI Request Routing interface. Such information would provide updates on information previously agreed upon in contracts between the participating CDNs. In other words, the CDNI FCI is a means for a dCDN to provide changes/updates regarding a footprint it has previously agreed to serve in a contract with a uCDN.
フットプリント広告の大部分が契約上の合意で定義されることを考えると、CDNIフットプリント広告のセマンティクスは、次の質問への回答に言及しています：CDNI FCIによって正確に何を広告する必要があるか？たとえば、フットプリントの一部の一時的な障害に関する更新は、CDNI要求ルーティングインターフェイスを介して伝達するのに役立つ情報です。そのような情報は、参加しているCDN間の契約で以前に合意された情報の更新を提供します。言い換えると、CDNI FCIは、dCDNがuCDNとの契約でサービスすることに以前に合意したフットプリントに関する変更/更新を提供するための手段です。
Generally speaking, one can imagine two categories of footprints to be advertised by a dCDN:
一般的に言えば、dCDNによって宣伝されるフットプリントの2つのカテゴリを想像できます。
o A footprint could be defined based on coverage/reachability, where "coverage/reachability" refers to a set of prefixes, a geographic region, or similar boundary. The dCDN claims that it can cover/reach "end user requests coming from this footprint".
o フットプリントは、カバレッジ/到達可能性に基づいて定義できます。「カバレッジ/到達可能性」は、プレフィックスのセット、地理的領域、または同様の境界を指します。 dCDNは、「このフットプリントからのエンドユーザー要求」をカバー/到達できると主張しています。
o A footprint could be defined based on resources, where "resources" refers to Surrogates a dCDN claims to have (e.g., the location of Surrogates/resources). The dCDN claims that "from this footprint" it can serve incoming end user requests.
o フットプリントは、リソースに基づいて定義できます。「リソース」とは、dCDNが要求するサロゲート（たとえば、サロゲート/リソースの場所）を指します。 dCDNは、「このフットプリントから」着信エンドユーザー要求に対応できると主張しています。
For each of these footprint types, there are capabilities associated with a given footprint:
これらのフットプリントタイプごとに、特定のフットプリントに関連付けられた機能があります。
o capabilities such as delivery protocol, redirection mode, and metadata, which are supported in the coverage area for a footprint that is defined by coverage/reachability, or
o カバレッジ/到達可能性によって定義されるフットプリントのカバレッジエリアでサポートされる配信プロトコル、リダイレクトモード、メタデータなどの機能、または
o capabilities of resources, such as delivery protocol, redirection mode, and metadata, which apply to a footprint that is defined by resources.
o リソースによって定義されたフットプリントに適用される、配信プロトコル、リダイレクトモード、メタデータなどのリソースの機能。
Resource footprint types are more specific than coverage/reachability footprint types, where the actual coverage and reachability are extrapolated from the resource location (e.g., a netmask applied to a resource IP address to derive an IP prefix). The specific methods for extrapolating coverage/reachability from the resource location are beyond the scope of this document. In the degenerate case, the resource address could be specified as a coverage/reachability footprint type, in which case no extrapolation is necessary. Resource footprint types could expose the internal structure of a CDN; this could be undesirable. As such, the resource footprint types are not considered mandatory to support for CDNI.
リソースフットプリントタイプは、カバレッジ/到達可能性フットプリントタイプよりも具体的です。実際のカバレッジと到達可能性は、リソースの場所から推定されます（たとえば、IPプレフィックスを取得するためにリソースIPアドレスに適用されるネットマスク）。リソースの場所からカバレッジ/到達可能性を推定する特定の方法は、このドキュメントの範囲を超えています。縮退の場合、リソースアドレスはカバレッジ/到達可能性フットプリントタイプとして指定できます。この場合、外挿は必要ありません。リソースフットプリントタイプは、CDNの内部構造を公開する可能性があります。これは望ましくない場合があります。そのため、リソースフットプリントタイプは、CDNIのサポートに必須とは見なされません。
Footprints can be viewed as constraints for delegating requests to a dCDN: a dCDN footprint advertisement tells the uCDN the limitations for delegating a request to the dCDN. For IP prefixes or ASN(s), the footprint signals to the uCDN that it should consider the dCDN a candidate only if the IP address of the Request Routing source falls within the prefix set (or ASN, respectively). The CDNI specifications do not define how a given uCDN determines what address ranges are in a particular ASN. Similarly, for country codes, a uCDN should only consider the dCDN a candidate if it covers the country of the Request Routing source. The CDNI specifications do not define how a given uCDN determines the country of the Request Routing source. Multiple footprint constraints are additive: the advertisement of different footprint types narrows the dCDN's candidacy cumulatively.
フットプリントは、dCDNへのリクエストを委任するための制約と見なすことができます。dCDNフットプリントアドバタイズは、リクエストをdCDNに委任するための制限をuCDNに通知します。 IPプレフィックスまたはASNの場合、フットプリントは、リクエストルーティングソースのIPアドレスがプレフィックスセット（またはASN）に含まれる場合にのみ、dCDNを候補と見なす必要があることをuCDNに通知します。 CDNI仕様は、特定のuCDNが特定のASN内のアドレス範囲を決定する方法を定義していません。同様に、国コードの場合、uCDNはリクエストルーティングソースの国をカバーする場合にのみ、dCDNを候補と見なす必要があります。 CDNI仕様は、特定のuCDNが要求ルーティングソースの国を決定する方法を定義していません。複数のフットプリント制約は付加的です。異なるフットプリントタイプのアドバタイズは、dCDNの候補を累積的に狭めます。
Independent of the exact type of a footprint, a footprint might also include the connectivity of a given dCDN to other CDNs that are able to serve content to users on behalf of that dCDN, to cover cases with cascaded CDNs. Further, the dCDN needs to be able to express its footprint to an interested uCDN in a comprehensive form, e.g., as a data set containing the complete footprint. However, making incremental updates to express dynamic changes in state is also desirable.
フットプリントの正確なタイプとは関係なく、フットプリントには、特定のdCDNから、そのdCDNに代わってユーザーにコンテンツを提供できる他のCDNへの接続が含まれ、カスケードCDNのケースをカバーする場合があります。さらに、dCDNは、完全なフットプリントを含むデータセットなどの包括的な形式で、関心のあるuCDNにフットプリントを表現できる必要があります。ただし、状態の動的な変化を表すために増分更新を行うことも望ましいです。
In general, the dCDN needs to be able to express its general capabilities to the uCDN. These general capabilities could indicate if the dCDN supports a given service -- for instance, HTTP vs. HTTPS delivery. Furthermore, the dCDN needs to be able to express particular capabilities for service delivery in a particular footprint area. For example, the dCDN might in general offer HTTPS but not in some specific areas, either for maintenance reasons or because the Surrogates covering this particular area cannot deliver this type of service. Hence, in certain cases a footprint and capabilities are tied together and cannot be interpreted independently of each other. In such cases, i.e., where capabilities need to be expressed on a per-footprint basis, it could be beneficial to combine footprint advertisement and capabilities advertisement.
一般に、dCDNはその一般的な機能をuCDNに表現できる必要があります。これらの一般的な機能は、dCDNが特定のサービス（HTTPとHTTPSの配信など）をサポートしているかどうかを示すことができます。さらに、dCDNは、特定の設置面積でサービスを提供するための特定の機能を表現できる必要があります。たとえば、dCDNは一般にHTTPSを提供しますが、メンテナンス上の理由またはこの特定の領域をカバーするサロゲートがこのタイプのサービスを提供できないため、特定の領域では提供しません。したがって、特定のケースでは、フットプリントと機能が結び付いており、互いに独立して解釈できない場合があります。このような場合、つまり機能をフットプリントごとに表現する必要がある場合は、フットプリント広告と機能広告を組み合わせると効果的です。
A high-level and very rough semantic for capabilities is thus the following: capabilities are types of information that allow a uCDN to determine if a dCDN is able (and willing) to accept (and properly handle) a delegated content request. In addition, capabilities are characterized by the fact that this information can change over time based on the state of the network or Surrogates.
したがって、機能の高レベルで非常に大まかなセマンティクスは次のとおりです。機能とは、uCDNが、dCDNが委任されたコンテンツ要求を受け入れる（そして適切に処理する）ことができる（そして喜んで）かどうかを判断できる情報のタイプです。さらに、機能は、この情報がネットワークまたはサロゲートの状態に基づいて時間とともに変化する可能性があるという事実によって特徴付けられます。
At first glance, several broad categories of capabilities seem useful to convey via an advertisement interface; however, advertising capabilities that change highly dynamically (e.g., real-time delivery performance metrics, CDN resource load, or other highly dynamically changing QoS information) are beyond the scope of the CDNI FCI. First, out of the multitude of possible metrics and capabilities, it is hard to agree on a subset and the precise metrics to be used. Second, it seems infeasible to specify such highly dynamically changing capabilities and the corresponding metrics within a reasonable time frame.
一見すると、いくつかの幅広いカテゴリの機能が、広告インターフェースを介して伝えるのに役立つようです。ただし、非常に動的に変化するアドバタイズ機能（リアルタイム配信パフォーマンスメトリック、CDNリソースロード、またはその他の非常に動的に変化するQoS情報など）は、CDNI FCIの範囲を超えています。まず、考えられる多数のメトリックと機能の中で、サブセットと使用する正確なメトリックについて合意するのは困難です。第二に、そのような高度に動的に変化する機能と対応するメトリックを妥当な時間枠内で指定することは実行不可能であると思われます。
Useful capabilities refer to information that does not change highly dynamically and that, in many cases, is absolutely necessary for deciding on a particular dCDN for a given end user request. For instance, if an end user request concerns the delivery of a video file with a certain protocol, the uCDN needs to know if a given dCDN is capable of supporting this delivery protocol.
有用な機能とは、動的に大きく変化しない情報を指し、多くの場合、特定のエンドユーザーリクエストの特定のdCDNを決定するために絶対に必要です。たとえば、エンドユーザーの要求が特定のプロトコルでのビデオファイルの配信に関係している場合、uCDNは、特定のdCDNがこの配信プロトコルをサポートできるかどうかを知る必要があります。
Similar to footprint advertisement, it is reasonable to assume that a significant part of the actual (resource) capabilities advertisement will also occur out-of-band, prior to any CDNI FCI advertisement, with capabilities defined in contractual agreements between participating CDNs. The role of capability advertisement is hence rather to enable the dCDN to update a uCDN on changes since a contract has been set up (e.g., in case a new delivery protocol is suddenly being added to the list of supported delivery protocols of a given dCDN or in case a certain delivery protocol is suddenly not being supported anymore due to failures). "Capabilities advertisement" thus refers to conveying information to a uCDN about changes/updates to certain capabilities with respect to a given contract.
フットプリントアドバタイズメントと同様に、実際の（リソース）機能アドバタイズメントのかなりの部分も、CDNI FCIアドバタイズメントの前にアウトバンドで発生し、機能は参加CDN間の契約で定義されていると想定するのが妥当です。したがって、機能アドバタイズの役割は、契約が設定されてからの変更時にdCDNがuCDNを更新できるようにすることです（たとえば、新しい配信プロトコルが特定のdCDNのサポートされている配信プロトコルのリストに突然追加された場合、または障害のため、特定の配信プロトコルが突然サポートされなくなった場合）。したがって、「機能の広告」とは、所定の契約に関する特定の機能の変更/更新に関する情報をuCDNに伝達することを指します。
Given these semantics, it needs to be decided what exact capabilities are useful and how these can be expressed. Since the details of CDNI contracts are not known at the time of this writing (and the CDNI interface is better off being agnostic to these contracts anyway), it remains to be seen what capabilities will be used to define agreements between CDNs in practice. One implication for standardization could be to initially only specify a very limited set of mandatory capabilities for advertisement and have, on top of that, a flexible data model that allows exchanging additional capabilities when needed. Still, agreement needs to be reached regarding which capabilities (if any) will be mandatory among CDNs.
これらのセマンティクスを前提として、どの正確な機能が有用であり、どのように表現できるかを決定する必要があります。この記事の執筆時点ではCDNIコントラクトの詳細はわかっていないため（そして、CDNIインターフェースはこれらのコントラクトにとらわれない方がよい）、実際にCDN間の合意を定義するためにどの機能が使用されるかはまだ不明です。標準化の影響の1つは、最初は非常に限られた必須の機能セットのみを広告に指定し、それに加えて、必要に応じて追加機能を交換できる柔軟なデータモデルを用意することです。それでも、CDN間で必須の機能（ある場合）について合意に達する必要があります。
It is not feasible to enumerate all the possible options for the mandatory capabilities listed above (e.g., all the potential delivery protocols or metadata options) or anticipate all the future needs for additional capabilities. FCI object extensibility is necessary to support future capabilities, as well as a generic protocol for conveying any capability information (e.g., with common encoding, error handling, and security mechanisms; further requirements for the CDNI FCI are listed in [RFC7337]).
上記の必須機能のすべての可能なオプション（たとえば、すべての潜在的な配信プロトコルまたはメタデータオプション）を列挙したり、追加機能の将来のすべてのニーズを予測したりすることはできません。 FCIオブジェクトの拡張性は、将来の機能、および機能情報を伝達するための一般的なプロトコル（たとえば、一般的なエンコーディング、エラー処理、セキュリティメカニズムなど）をサポートするために必要です。CDNIFCIの追加要件は[RFC7337]に記載されています）。
Acknowledgments
謝辞
Jan Seedorf is partially supported by the GreenICN project (GreenICN: Architecture and Applications of Green Information Centric Networking), a research project supported jointly by the European Commission under its 7th Framework Program (contract no. 608518) and the National Institute of Information and Communications Technology (NICT) in Japan (contract no. 167). The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the GreenICN project, the European Commission, or NICT.
Jan Seedorfは、GreenICNプロジェクト（GreenICN：Green Information Centric Networkingのアーキテクチャとアプリケーション）、第7回フレームワークプログラム（契約番号608518）および国立情報通信研究所のもとで欧州委員会が共同でサポートする研究プロジェクトによって部分的にサポートされています日本のテクノロジー（NICT）（契約番号167）。ここに含まれる見解と結論は著者の見解と結論であり、GreenICNプロジェクト、欧州委員会、またはNICTの公式のポリシーまたは推奨を明示または暗示するものとして必ずしも解釈するべきではありません。
Martin Stiemerling provided initial input to this document and valuable comments to the ongoing discussions among the authors of this document. Thanks to Francois Le Faucheur and Scott Wainner for providing valuable comments and suggestions for the text.
Martin Stiemerlingは、このドキュメントへの最初のインプットと、このドキュメントの作者間の進行中の議論への貴重なコメントを提供しました。テキストに対して貴重なコメントと提案を提供してくれたFrancois Le FaucheurとScott Wainnerに感謝します。
Authors' Addresses
著者のアドレス
Jan Seedorf HFT Stuttgart - University of Applied Sciences Stuttgart Schellingstrasse 24 Stuttgart 70174 Germany
Jan Seedorf HFTシュトゥットガルト-応用科学大学シュトゥットガルトSchellingstrasse 24シュトゥットガルト70174ドイツ
Phone: +49-0711-8926-2801
Email: jan.seedorf@hft-stuttgart.de
Jon Peterson NeuStar 1800 Sutter St. Suite 570 Concord, CA 94520 United States of America
Jon Peterson NeuStar 1800 Sutter St. Suite 570 Concord、CA 94520アメリカ合衆国
Email: jon.peterson@neustar.biz Stefano Previdi Cisco Systems Via Del Serafico 200 Rome 0144 Italy
メール：jon.peterson@neustar.biz Stefano Previdi Cisco Systems Via Del Serafico 200 Rome 0144 Italy
Email: sprevidi@cisco.com
Ray van Brandenburg TNO Anna van Buerenplein 1 The Hague 2595DA The Netherlands
レイ・ファン・ブランデンブルクTNOアンナ・ファン・ブレンプレイン1ハーグ2595DAオランダ
Phone: +31-88-866-7000
Email: ray.vanbrandenburg@tno.nl
Kevin J. Ma Ericsson 43 Nagog Park Acton, MA 01720 United States of America
ケビンJ. Maエリクソン43 Nagog Parkアクトン、MA 01720アメリカ合衆国
Phone: +1-978-844-5100
Email: kevin.j.ma@ericsson.com