[要約] RFC 7975は、CDN間のリクエストルーティングリダイレクションインターフェースに関する標準仕様です。その目的は、異なるCDN間でのトラフィックの効率的なルーティングとリダイレクションを可能にすることです。
Internet Engineering Task Force (IETF) B. Niven-Jenkins, Ed.
Request for Comments: 7975 Nokia
Category: Standards Track R. van Brandenburg, Ed.
ISSN: 2070-1721 TNO
October 2016
Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection
コンテンツ配信ネットワーク（CDN）相互接続用の要求ルーティングリダイレクトインターフェイス
Abstract
概要
The Request Routing interface comprises (1) the asynchronous advertisement of footprint and capabilities by a downstream Content Delivery Network (CDN) that allows an upstream CDN to decide whether to redirect particular user requests to that downstream CDN; and (2) the synchronous operation of an upstream CDN requesting whether a downstream CDN is prepared to accept a user request and of a downstream CDN responding with how to actually redirect the user request. This document describes an interface for the latter part, i.e., the CDNI Request Routing Redirection interface.
リクエストルーティングインターフェイスは、（1）ダウンストリームコンテンツ配信ネットワーク（CDN）によるフットプリントと機能の非同期アドバタイズで構成されます。これにより、アップストリームCDNが特定のユーザーリクエストをそのダウンストリームCDNにリダイレクトするかどうかを決定できます。 （２）ダウンストリームＣＤＮがユーザ要求を受け入れる準備ができているかどうかを要求するアップストリームＣＤＮと、ユーザ要求を実際にリダイレクトする方法で応答するダウンストリームＣＤＮとの同期動作。このドキュメントでは、後の部分のインターフェース、つまりCDNIリクエストルーティングリダイレクトインターフェースについて説明します。
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/rfc7975.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7975で入手できます。
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Interface Function and Operation Overview . . . . . . . . . . 4
4. HTTP-Based Interface for the Redirection Interface . . . . . 6
4.1. Information Passed in RI Requests and Responses . . . . . 8
4.2. JSON Encoding of RI Requests and Responses . . . . . . . 9
4.3. MIME Media Types Used by the RI Interface . . . . . . . . 11
4.4. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 12
4.4.1. DNS Redirection Requests . . . . . . . . . . . . . . 12
4.4.2. DNS Redirection Responses . . . . . . . . . . . . . . 14
4.5. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 17
4.5.1. HTTP Redirection Requests . . . . . . . . . . . . . . 17
4.5.2. HTTP Redirection Responses . . . . . . . . . . . . . 19
4.6. Cacheability and Scope of Responses . . . . . . . . . . . 22
4.7. Error Responses . . . . . . . . . . . . . . . . . . . . . 24
4.8. Loop Detection and Prevention . . . . . . . . . . . . . . 28
5. Security Considerations . . . . . . . . . . . . . . . . . . . 29
5.1. Authentication, Authorization, Confidentiality, and
Integrity Protection . . . . . . . . . . . . . . . . . . 29
5.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 30
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
6.1. CDNI Payload Type Parameter Registrations . . . . . . . . 31
6.1.1. CDNI RI Redirection Request Payload Type . . . . . . 31
6.1.2. CDNI RI Redirection Response Payload Type . . . . . . 31
6.2. RI Error Response Registry . . . . . . . . . . . . . . . 31
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.1. Normative References . . . . . . . . . . . . . . . . . . 32
7.2. Informative References . . . . . . . . . . . . . . . . . 34
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 34
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
A Content Delivery Network (CDN) is a system built on an existing IP network that is used for large-scale content delivery, via prefetching or dynamically caching content on its distributed surrogates (caching servers). [RFC6707] describes the problem area of interconnecting CDNs.
コンテンツ配信ネットワーク（CDN）は、既存のIPネットワーク上に構築されたシステムであり、分散サロゲート（キャッシュサーバー）でコンテンツをプリフェッチまたは動的にキャッシュすることにより、大規模なコンテンツ配信に使用されます。 [RFC6707]は、CDNの相互接続の問題領域について説明しています。
The CDNI Request Routing interface outlined in [RFC7336] is comprised of:
[RFC7336]で概説されているCDNI要求ルーティングインターフェイスは、次のもので構成されています。
1. The asynchronous advertisement of footprint and capabilities by a downstream CDN (dCDN) that allows an upstream CDN (uCDN) to decide whether to redirect particular user requests to that dCDN.
1. アップストリームCDN（uCDN）が特定のユーザー要求をそのdCDNにリダイレクトするかどうかを決定できるようにする、ダウンストリームCDN（dCDN）によるフットプリントと機能の非同期通知。
2. The synchronous operation of a uCDN requesting whether a dCDN is prepared to accept a user request and of a dCDN responding with how to actually redirect the user request.
2. dCDNがユーザー要求を受け入れる準備ができているかどうかを要求するuCDNと、ユーザー要求を実際にリダイレクトする方法で応答するdCDNの同期操作。
This document describes an interface for the latter part, i.e., the CDNI Request Routing Redirection interface (RI).
このドキュメントでは、後の部分、つまりCDNIリクエストルーティングリダイレクトインターフェイス（RI）のインターフェイスについて説明します。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document reuses the terminology defined in [RFC6707].
このドキュメントは、[RFC6707]で定義された用語を再利用します。
The following additional terms are introduced by this document:
このドキュメントでは、次の追加用語が導入されています。
Application-Level Redirection: The act of using an application-specific redirection mechanism for the request routing process of a CDN. The Redirection Target (RT) is the result of a CDN's routing decision at the time it receives a content request via an application-specific protocol response. Examples of an application-level redirection are HTTP 302 Redirection and Real Time Messaging Protocol (RTMP) [RTMP] 302 Redirection.
アプリケーションレベルのリダイレクト：CDNの要求ルーティングプロセスにアプリケーション固有のリダイレクトメカニズムを使用する行為。リダイレクトターゲット（RT）は、アプリケーション固有のプロトコル応答を介してコンテンツ要求を受信したときのCDNのルーティング決定の結果です。アプリケーションレベルのリダイレクトの例は、HTTP 302リダイレクトおよびリアルタイムメッセージングプロトコル（RTMP）[RTMP] 302リダイレクトです。
DNS Redirection: The act of using DNS name resolution for the request routing process of a CDN. In DNS Redirection, the DNS name server of the CDN makes the routing decision based on a local policy and selects one or more Redirection Targets (RTs) and redirects the User Agent (UA) to the RT(s) by returning the details of the RT(s) in response to the DNS query request from the User Agent's DNS resolver.
DNSリダイレクト：CDNの要求ルーティングプロセスにDNS名前解決を使用する行為。 DNSリダイレクトでは、CDNのDNSネームサーバーがローカルポリシーに基づいてルーティングを決定し、1つ以上のリダイレクトターゲット（RT）を選択し、ユーザーエージェント（UA）をRTにリダイレクトします。ユーザーエージェントのDNSリゾルバーからのDNSクエリ要求に応答するRT（s）。
HTTP Redirection: The act of using an HTTP redirection response for the request routing process of a CDN. The Redirection Target (RT) is the result of the routing decision of a CDN at the time it receives a content request via HTTP. HTTP Redirection is a particular case of application-level redirection.
HTTPリダイレクト：CDNの要求ルーティングプロセスにHTTPリダイレクト応答を使用すること。リダイレクトターゲット（RT）は、HTTP経由でコンテンツ要求を受信したときのCDNのルーティング決定の結果です。 HTTPリダイレクションは、アプリケーションレベルのリダイレクションの特定のケースです。
Redirection Target (RT): The endpoint to which the User Agent is redirected. In CDNI, an RT may point to a number of different components, some examples include a surrogate in the same CDN as the request router, a request router in a dCDN, or a surrogate in a dCDN.
リダイレクトターゲット（RT）：ユーザーエージェントがリダイレクトされるエンドポイント。 CDNIでは、RTがいくつかの異なるコンポーネントを指す場合があります。いくつかの例には、リクエストルーターと同じCDNのサロゲート、dCDNのリクエストルーター、またはdCDNのサロゲートが含まれます。
The main function of the CDNI Redirection interface (RI) is to allow the request routing systems in interconnected CDNs to communicate to facilitate the redirection of User Agent requests between interconnected CDNs.
CDNIリダイレクトインターフェイス（RI）の主な機能は、相互接続されたCDN内の要求ルーティングシステムが通信して、相互接続されたCDN間のユーザーエージェント要求のリダイレクトを容易にすることです。
The detailed requirements for the Redirection interface and their relative priorities are described in Section 5 of [RFC7337].
リダイレクトインターフェースの詳細な要件とそれらの相対的な優先順位については、[RFC7337]のセクション5で説明されています。
The User Agent will make a request to a request router in the uCDN using one of either DNS or HTTP. The RI is used between the uCDN and one or more dCDNs. The dCDN's RI response may contain a Redirection Target with a type that is compatible with the protocol used between the User Agent and uCDN request router. The dCDN has control over the Redirection Target it provides. Depending on the returned Redirection Target, the User Agent's request may be redirected to:
ユーザーエージェントは、DNSまたはHTTPのいずれかを使用して、uCDNのリクエストルーターにリクエストを送信します。 RIは、uCDNと1つ以上のdCDNの間で使用されます。 dCDNのRI応答には、ユーザーエージェントとuCDN要求ルーター間で使用されるプロトコルと互換性のあるタイプのリダイレクトターゲットが含まれる場合があります。 dCDNは、提供するリダイレクトターゲットを制御します。返されたリダイレクトターゲットに応じて、ユーザーエージェントのリクエストは次の場所にリダイレクトされます。
o The final surrogate, which may be in the dCDN that returned the RI response to the uCDN or another CDN (if the dCDN delegates the delivery to another CDN); or
o uCDNまたは別のCDN（dCDNが別のCDNに配信を委任する場合）にRI応答を返したdCDNにある可能性がある最終サロゲート。または
o A request router (in the dCDN or another CDN), which may use a different redirection protocol (DNS or HTTP) than the one included in the RI request.
o リクエストルーター（dCDNまたは別のCDN内）。RIリクエストに含まれているものとは異なるリダイレクトプロトコル（DNSまたはHTTP）を使用できます。
The Redirection interface operates between the request routing systems of a pair of interconnected CDNs. To enable communication over the Redirection interface, the uCDN needs to know the URI (endpoint) in the dCDN to send CDNI request routing queries.
リダイレクションインターフェイスは、相互接続されたCDNのペアの要求ルーティングシステム間で動作します。リダイレクトインターフェイスを介した通信を有効にするには、uCDNがdCDNのURI（エンドポイント）を認識して、CDNI要求ルーティングクエリを送信する必要があります。
The Redirection interface URI may be statically preconfigured, dynamically discovered via the CDNI Control interface, or discovered via other means. However, such discovery mechanisms are not specified in this document, as they are considered out of the scope of the Redirection interface specification.
リダイレクションインターフェイスURIは、静的に事前設定するか、CDNIコントロールインターフェイスを介して動的に検出するか、または他の方法で検出することができます。ただし、このような検出メカニズムは、リダイレクトインターフェイス仕様の範囲外と見なされるため、このドキュメントでは指定されていません。
The Redirection interface is only relevant in the case of Recursive Request Redirection, as Iterative Request Redirection does not invoke any interaction over the Redirection interface between interconnected CDNs. Therefore, the scope of this document is limited to Recursive Request Redirection.
反復リクエストリダイレクトは相互接続されたCDN間のリダイレクトインターフェースを介した相互作用を呼び出さないため、リダイレクトインターフェースは再帰リクエストリダイレクトの場合にのみ関連します。したがって、このドキュメントの範囲は、再帰要求リダイレクトに限定されています。
In the case of Recursive Request Redirection, in order to perform redirection of a request received from a User Agent, the uCDN queries the dCDN so that the dCDN can select and provide a Redirection Target. In cases where a uCDN has a choice of dCDNs, it is up to the uCDN to decide (for example, via configured policies) which dCDN(s) to query and in which order to query them. A number of strategies are possible, including selecting a preferred dCDN based on local policy, possibly falling back to querying an alternative dCDN(s) if the first dCDN does not return a Redirection Target or otherwise rejects the uCDN's RI request. A more complex strategy could be to query multiple dCDNs in parallel before selecting one and using the Redirection Target provided by that dCDN.
再帰的なリクエストのリダイレクトの場合、ユーザーエージェントから受信したリクエストのリダイレクトを実行するために、uCDNはdCDNにクエリを送信し、dCDNがリダイレクトターゲットを選択して提供できるようにします。 uCDNにdCDNの選択肢がある場合、（たとえば、構成されたポリシーを介して）照会するdCDNとそれらを照会する順序を決定するのはuCDNです。ローカルポリシーに基づく優先dCDNの選択、最初のdCDNがリダイレクトターゲットを返さない、またはuCDNのRI要求を拒否した場合の代替dCDNのクエリへのフォールバックなど、いくつかの戦略が可能です。より複雑な戦略は、1つを選択し、そのdCDNによって提供されるリダイレクトターゲットを使用する前に、複数のdCDNを同時にクエリすることです。
The uCDN->User Agent redirection protocols addressed in this document are: DNS redirection and HTTP redirection. Other types of application-level redirection will not be discussed further in this document. However, the Redirection interface is designed to be extensible and could be extended to support additional application-level redirection protocols.
このドキュメントで扱うuCDN-> User Agentリダイレクトプロトコルは、DNSリダイレクトとHTTPリダイレクトです。他のタイプのアプリケーションレベルのリダイレクトについては、このドキュメントではこれ以上説明しません。ただし、リダイレクトインターフェイスは拡張できるように設計されており、アプリケーションレベルの追加リダイレクトプロトコルをサポートするように拡張できます。
For both DNS and HTTP redirection, either HTTP or HTTPS could be used to connect to the Redirection Target. When HTTPS is used to connect to the uCDN, if the uCDN uses DNS redirection to identify the RT to the User Agent, then the new target domain name may not match the domain in the URL dereferenced to reach the uCDN; without operational precautions, and in the absence of DNSSEC, this can make a legitimate redirection look like a DNS-based attack to a User Agent and trigger security warnings. When DNS-based redirection with HTTPS is used, this specification assumes that any RT can complete the necessary Transport Layer Security (TLS) handshake with the User Agent. Any operational mechanisms this requires, e.g., private key distribution to surrogates and request routers in dCDNs, are outside the scope of this document.
DNSリダイレクトとHTTPリダイレクトの両方で、HTTPまたはHTTPSを使用してリダイレクトターゲットに接続できます。 uCDNへの接続にHTTPSが使用されている場合、uCDNがDNSリダイレクトを使用してユーザーエージェントへのRTを識別すると、新しいターゲットドメイン名は、uCDNに到達するために参照解除されたURLのドメインと一致しない場合があります。運用上の予防策がなく、DNSSECがない場合、これにより、正当なリダイレクトがユーザーエージェントに対するDNSベースの攻撃のようになり、セキュリティ警告がトリガーされる可能性があります。 HTTPSを使用したDNSベースのリダイレクトが使用される場合、この仕様では、RTがユーザーエージェントとの必要なトランスポート層セキュリティ（TLS）ハンドシェイクを完了できると想定しています。これが必要とする操作メカニズム、たとえば、dCDNの代理および要求ルーターへの秘密鍵の配布は、このドキュメントの範囲外です。
This document also defines an RI loop prevention and detection mechanism as part of the Redirection interface.
このドキュメントでは、リダイレクトループの防止および検出メカニズムをリダイレクトインターフェイスの一部として定義しています。
This document defines a simple interface for the Redirection interface based on HTTP [RFC7230], where the attributes of a User Agent's requests are encapsulated along with any other data that can aid the dCDN in processing the requests. The RI response encapsulates the attributes of the RT(s) that the uCDN should return to the User Agent (if it decides to utilize the dCDN for delivery) along with the policy for how the response can be reused. The examples of RI requests and responses below do not contain a complete set of HTTP headers for brevity; only the pertinent HTTP headers are shown.
このドキュメントでは、HTTP [RFC7230]に基づくリダイレクトインターフェースのシンプルなインターフェースを定義します。ユーザーエージェントのリクエストの属性は、dCDNがリクエストを処理するのに役立つ他のデータとともにカプセル化されます。 RI応答は、uCDNがユーザーエージェントに返す必要があるRTの属性（配信にdCDNを利用する場合）と、応答の再利用方法に関するポリシーをカプセル化します。以下のRI要求と応答の例には、簡潔にするためにHTTPヘッダーの完全なセットは含まれていません。関連するHTTPヘッダーのみが表示されます。
The RI between the uCDN and dCDN uses the same HTTP interface to encapsulate the attributes of both DNS and HTTP requests received from User Agents, although the contents of the RI requests/responses contain data specific to either DNS or HTTP redirection.
uCDNとdCDN間のRIは、同じHTTPインターフェースを使用して、ユーザーエージェントから受信したDNSとHTTP要求の両方の属性をカプセル化しますが、RI要求/応答の内容には、DNSまたはHTTPリダイレクトに固有のデータが含まれます。
This approach has been chosen because it enables CDN operators to only have to deploy a single interface for the RI between their CDNs, regardless of the User Agent redirection method. In this way, from an operational point of view, there is only one interface to monitor, manage, develop troubleshooting tools for, etc.
このアプローチが選択されたのは、ユーザーエージェントのリダイレクト方法に関係なく、CDNオペレーターがCDN間にRIの単一のインターフェースをデプロイするだけで済むためです。このように、運用の観点からは、監視、管理、トラブルシューティングツールの開発などを行うためのインターフェイスは1つだけです。
In addition, having a single RI where the attributes of the User Agent's DNS or HTTP request are encapsulated along with the other data required for the dCDN to make a request routing decision, avoids having to both 1) try to encapsulate or proxy DNS/HTTP/RTMP/ etc. requests and 2) find ways to somehow embed the additional CDNI Request Routing Redirection interface properties/data within those end-user DNS/HTTP/RTMP/etc. requests.
さらに、ユーザーエージェントのDNSまたはHTTPリクエストの属性が、dCDNがリクエストルーティングの決定を行うために必要な他のデータと共にカプセル化される単一のRIを持つことで、1）DNS / HTTPのカプセル化またはプロキシの試行/ RTMP /などのリクエスト、および2）エンドユーザーのDNS / HTTP / RTMP / etc内に追加のCDNIリクエストルーティングリダイレクトインターフェイスのプロパティ/データを何らかの方法で埋め込む方法を見つける。リクエスト。
Finally, the RI is easily extendable to support other User Agent request redirection methods (e.g., RTMP 302 redirection) by defining additional protocol-specific keys for RI requests and responses along with a specification about how to process them.
最後に、RIは簡単に拡張可能であり、RI要求と応答の追加のプロトコル固有のキーとそれらの処理方法に関する仕様を定義することにより、他のユーザーエージェント要求リダイレクト方法（RTMP 302リダイレクトなど）をサポートします。
The generic Recursive Request Redirection message flow between Request Routing systems in a pair of interconnected CDNs is as follows:
相互接続されたCDNのペアの要求ルーティングシステム間の一般的な再帰要求リダイレクトメッセージフローは次のとおりです。
User Agent CDN B RR CDN A RR
|UA Request (DNS or HTTP) | |
|-------------------------------------------------->| (1)
| | |
| |HTTP POST to CDN B's RI |
| |URI encapsulating UA |
| |request attributes |
| |<------------------------| (2)
| | |
| |HTTP Response with body |
| |containing RT attributes |
| |of the protocol-specific |
| |response to return to UA |
| |------------------------>| (3)
| | |
| Protocol-specific response (redirection)|
|<--------------------------------------------------| (4)
| | |
Figure 1: Generic Recursive Request Redirection Message Flow
図1：一般的な再帰リクエストのリダイレクトメッセージフロー
1. The User Agent sends its (DNS or HTTP) request to CDN A. The Request Routing System of CDN A processes the request and, through local policy, recognizes that the request is best served by another CDN, specifically CDN B (or that CDN B may be one of a number of candidate dCDNs it could use).
1. ユーザーエージェントは、その（DNSまたはHTTP）要求をCDN Aに送信します。CDNAの要求ルーティングシステムが要求を処理し、ローカルポリシーを通じて、その要求が別のCDN、具体的にはCDN B（またはそのCDN B）によって最適に処理されることを認識します。使用できるdCDNの候補の1つである場合があります）。
2. The Request Routing System of CDN A sends an HTTP POST to CDN B's RI URI containing the attributes of the User Agent's request.
2. CDN Aのリクエストルーティングシステムは、ユーザーエージェントのリクエストの属性を含むHTTP POSTをCDN BのRI URIに送信します。
3. The Request Routing System of CDN B processes the RI request and, assuming the request is well-formed, responds with an HTTP "200" response with a message body containing the RT(s) to return to the User Agent as well as parameters that indicate the properties of the response (cacheability and scope).
3. CDN BのリクエストルーティングシステムはRIリクエストを処理し、リクエストが適切な形式であると想定して、RT "s"を含むメッセージ本文を含むHTTP "200"レスポンスで応答し、ユーザーエージェントと、応答のプロパティを示します（キャッシュ可能性とスコープ）。
4. The Request Routing System of CDN A sends a protocol-specific response (containing the returned attributes) to the User Agent, so that the User Agent's request will be redirected to the RT(s) returned by CDN B.
4. CDN Aのリクエストルーティングシステムは、返された属性を含むプロトコル固有の応答をユーザーエージェントに送信します。これにより、ユーザーエージェントのリクエストは、CDN Bから返されたRTにリダイレクトされます。
The information passed in RI requests splits into two basic categories:
RIリクエストで渡される情報は、2つの基本的なカテゴリに分かれます。
1. The attributes of the User Agent's request to the uCDN.
1. uCDNに対するユーザーエージェントのリクエストの属性。
2. Properties/parameters that the uCDN can use to control the dCDN's response or that can help the dCDN make its decision.
2. uCDNがdCDNの応答を制御するために使用できる、またはdCDNが決定を行うのを助けることができるプロパティ/パラメーター。
Generally, dCDNs can provide better routing decisions given additional information about the content request, e.g., the URI of the requested content or the User Agent's IP address or subnet. The information required to base a routing decision on can be highly dependent on the type of content delivered. A uCDN SHOULD only include information that is absolutely necessary for delivering that type of content. Cookies in particular are especially sensitive from a security/privacy point of view and in general SHOULD NOT be conveyed in the RI Requests to the dCDN. The information necessary to be conveyed for a particular type of request is expected to be conveyed out of band between the uCDN and dCDN. See Section 5.2 for more detail on the privacy aspects of using RI Requests to convey information about UA requests.
一般に、dCDNは、要求されたコンテンツのURIやユーザーエージェントのIPアドレスやサブネットなど、コンテンツ要求に関する追加情報が与えられれば、より適切なルーティング決定を提供できます。ルーティングを決定するために必要な情報は、配信されるコンテンツのタイプによって大きく異なります。 uCDNには、そのタイプのコンテンツを配信するために絶対に必要な情報のみを含める必要があります（SHOULD）。特にCookieはセキュリティ/プライバシーの観点から特に機密性が高く、一般にRIリクエストでdCDNに伝達すべきではありません。特定のタイプのリクエストで伝達する必要がある情報は、uCDNとdCDNの間で帯域外で伝達されることが期待されています。 RIリクエストを使用してUAリクエストに関する情報を伝達するプライバシーの側面の詳細については、セクション5.2を参照してください。
In order for the dCDN to determine whether it is capable of delivering any requested content, it requires CDNI metadata related to the content the User Agent is requesting. That metadata will describe the content and any policies associated with it. It is expected that the RI request contains sufficient information for the Request Router in the dCDN to be able to retrieve the required CDNI Metadata via the CDNI Metadata interface.
dCDNが要求されたコンテンツを配信できるかどうかを判断するには、ユーザーエージェントが要求しているコンテンツに関連するCDNIメタデータが必要です。そのメタデータは、コンテンツとそれに関連付けられたポリシーを記述します。 RI要求には、dCDN内の要求ルーターがCDNIメタデータインターフェースを介して必要なCDNIメタデータを取得できるようにするための十分な情報が含まれていることが期待されます。
The information passed in RI responses splits into two basic categories:
RI応答で渡される情報は、2つの基本的なカテゴリに分かれます。
1. The attributes of the RT to return to the User Agent in the DNS response or HTTP response.
1. DNS応答またはHTTP応答でユーザーエージェントに返すRTの属性。
2. Parameters/policies that indicate the properties of the response, such as, whether it is cacheable, the scope of the response, etc.
2. キャッシュ可能かどうか、応答のスコープなど、応答のプロパティを示すパラメータ/ポリシー。
In addition to details about how to redirect the User Agent, the dCDN may wish to return additional policy information to the uCDN. For example, the dCDN may wish to return a policy that expresses "this response can be reused without requiring an RI request for 60 seconds provided the User Agent's IP address is in the range 198.51.100.0 -- 198.51.100.255".
ユーザーエージェントをリダイレクトする方法の詳細に加えて、dCDNは追加のポリシー情報をuCDNに返したい場合があります。たとえば、dCDNは、「ユーザーエージェントのIPアドレスが198.51.100.0から198.51.100.255の範囲内にある場合、RIリクエストを60秒間要求せずにこの応答を再利用できます」を表すポリシーを返したい場合があります。
These additional policies split into two basic categories:
これらの追加ポリシーは、2つの基本的なカテゴリに分かれています。
o Cacheability information signaled via the HTTP response headers of the RI response (to reduce the number of subsequent RI requests the uCDN needs to make).
o RI応答のHTTP応答ヘッダーを介して通知されるキャッシュ可能性情報（uCDNが行う必要がある後続のRI要求の数を減らすため）。
o The scope of a cacheable response signaled in the HTTP response body of the RI response, for example, whether the response applies to a wider range of IP addresses than what was included in the RI request.
o RI応答のHTTP応答本文で通知されるキャッシュ可能な応答のスコープ。たとえば、応答がRI要求に含まれていたものよりも広い範囲のIPアドレスに適用されるかどうか。
The cacheability of the response is indicated using the standard HTTP Cache-Control mechanisms.
応答のキャッシュ可能性は、標準のHTTPキャッシュ制御メカニズムを使用して示されます。
The body of RI requests and responses is a JSON object [RFC7159] that contains a dictionary of key:value pairs that MUST conform to [RFC7493]. Senders MUST encode all (top-level object and sub-object) keys specified in this document in lowercase. Receivers MUST ignore any keys that are unknown or invalid.
RI要求と応答の本体は、[RFC7493]に準拠する必要があるキーと値のペアのディクショナリを含むJSONオブジェクト[RFC7159]です。送信者は、このドキュメントで指定されているすべての（トップレベルのオブジェクトとサブオブジェクト）キーを小文字でエンコードする必要があります。受信者は、不明または無効なキーを無視する必要があります。
The following table defines the top-level keys and indicates whether they are applicable to RI requests, RI responses, or both:
次の表は、トップレベルのキーを定義し、それらがRI要求、RI応答、またはその両方に適用可能かどうかを示しています。
+----------+------------------+-------------------------------------+
| Key | Request/Response | Description |
+----------+------------------+-------------------------------------+
| dns | Both | The attributes of the UA's DNS |
| | | request or the attributes of the |
| | | RT(s) to return in a DNS response. |
| | | |
| http | Both | The attributes of the UA's HTTP |
| | | request or the attributes of the RT |
| | | to return in an HTTP response. |
| | | |
| scope | Response | The scope of the response (if it is |
| | | cacheable). For example, whether |
| | | the response applies to a wider |
| | | range of IP addresses than what was |
| | | included in the RI request. |
| | | |
| error | Response | Additional details if the response |
| | | is an error response. |
| | | |
| cdn-path | Both | A List of Strings. Contains a list |
| | | of the CDN Provider IDs of previous |
| | | CDNs that have participated in the |
| | | request routing for the associated |
| | | User Agent request. On RI requests, |
| | | it contains the list of previous |
| | | CDNs that this RI request has |
| | | passed through. On RI responses, it |
| | | contains the list of CDNs that were |
| | | involved in obtaining the final |
| | | redirection included in the RI |
| | | response. See Section 4.8. |
| | | |
| max-hops | Request | Integer specifying the maximum |
| | | number of hops (CDN Provider IDs) |
| | | this request is allowed to be |
| | | propagated along. This allows the |
| | | uCDN to coarsely constrain the |
| | | latency of the request routing |
| | | chain. |
+----------+------------------+-------------------------------------+
Table 1: Top-Level Keys in RI Requests/Responses
表1：RI要求/応答の最上位キー
A single request or response MUST contain only one of the dns or http keys. Requests MUST contain a cdn-path key and responses MAY contain a cdn-path key. If the max-hops key is not present, then there is no limit on the number of CDN hops that the RI request can be propagated along. If the first uCDN does not wish the RI request to be propagated beyond the dCDN it is making the request to, then the uCDN MUST set max-hops to 1.
単一の要求または応答には、dnsまたはhttpキーのいずれか1つのみを含める必要があります。要求にはcdn-pathキーが含まれている必要があり、応答にはcdn-pathキーが含まれている場合があります。 max-hopsキーが存在しない場合、RI要求を伝搬できるCDNホップの数に制限はありません。最初のuCDNがRI要求が要求を行っているdCDNを超えて伝播されることを望まない場合、uCDNはmax-hopsを1に設定する必要があります。
The cdn-path MAY be reflected back in RI responses, although doing so could expose information to the uCDN that a dCDN may not wish to expose (for example, the existence of business relationships between a dCDN and other CDNs).
cdn-pathはRI応答に反映される可能性がありますが、そうすると、dCDNが公開したくない情報をuCDNに公開する可能性があります（たとえば、dCDNと他のCDN間のビジネス関係の存在）。
If the cdn-path is reflected back in the RI response, it MUST contain the value of cdn-path received in the associated RI request with the final dCDN's CDN Provider ID appended. Transit CDNs MAY remove the cdn-path from RI responses but MUST NOT modify the cdn-path in other ways.
cdn-pathがRI応答に反映されている場合、関連付けられたRI要求で受信されたcdn-pathの値と最後のdCDNのCDNプロバイダーIDが付加されている必要があります。中継CDNはRI応答からcdn-pathを削除してもよいが、他の方法でcdn-pathを変更してはならない（MUST NOT）。
The presence of an error key within a response that also contains either a dns or http key does not automatically indicate that the RI request was unsuccessful as the error key MAY be used for communicating additional (e.g., debugging) information. When a response contains an error key as well as either a dns or http key, the error-code SHOULD be 1xx (e.g., 100). See Section 4.7 for more details about encoding error information in RI responses.
dnsまたはhttpキーのいずれかを含む応答内のエラーキーの存在は、エラーキーが追加（デバッグなど）情報の通信に使用される可能性があるため、RIリクエストが失敗したことを自動的に示すわけではありません。応答にエラーキーとdnsまたはhttpキーのいずれかが含まれている場合、エラーコードは1xx（例：100）である必要があります。 RI応答のエラー情報のエンコードの詳細については、セクション4.7を参照してください。
All implementations that support IPv4 addresses MUST support the encoding specified by the 'IPv4address' rule in Section 3.2.2 of [RFC3986]. Likewise, implementations that support IPv6 addresses MUST support all IPv6 address formats specified in [RFC4291]. Server implementations SHOULD use IPv6 address formats specified in [RFC5952].
IPv4アドレスをサポートするすべての実装は、[RFC3986]のセクション3.2.2の「IPv4address」ルールで指定されたエンコーディングをサポートする必要があります。同様に、IPv6アドレスをサポートする実装は、[RFC4291]で指定されているすべてのIPv6アドレス形式をサポートする必要があります。サーバーの実装は[RFC5952]で指定されたIPv6アドレス形式を使用する必要があります（SHOULD）。
RI requests MUST use a MIME media type of application/cdni as specified in [RFC7736], with the Payload Type (ptype) parameter set to 'redirection-request'.
RIリクエストは、[RFC7736]で指定されているペイロードタイプ（ptype）パラメータを 'redirection-request'に設定して、application / cdniのMIMEメディアタイプを使用する必要があります。
RI responses MUST use a MIME media type of application/cdni as specified in [RFC7736], with the Payload Type (ptype) parameter set to 'redirection-response'.
RI応答は、ペイロードタイプ（ptype）パラメータを 'redirection-response'に設定して、[RFC7736]で指定されているように、application / cdniのMIMEメディアタイプを使用する必要があります。
The following sections provide detailed descriptions of the information that should be passed in RI requests and responses for DNS redirection.
以下のセクションでは、DNSリダイレクトのRI要求と応答で渡される必要がある情報の詳細な説明を提供します。
For DNS-based redirection, the uCDN needs to pass the following information to the dCDN in the RI request:
DNSベースのリダイレクトの場合、uCDNは次の情報をRIリクエストでdCDNに渡す必要があります。
o The IP address of the DNS resolver that made the DNS request to the uCDN.
o uCDNにDNS要求を行ったDNSリゾルバーのIPアドレス。
o The type of DNS query made (usually either A or AAAA).
o 作成されたDNSクエリのタイプ（通常はAまたはAAAA）。
o The class of DNS query made (usually IN).
o 作成されたDNSクエリのクラス（通常はIN）。
o The fully qualified domain name for which DNS redirection is being requested.
o DNSリダイレクトが要求されている完全修飾ドメイン名。
o The IP address or prefix of the User Agent (if known to the uCDN).
o ユーザーエージェントのIPアドレスまたはプレフィックス（uCDNで認識されている場合）。
The preceding information is encoded as a set of key:value pairs within the dns dictionary as follows:
上記の情報は、dns辞書内で次のようにキーと値のペアのセットとしてエンコードされます。
+-------------+---------+-----------+-------------------------------+
| Key | Value | Mandatory | Description |
+-------------+---------+-----------+-------------------------------+
| resolver-ip | String | Yes | The IP address of the UA's |
| | | | DNS resolver. |
| | | | |
| qtype | String | Yes | The type of DNS query made by |
| | | | the UA's DNS resolvers in |
| | | | uppercase. The value of this |
| | | | field SHALL be set to either |
| | | | 'A' or 'AAAA'. |
| | | | |
| qclass | String | Yes | The class of DNS query made |
| | | | in uppercase (IN, etc.). |
| | | | |
| qname | String | Yes | The fully qualified domain |
| | | | name being queried. |
| | | | |
| c-subnet | String | No | The IP address (or prefix) of |
| | | | the UA in Classless Inter- |
| | | | Domain Routing (CIDR) format. |
| | | | |
| dns-only | Boolean | No | If True, then dCDN MUST only |
| | | | use DNS redirection and MUST |
| | | | include RTs to one or more |
| | | | surrogates in any successful |
| | | | RI response. CDNs MUST |
| | | | include the dns-only property |
| | | | set to True on any cascaded |
| | | | RI requests. Defaults to |
| | | | False. |
+-------------+---------+-----------+-------------------------------+
Table 2
表2
An RI request for DNS-based redirection MUST include a dns dictionary. This dns dictionary MUST contain the following keys: resolver-ip, qtype, qclass, and qname; the value of each MUST be the value of the appropriate part of the User Agent's DNS query/request. For internationalized domain names containing non-ASCII characters, the value of the qname field MUST be the ASCII-compatible encoded (ACE) representation (A-label) of the domain name [RFC5890].
DNSベースのリダイレクトのRI要求には、dns辞書を含める必要があります。このDNS辞書には、次のキーが含まれている必要があります。resolver-ip、qtype、qclass、およびqname。それぞれの値は、ユーザーエージェントのDNSクエリ/リクエストの適切な部分の値でなければなりません。非ASCII文字を含む国際化ドメイン名の場合、qnameフィールドの値は、ドメイン名[RFC5890]のASCII互換のエンコード（ACE）表現（Aラベル）でなければなりません（MUST）。
An example RI request (uCDN->dCDN) for DNS-based redirection is as follows:
DNSベースのリダイレクトのTO要求の例（CDN-> CDN）は次のとおりです。
POST /dcdn/ri HTTP/1.1
Host: rr1.dcdn.example.net
Content-Type: application/cdni; ptype=redirection-request
Accept: application/cdni; ptype=redirection-response
{
"dns" : {
"resolver-ip" : "192.0.2.1",
"c-subnet" : "198.51.100.0/24",
"qtype" : "A",
"qclass" : "IN",
"qname" : "www.example.com"
},
"cdn-path": ["AS64496:0"],
"max-hops": 3
}
For a successful DNS-based redirection, the dCDN needs to return one of the following to the uCDN in the RI response:
DNSベースのリダイレクトを成功させるには、dCDNがRI応答でuCDNに次のいずれかを返す必要があります。
o The IP address(es) of (or the CNAME of) RTs that are dCDN surrogates (if the dCDN is performing DNS-based redirection directly to a surrogate); or
o dCDNサロゲートであるRTのIPアドレス（またはCNAME）（dCDNがサロゲートへ直接DNSベースのリダイレクトを実行している場合）。または
o The IP address(es) of (or the CNAME of) RTs that are Request Routers (if the dCDN will perform request redirection itself). A dCDN MUST NOT return an RT that is a Request Router if the dns-only key is set to True in the RI request.
o リクエストルーターであるRTのIPアドレス（またはCNAME）（dCDNがリクエストリダイレクト自体を実行する場合）。 RI要求でdns-onlyキーがTrueに設定されている場合、dCDNは要求ルーターであるRTを返してはなりません（MUST NOT）。
The preceding information is encoded as a set of key:value pairs within the dns dictionary as follows:
上記の情報は、dns辞書内で次のようにキーと値のペアのセットとしてエンコードされます。
+-------+-----------+-----------+-----------------------------------+
| Key | Value | Mandatory | Description |
+-------+-----------+-----------+-----------------------------------+
| rcode | Integer | Yes | DNS response code (see |
| | | | [RFC6895]). |
| | | | |
| name | String | Yes | The fully qualified domain name |
| | | | the response relates to. |
| | | | |
| a | List of | No | Set of IPv4 Addresses of RT(s). |
| | String | | |
| | | | |
| aaaa | List of | No | Set of IPv6 Addresses of RT(s). |
| | String | | |
| | | | |
| cname | List of | No | Set of fully qualified domain |
| | String | | names of RT(s). |
| | | | |
| ttl | Integer | No | TTL in seconds of DNS response. |
| | | | Default is 0. |
+-------+-----------+-----------+-----------------------------------+
Table 3
表3
A successful RI response for DNS-based redirection MUST include a dns dictionary and MAY include an error dictionary (see Section 4.7). An unsuccessful RI response for DNS-based redirection MUST include an error dictionary. If a dns dictionary is included in the RI response, it MUST include the rcode and name keys and it MUST include at least one of the following keys: a, aaaa, or cname. The dns dictionary MAY include both a and aaaa keys. If the dns dictionary contains a cname key, it MUST NOT contain either an a or aaaa key. For internationalized domain names containing non-ASCII characters, the value of the cname field MUST be the ACE representation (A-label) of the domain name.
DNSベースのリダイレクトに対する正常なRI応答には、dns辞書を含める必要があり、エラー辞書を含めることができます（セクション4.7を参照）。 DNSベースのリダイレクトの失敗したRI応答には、エラーディクショナリを含める必要があります。 DNS辞書がRI応答に含まれている場合、rcodeキーと名前キーを含める必要があり、次のキーの少なくとも1つを含める必要があります：a、aaaa、またはcname。 DNSディクショナリには、aキーとaaaaキーの両方が含まれる場合があります。 DNSディクショナリにcnameキーが含まれている場合は、aキーまたはaaaaキーのいずれかが含まれていてはなりません。非ASCII文字を含む国際化ドメイン名の場合、cnameフィールドの値は、ドメイン名のACE表現（Aラベル）でなければなりません。
An example of a successful RI response (dCDN->uCDN) for DNS-based redirection with both a and aaaa keys is listed below:
aキーとaaaaキーの両方を使用したDNSベースのリダイレクトで成功したRI応答の例（dCDN-> uCDN）を以下に示します。
HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni; ptype=redirection-response
{
"dns" : {
"rcode" : 0,
"name" : "www.example.com",
"a" : ["203.0.113.200", "203.0.113.201", "203.0.113.202"],
"aaaa" : ["2001:DB8::C8", "2001:DB8::C9"],
"ttl" : 60
}
}
A further example of a successful RI response (dCDN->uCDN) for DNS-based redirection is listed below, in this case with a cname key containing the FQDN of the RT.
DNSベースのリダイレクトの成功したRI応答（dCDN-> uCDN）のさらなる例を以下に示します。この場合は、RTのFQDNを含むcnameキーを使用しています。
HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni; ptype=redirection-response
{
"dns" : {
"rcode" : 0,
"name" : "www.example.com",
"cname" : ["rr1.dcdn.example"],
"ttl" : 20
}
}
The following sections provide detailed descriptions of the information that should be passed in RI requests and responses for HTTP redirection.
次のセクションでは、HTTPリダイレクトのRI要求と応答で渡される必要がある情報について詳しく説明します。
The dictionary keys used in HTTP Redirection requests and responses use the following conventions for their prefixes:
HTTPリダイレクトの要求と応答で使用されるディクショナリキーは、プレフィックスに次の規則を使用します。
o c- is prefixed to keys for information related to the Client (User Agent).
o c-は、クライアント（ユーザーエージェント）に関連する情報のキーの前に付けられます。
o cs- is prefixed to keys for information passed by the Client (User Agent) to the Server (uCDN).
o cs-は、クライアント（ユーザーエージェント）からサーバー（uCDN）に渡される情報のキーの前に付けられます。
o sc- is prefixed to keys for information to be passed by the Server (uCDN) to the Client (User Agent).
o sc-は、サーバー（uCDN）からクライアント（ユーザーエージェント）に渡される情報のキーの前に付けられます。
For HTTP-based redirection, the uCDN needs to pass the following information to the dCDN in the RI request:
HTTPベースのリダイレクトの場合、uCDNは次の情報をRIリクエストでdCDNに渡す必要があります。
o The IP address of the User Agent.
o ユーザーエージェントのIPアドレス。
o The URI requested by the User Agent.
o ユーザーエージェントによって要求されたURI。
o The HTTP method requested by the User Agent.
o ユーザーエージェントによって要求されたHTTPメソッド。
o The HTTP version number requested by the User Agent.
o ユーザーエージェントによって要求されたHTTPバージョン番号。
The uCDN may also decide to pass the presence and value of particular HTTP headers included in the User Agent request to the dCDN.
uCDNは、ユーザーエージェント要求に含まれる特定のHTTPヘッダーの存在と値をdCDNに渡すことも決定します。
The preceding information is encoded as a set of key:value pairs within the http dictionary as follows:
上記の情報は、次のようにhttp辞書内のキーと値のペアのセットとしてエンコードされます。
+-------------------+--------+-----------+--------------------------+
| Key | Value | Mandatory | Description |
+-------------------+--------+-----------+--------------------------+
| c-ip | String | Yes | The IP address of the |
| | | | UA. |
| | | | |
| cs-uri | String | Yes | The Effective Request |
| | | | URI [RFC7230] requested |
| | | | by the UA. |
| | | | |
| cs-method | String | Yes | The method part of the |
| | | | request-line as defined |
| | | | in Section 3.1.1 of |
| | | | [RFC7230]. |
| | | | |
| cs-version | String | Yes | The HTTP-version part of |
| | | | the request-line as |
| | | | defined in Section 3.1.1 |
| | | | of [RFC7230]. |
| | | | |
| cs-(<headername>) | String | No | The field-value of the |
| | | | HTTP header field named |
| | | | <HeaderName> as a |
| | | | string, for example, |
| | | | cs-(cookie) would |
| | | | contain the value of the |
| | | | HTTP Cookie header from |
| | | | the UA request. |
+-------------------+--------+-----------+--------------------------+
Table 4
表4
An RI request for HTTP-based redirection MUST include an http dictionary. This http dictionary MUST contain the following keys: c-ip, cs-method, cs-version, and cs-uri; the value of each MUST be the value of the appropriate part of the User Agent's HTTP request.
HTTPベースのリダイレクトのRIリクエストには、http辞書を含める必要があります。このhttp辞書には、c-ip、cs-method、cs-version、cs-uriのキーが含まれている必要があります。それぞれの値は、ユーザーエージェントのHTTPリクエストの適切な部分の値でなければなりません。
The http dictionary of an RI request MUST contain a maximum of one cs-(<headername>) key for each unique header field-name (HTTP header field). <headername> MUST be identical to the equivalent HTTP header field-name encoded in all lowercase.
RIリクエストのhttp辞書には、一意のヘッダーフィールド名（HTTPヘッダーフィールド）ごとに最大1つのcs-（<headername>）キーを含める必要があります。 <headername>は、すべて小文字でエンコードされた同等のHTTPヘッダーフィールド名と同一である必要があります。
In the case where the User Agent request includes multiple HTTP header fields with the same field-name, it is RECOMMENDED that the uCDN combine these different HTTP headers into a single value according to Section 3.2.2 of [RFC7230]. However, because of the plurality of already defined HTTP header fields and the inconsistency of some of these header fields concerning the combination mechanism defined in RFC 7230, the uCDN MAY have to deviate from using the combination mechanism where appropriate. For example, it might only send the contents of the first occurrence of the HTTP Headers instead.
ユーザーエージェントリクエストに同じフィールド名の複数のHTTPヘッダーフィールドが含まれている場合、[RFC7230]のセクション3.2.2に従って、uCDNがこれらの異なるHTTPヘッダーを単一の値に結合することをお勧めします。ただし、RFC 7230で定義された組み合わせメカニズムに関する複数のすでに定義されたHTTPヘッダーフィールドとこれらのヘッダーフィールドの一部の不整合のため、uCDNは、必要に応じて組み合わせメカニズムの使用から逸脱する必要があります。たとえば、代わりに最初のHTTPヘッダーのコンテンツのみを送信する場合があります。
An example RI request (uCDN->dCDN) for HTTP-based redirection is as follows:
HTTPベースのリダイレクトのRIリクエストの例（uCDN-> dCDN）は次のとおりです。
POST /dcdn/rrri HTTP/1.1
Host: rr1.dcdn.example.net
Content-Type: application/cdni; ptype=redirection-request
Accept: application/cdni; ptype=redirection-response
{
"http": {
"c-ip": "198.51.100.1",
"cs-uri": "http://www.example.com",
"cs-version": "HTTP/1.1",
"cs-method": "GET"
},
"cdn-path": ["AS64496:0"],
"max-hops": 3
}
For a successful HTTP-based redirection, the dCDN needs to return one of the following to the uCDN in the RI response:
HTTPベースのリダイレクトを成功させるには、dCDNがRI応答でuCDNに次のいずれかを返す必要があります。
o A URI pointing to an RT that is the selected dCDN surrogate(s) (if the dCDN is performing HTTP-based redirection directly to a surrogate); or
o 選択されたdCDNサロゲートであるRTを指すURI（dCDNがサロゲートへのHTTPベースのリダイレクトを直接実行している場合）。または
o A URI pointing to an RT that is a Request Router (if the dCDN will perform request redirection itself).
o リクエストルーターであるRTを指すURI（dCDNがリクエストリダイレクト自体を実行する場合）。
The preceding information is encoded as a set of key:value pairs within the http dictionary as follows:
上記の情報は、次のようにhttp辞書内のキーと値のペアのセットとしてエンコードされます。
+-------------------+---------+-----------+-------------------------+
| Key | Value | Mandatory | Description |
+-------------------+---------+-----------+-------------------------+
| sc-status | Integer | Yes | The status-code part of |
| | | | the status-line as |
| | | | defined in Section |
| | | | 3.1.2 of [RFC7230] to |
| | | | return to the UA |
| | | | (usually set to 302). |
| | | | |
| sc-version | String | Yes | The HTTP-version part |
| | | | of the status-line as |
| | | | defined in Section |
| | | | 3.1.2 of [RFC7230] to |
| | | | return to the UA. |
| | | | |
| sc-reason | String | Yes | The reason-phrase part |
| | | | of the status-line as |
| | | | defined in Section |
| | | | 3.1.2 of [RFC7230] to |
| | | | return to the UA. |
| | | | |
| cs-uri | String | Yes | The URI requested by |
| | | | the UA/client. |
| | | | |
| sc-(location) | String | Yes | The contents of the |
| | | | Location header to |
| | | | return to the UA (i.e., |
| | | | a URI pointing to the |
| | | | RT(s)). |
| | | | |
| sc-(<headername>) | String | No | The field-value of the |
| | | | HTTP header field named |
| | | | <HeaderName> to return |
| | | | to the UA. For example, |
| | | | sc-(expires) would |
| | | | contain the value of |
| | | | the HTTP Expires |
| | | | header. |
+-------------------+---------+-----------+-------------------------+
Table 5
表5
Note: The sc-(location) key in the preceding table is an example of sc-(<headername>) that has been called out separately as its presence is mandatory in RI responses.
注：上記の表のsc-（location）キーは、RI応答での存在が必須であるため、個別に呼び出されるsc-（<headername>）の例です。
A successful RI response for HTTP-based redirection MUST include an http dictionary and MAY include an error dictionary (see Section 4.7). An unsuccessful RI response for HTTP-based redirection MUST include an error dictionary. If an http dictionary is included in the RI response, it MUST include at least the following keys: sc-status, sc-version, sc-reason, cs-uri, and sc-(location).
HTTPベースのリダイレクトの成功したRI応答には、http辞書を含める必要があり、エラー辞書を含めることができます（セクション4.7を参照）。 HTTPベースのリダイレクトの失敗したRI応答には、エラーディクショナリを含める必要があります。 http辞書がRI応答に含まれている場合、少なくとも以下のキーを含める必要があります：sc-status、sc-version、sc-reason、cs-uri、およびsc-（location）。
The http dictionary of an RI response MUST contain a maximum of one sc-(<headername>) key for each unique header field-name (HTTP header field). <headername> MUST be identical to the equivalent HTTP header field-name encoded in all lowercase.
RI応答のhttp辞書には、一意のヘッダーフィールド名（HTTPヘッダーフィールド）ごとに最大1つのsc-（<headername>）キーを含める必要があります。 <headername>は、すべて小文字でエンコードされた同等のHTTPヘッダーフィールド名と同一である必要があります。
The uCDN MAY decide to not return, override, or alter any or all of the HTTP headers defined by sc-(<headername>) keys before sending the HTTP response to the UA. It should be noted that in some cases, sending the HTTP Headers indicated by the dCDN transparently on to the UA might result in, for the uCDN, undesired behavior. As an example, the dCDN might include sc-(cache-control), sc-(last-modified), and sc-(expires) keys in the http dictionary, through which the dCDN may try to influence the cacheability of the response by the UA. If the uCDN would pass these HTTP headers on to the UA, this could mean that further requests from the uCDN would go directly to the dCDN, bypassing the uCDN and any logging it may perform on incoming requests. Therefore, the uCDN is recommended to carefully consider which HTTP headers to pass on, and which to either override or not pass on at all.
uCDNは、UAにHTTP応答を送信する前に、sc-（<headername>）キーで定義された一部またはすべてのHTTPヘッダーを返さない、上書きしない、または変更しないことを決定できます（MAY）。場合によっては、dCDNによって示されたHTTPヘッダーを透過的にUAに送信すると、uCDNにとって望ましくない動作が発生する可能性があることに注意してください。例として、dCDNにはhttp辞書のsc-（cache-control）、sc-（last-modified）、およびsc-（expires）キーが含まれる場合があり、dCDNはこれらのキーを使用して応答のキャッシュ可能性に影響を与えようとします。 UA。 uCDNがこれらのHTTPヘッダーをUAに渡す場合、これは、uCDNからの以降の要求が直接dCDNに送られ、uCDNと、それが着信要求で実行するロギングをバイパスすることを意味します。したがって、uCDNでは、どのHTTPヘッダーを渡すか、どのHTTPヘッダーをオーバーライドするか、まったく渡さないかを慎重に検討することをお勧めします。
An example of a successful RI response (dCDN->uCDN) for HTTP-based redirection is a follows:
HTTPベースのリダイレクトで成功したRI応答（dCDN-> uCDN）の例は次のとおりです。
HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni; ptype=redirection-response
{
"http": {
"sc-status": 302,
"sc-version": "HTTP/1.1",
"sc-reason": "Found",
"cs-uri": "http://www.example.com"
"sc-(location)":
"http://sur1.dcdn.example/ucdn/example.com",
}
}
RI responses may be cacheable. As long as a cached RI response is not stale according to standard HTTP Cache-Control or other applicable mechanisms, it may be reused by the uCDN in response to User Agent requests without sending another RI request to the dCDN.
RI応答はキャッシュ可能です。キャッシュされたRI応答が標準のHTTP Cache-Controlまたはその他の適用可能なメカニズムに従って古くならない限り、dCDNに別のRI要求を送信せずに、ユーザーエージェント要求に応答してuCDNによって再利用できます。
An RI response MUST NOT be reused unless the request from the User Agent would generate an identical RI request to the dCDN as the one that resulted in the cached RI response (except for the c-ip field provided that the User Agent's c-ip is covered by the scope in the original RI response, as elaborated upon below).
ユーザーエージェントからのリクエストが、キャッシュされたRIレスポンスをもたらしたものと同じRIリクエストをdCDNに生成しない限り、RIレスポンスを再利用してはなりません（ユーザーエージェントのc-ipが以下に詳述するように、元のRI応答の範囲でカバーされています。
Additionally, although RI requests only encode a single User Agent request to be redirected, there may be cases where a dCDN wishes to indicate to the uCDN that the RI response can be reused for other User Agent requests without the uCDN having to make another request via the RI. For example, a dCDN may know that it will always select the same surrogates for a given set of User Agent IP addresses and in order to reduce request volume across the RI or to remove the additional latency associated with an RI request, the dCDN may wish to indicate that set of User Agent IP addresses to the uCDN in the initial RI response. This is achieved by including an optional scope dictionary in the RI response.
さらに、RIリクエストはリダイレクトされる単一のユーザーエージェントリクエストのみをエンコードしますが、dCDNがuCDNに、RIレスポンスを他のユーザーエージェントリクエストに再利用できることを示したい場合があります。 RI。たとえば、dCDNは、特定のユーザーエージェントIPアドレスのセットに対して常に同じサロゲートを選択することを知っている場合があり、RI全体の要求ボリュームを減らすため、またはRI要求に関連する追加の待ち時間を削除するために、dCDNは最初のRI応答で、ユーザーエージェントIPアドレスのセットをuCDNに示すため。これは、RI応答にオプションのスコープディクショナリを含めることによって実現されます。
Scope is encoded as a set of key:value pairs within the scope dictionary as follows:
スコープは、次のようにスコープディクショナリ内のキーと値のペアのセットとしてエンコードされます。
+---------+--------+-----------+------------------------------------+
| Key | Value | Mandatory | Description |
+---------+--------+-----------+------------------------------------+
| iprange | List | No | A List of IP subnets in CIDR |
| | of | | notation that this RI response can |
| | String | | be reused for, provided the RI |
| | | | response is still considered |
| | | | fresh. |
+---------+--------+-----------+------------------------------------+
Table 6
表6
If a uCDN has multiple cached responses with overlapping scopes and a UA request comes in for which the User Agent's IP matches with the IP subnets in multiple of these cached responses, the uCDN SHOULD use the most recent cached response when determining the appropriate RI response to use.
uCDNにスコープが重複する複数のキャッシュされた応答があり、UAリクエストが受信され、ユーザーエージェントのIPがこれらの複数のキャッシュされた応答のIPサブネットと一致する場合、uCDNは適切なRI応答を決定するときに最新のキャッシュされた応答を使用する必要があります（SHOULD）。使用する。
The following is an example of a DNS redirection response from Section 4.4.2 that is cacheable by the uCDN for 30 seconds and can be returned to any User Agent with an IPv4 address in 198.51.100.0/24.
以下は、セクション4.4.2からのDNSリダイレクション応答の例です。これは、uCDNによって30秒間キャッシュ可能で、198.51.100.0 / 24のIPv4アドレスを持つ任意のユーザーエージェントに返すことができます。
HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni; ptype=redirection-response
Cache-Control: public, max-age=30
{
"dns" : {
"rcode" : 0,
"name" : "www.example.com",
"a" : ["203.0.113.200", "203.0.113.201"],
"aaaa" : ["2001:DB8::C8", "2001:DB8::C9"],
"ttl" : 60
}
"scope" : {
"iprange" : ["198.51.100.0/24"]
}
}
The following is an example of an HTTP redirection response from Section 4.5.2 that is cacheable by the uCDN for 60 seconds and can be returned to any User Agent with an IPv4 address in 198.51.100.0/24.
以下は、セクション4.5.2からのHTTPリダイレクション応答の例です。これは、uCDNによって60秒間キャッシュされ、IPv4アドレスが198.51.100.0/24の任意のユーザーエージェントに返すことができます。
Note: The response to the UA is only valid for 30 seconds, whereas the uCDN can cache the RI response for 60 seconds.
注：UAへの応答は30秒間のみ有効ですが、uCDNはRI応答を60秒間キャッシュできます。
HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni; ptype=redirection-response
Cache-Control: public, max-age=60
{
"http": {
"sc-status": 302,
"cs-uri": "http://www.example.com"
"sc-(location)":
"http://sur1.dcdn.example/ucdn/example.com",
"sc-(cache-control)" : "public, max-age=30"
}
"scope" : {
"iprange" : ["198.51.100.0/24"]
}
}
From a uCDN perspective, there are two types of errors that can be the result of the transmission of an RI request to a dCDN:
uCDNの観点からは、dCDNへのRI要求の送信の結果である可能性のある2種類のエラーがあります。
1. An HTTP protocol error signaled via an HTTP status code, indicating a problem with the reception or parsing of the RI request or the generation of the RI response by the dCDN, and
1. HTTPステータスコードを介して通知されるHTTPプロトコルエラー。RI要求の受信または解析、またはdCDNによるRI応答の生成に問題があることを示します。
2. An RI-level error specified in an RI response message.
2. RI応答メッセージで指定されたRIレベルのエラー。
This section deals with the latter type. The former type is outside the scope of this document.
このセクションでは、後者のタイプを扱います。前者のタイプはこのドキュメントの範囲外です。
There are numerous reasons for a dCDN to be unable to return an affirmative RI response to a uCDN. Reasons may include both dCDN internal issues such as capacity problems, as well as reasons outside the influence of the dCDN, such as a malformed RI request. To aid with diagnosing the cause of errors, RI responses SHOULD include an error dictionary to provide additional information to the uCDN as to the reason/cause of the error. The intention behind the error dictionary is to aid with either manual or automatic diagnosis of issues. The resolution of such issues is outside the scope of this document; this document does not specify any consequent actions a uCDN should take upon receiving a particular error-code.
dCDNが肯定的なRI応答をuCDNに返せない理由は数多くあります。理由には、容量の問題などのdCDN内部の問題と、不正なRIリクエストなどのdCDNの影響外の理由の両方が含まれます。エラーの原因の診断を支援するために、RI応答には、エラーディクショナリを含めて、エラーの理由/原因に関する追加情報をuCDNに提供する必要があります（SHOULD）。エラーディクショナリの背後にある意図は、問題の手動または自動診断を支援することです。このような問題の解決は、このドキュメントの範囲外です。このドキュメントでは、特定のエラーコードを受け取ったときにuCDNが実行する必要のあるその後のアクションは指定していません。
Error information (if present) is encoded as a set of key:value pairs within a JSON-encoded error dictionary as follows:
エラー情報（存在する場合）は、次のように、JSONエンコードされたエラーディクショナリ内のキーと値のペアのセットとしてエンコードされます。
+------------+---------+-----------+--------------------------------+
| Key | Value | Mandatory | Description |
+------------+---------+-----------+--------------------------------+
| error-code | Integer | Yes | A three-digit numeric code |
| | | | defined by the server to |
| | | | indicate the error(s) that |
| | | | occurred. |
| | | | |
| reason | String | No | A string providing further |
| | | | information related to the |
| | | | error. |
+------------+---------+-----------+--------------------------------+
Table 7
表7
The first digit of the error-code defines the class of error. There are 5 classes of errors distinguished by the first digit of the error-code:
エラーコードの最初の数字はエラーのクラスを定義します。エラーコードの最初の桁で区別されるエラーには5つのクラスがあります。
1xx: Informational (no error): The response should not be considered an error by the uCDN, which may proceed by redirecting the UA according to the values in the RI response. The error-code and accompanying description may be used for informational purposes, e.g., for logging.
1xx：情報（エラーなし）：応答はuCDNによってエラーと見なされるべきではありません。これは、RI応答の値に従ってUAをリダイレクトすることによって続行される場合があります。エラーコードと付随する説明は、ロギングなどの情報提供の目的で使用できます。
2xx: Reserved.
2xx：予約済み。
3xx: Reserved.
3xx：予約済み。
4xx: uCDN error: The dCDN cannot or will not process the request due to something that is perceived to be a uCDN error, for example, the RI request could not be parsed successfully by the dCDN. The last two-digits may be used to more specifically indicate the source of the problem.
4xx：uCDNエラー：uCDNエラーであると認識されていることが原因で、dCDNが要求を処理できない、または処理しません。たとえば、RI要求をdCDNで正常に解析できませんでした。最後の2桁は、問題の原因をより具体的に示すために使用できます。
5xx: dCDN error: Indicates that the dCDN is aware that it has erred or is incapable of satisfying the RI request for some reason, for example, the dCDN was able to parse the RI request but encountered an error for some reason. Examples include the dCDN not being able to retrieve the associated metadata or the dCDN being out of capacity.
5xx：dCDNエラー：dCDNがエラーを検出したか、何らかの理由でRI要求を満たすことができないことを示します。たとえば、dCDNはRI要求を解析できましたが、何らかの理由でエラーが発生しました。例としては、関連するメタデータを取得できないdCDNや、容量が不足しているdCDNがあります。
The following error-codes are defined and maintained by IANA (see Section 6).
以下のエラーコードは、IANAによって定義および保守されています（セクション6を参照）。
Error-codes with a "Reason" of "<reason>" do not have a defined value for their 'reason'-key. Depending on the error-code semantics, the value of this field may be determined dynamically.
「理由」が「<理由>」のエラーコードには、「理由」キーの値が定義されていません。エラーコードのセマンティクスに応じて、このフィールドの値は動的に決定される場合があります。
+------+--------------+---------------------------------------------+
| Code | Reason | Description |
+------+--------------+---------------------------------------------+
| 100 | <reason> | Generic informational error-code meant for |
| | (see | carrying a human-readable string |
| | Description) | |
| | | |
| 400 | <reason> | Generic error-code for uCDN errors where |
| | (see | the dCDN cannot or will not process the |
| | Description) | request due to something that is perceived |
| | | to be a uCDN error. The reason field may |
| | | be used to provide more details about the |
| | | source of the error. |
| | | |
| 500 | <reason> | Generic error-code for dCDN errors where |
| | (see | the dCDN is aware that it has erred or is |
| | Description) | incapable of satisfying the RI request for |
| | | some reason. The reason field may be used |
| | | to provide more details about the source of |
| | | the error. |
| | | |
| 501 | Unable to | The dCDN is unable to retrieve the metadata |
| | retrieve | associated with the content requested by |
| | metadata | the UA. This may indicate a configuration |
| | | error or that the content requested by the |
| | | UA does not exist. |
| | | |
| 502 | Loop | The dCDN detected a redirection loop (see |
| | detected | Section 4.8). |
| | | |
| 503 | Maximum hops | The dCDN detected the maximum number of |
| | exceeded | redirection hops exceeding max-hops (see |
| | | Section 4.8). |
| | | |
| 504 | Out of | The dCDN does not currently have sufficient |
| | capacity | capacity to handle the UA request. |
| | | |
| 505 | Delivery | The dCDN does not support the (set of) |
| | protocol not | delivery protocols indicated in the CDNI |
| | supported | Metadata of the content requested by the |
| | | UA. |
| | | |
| 506 | Redirection | The dCDN does not support the requested |
| | protocol not | redirection protocol. This error-code is |
| | supported | also used when the RI request has the dns- |
| | | only flag set to True and the dCDN is not |
| | | supported or is not prepared to return an |
| | | RT of a surrogate directly. |
+------+--------------+---------------------------------------------+
Table 8
表8
The following is an example of an unsuccessful RI response (dCDN->uCDN) for a DNS-based User Agent request:
以下は、DNSベースのユーザーエージェント要求に対する失敗したRI応答（dCDN-> uCDN）の例です。
HTTP/1.1 500 Internal Server Error
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni; ptype=redirection-response
Cache-Control: private, no-cache
{
"error" : {
"error-code" : 504,
"description" : "Out of capacity"
}
}
The following is an example of a successful RI response (dCDN->uCDN) for an HTTP-based User Agent request containing an error dictionary for informational purposes:
以下は、情報提供の目的でエラーディクショナリを含むHTTPベースのユーザーエージェントリクエストの成功したRI応答（dCDN-> uCDN）の例です。
HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni; ptype=redirection-response
Cache-Control: private, no-cache
{
"http": {
"sc-status": 302,
"sc-version": "HTTP/1.1",
"sc-reason": "Found",
"cs-uri": "http://www.example.com"
"sc-(location)":
"http://sur1.dcdn.example/ucdn/example.com",
},
"error" : {
"error-code" : 100,
"description" :
"This is a human-readable message meant for debugging purposes"
}
}
In order to prevent and detect RI request loops, each CDN MUST insert its CDN Provider ID into the cdn-path key of every RI request it originates or cascades. When receiving RI requests, a dCDN MUST check the cdn-path and reject any RI requests that already contain the dCDN's Provider ID in the cdn-path. Transit CDNs MUST NOT propagate to any downstream CDNs if the number of CDN Provider IDs in cdn-path (before adding its own Provider ID) is equal to or greater than max-hops.
RI要求ループを防止および検出するために、各CDNは、そのCDNプロバイダーIDを、それが発信またはカスケードするすべてのRI要求のcdn-pathキーに挿入する必要があります。 RI要求を受信するとき、dCDNはcdn-pathを確認し、cdn-pathにすでにdCDNのプロバイダーIDが含まれているRI要求を拒否する必要があります。 cdn-path内のCDNプロバイダーIDの数（独自のプロバイダーIDを追加する前）がmax-hops以上の場合、トランジットCDNはダウンストリームCDNに伝播してはなりません（MUST NOT）。
The CDN Provider ID uniquely identifies each CDN Provider during the course of request routing redirection. It consists of the characters AS followed by the CDN Provider's AS number, then a colon (':') and an additional qualifier that is used to guarantee uniqueness in case a particular AS has multiple independent CDNs deployed; for example, "AS64496:0".
CDNプロバイダーIDは、リクエストルーティングのリダイレクト中に各CDNプロバイダーを一意に識別します。これは、ASという文字の後にCDNプロバイダーのAS番号、コロン（ '：'）、および特定のASに複数の独立したCDNが配備されている場合に一意性を保証するために使用される追加の修飾子で構成されます。たとえば、 "AS64496：0"。
If a dCDN receives an RI request whose cdn-path already contains that dCDN's Provider ID, the dCDN MUST send an RI error response that SHOULD include an error-code of 502.
dCDNがcdn-pathにすでにそのdCDNのプロバイダーIDが含まれているRI要求を受信する場合、dCDNは502のエラーコードを含む必要があるRIエラー応答を送信する必要があります。
If a dCDN receives an RI request where the number of CDN Provider IDs in cdn-path is greater than max-hops, the dCDN MUST send an RI error response that SHOULD include an error-code of 503.
dCDNがcdn-pathのCDNプロバイダーIDの数がmax-hopsより大きいRI要求を受信した場合、dCDNは503のエラーコードを含むべきであるRIエラー応答を送信しなければなりません（MUST）。
It should be noted that the loop detection and prevention mechanisms described above only cover preventing and detecting loops within the RI itself. Besides loops within the RI itself, there is also the possibility of loops in the data plane; for example, if the IP address(es) or URI(s) returned in RI responses do not resolve directly to a surrogate in the final dCDN, there is the possibility that a User Agent may be continuously redirected through a loop of CDNs. The specification of solutions to address data-plane request redirection loops between CDNs is outside of the scope of this document.
上記のループ検出および防止メカニズムは、RI自体内のループの防止および検出のみをカバーすることに注意してください。 RI自体内のループの他に、データプレーンでループが発生する可能性もあります。たとえば、RI応答で返されたIPアドレスまたはURIが最終的なdCDNのサロゲートに直接解決されない場合、ユーザーエージェントがCDNのループを介して継続的にリダイレクトされる可能性があります。 CDN間のデータプレーン要求リダイレクトループに対処するソリューションの仕様は、このドキュメントの範囲外です。
Information passed over the RI could be considered personal or sensitive, for example, RI requests contain parts of a User Agent's original request and RI responses reveal information about the dCDN's policy for which surrogates should serve which content/user locations.
RIを介して渡される情報は、個人情報または機密情報と見なされる可能性があります。たとえば、RI要求にはユーザーエージェントの元の要求の一部が含まれ、RI応答は、代理がどのコンテンツ/ユーザーの場所を提供するかに関するdCDNのポリシーに関する情報を明らかにします。
The RI interface also provides a mechanism whereby a uCDN could probe a dCDN and infer the dCDN's edge topology by making repeated RI requests for different content and/or UA IP addresses and correlating the responses from the dCDN. Additionally, the ability for a dCDN to indicate that an RI response applies more widely than the original request (via the scope dictionary) may significantly reduce the number of RI requests required to probe and infer the dCDN's edge topology.
また、RIインターフェースは、uCDNがdCDNをプローブし、異なるコンテンツやUA IPアドレスに対してRIリクエストを繰り返し行い、dCDNからの応答を関連付けることにより、dCDNのエッジトポロジを推測できるメカニズムも提供します。さらに、dCDNがRI応答が（スコープディクショナリを介して）元の要求よりも広く適用されることを示す機能により、dCDNのエッジトポロジを調査および推論するために必要なRI要求の数が大幅に減少する場合があります。
The same information could be obtained in the absence of the RI interface, but it could be more difficult to gather as it would require a distributed set of machines with a range of different IP addresses, each making requests directly to the dCDN. However, the RI facilitates easier collection of such information as it enables a single client to query the dCDN for a redirection/surrogate selection on behalf of any UA IP address.
RIインターフェースがなくても同じ情報を取得できますが、それぞれがdCDNに直接要求を行う一連の異なるIPアドレスを持つ分散マシンのセットが必要になるため、収集がより困難になる可能性があります。ただし、RIは、単一のクライアントが任意のUA IPアドレスに代わってリダイレクト/サロゲートの選択についてdCDNにクエリを実行できるようにするため、このような情報の収集を容易にします。
5.1. Authentication, Authorization, Confidentiality, and Integrity Protection
5.1. 認証、承認、機密性、および完全性の保護
An implementation of the CDNI Redirection interface MUST support TLS transport as per [RFC2818] and [RFC7230]. The use of TLS for transport of the CDNI Redirection interface messages allows the dCDN and uCDN to authenticate each other. Once they have mutually authenticated each other, it allows:
CDNIリダイレクションインターフェイスの実装は、[RFC2818]および[RFC7230]に従ってTLSトランスポートをサポートする必要があります。 CDNIリダイレクションインターフェイスメッセージの転送にTLSを使用すると、dCDNとuCDNが相互に認証できます。相互認証が完了すると、次のことが可能になります。
o The dCDN and uCDN to authorize each other (to ensure they are transmitting/receiving CDNI Redirection messages to/from an authorized CDN);
o dCDNとuCDNは相互に認証します（認証されたCDNとの間でCDNIリダイレクトメッセージを送受信していることを確認するため）。
o CDNI Redirection interface messages to be transmitted with confidentiality; and
o 機密性を保って送信されるCDNIリダイレクションインターフェイスメッセージ。そして
o The integrity of the CDNI Redirection interface messages to be protected during the exchange.
o 交換中に保護されるCDNIリダイレクションインターフェイスメッセージの整合性。
In an environment where any such protection is required, mutually authenticated encrypted transport MUST be used to ensure confidentiality of the redirection information; to do so, TLS MUST be used (including authentication of the remote end) by the server side (dCDN) and the client side (uCDN) of the CDNI Redirection interface.
このような保護が必要な環境では、相互認証された暗号化トランスポートを使用して、リダイレクト情報の機密性を確保する必要があります。そのためには、TLSを（リモートエンドの認証を含めて）CDNIリダイレクションインターフェイスのサーバー側（dCDN）およびクライアント側（uCDN）で使用する必要があります。
When TLS is used, the general TLS usage guidance in [RFC7525] MUST be followed.
TLSを使用する場合は、[RFC7525]の一般的なTLS使用ガイダンスに従う必要があります。
Information passed over the RI ought to be considered personal and sensitive. In particular, parts of a User Agent's original request, most notably the UA's IP address and requested URI, are transmitted over the RI to the dCDN. The use of mutually authenticated TLS, as described in the previous section, prevents any other party than the authorized dCDN from gaining access to this information.
RIを介して渡される情報は、個人的で機密性の高いものと見なされるべきです。特に、ユーザーエージェントの元のリクエストの一部、特にUAのIPアドレスとリクエストされたURIは、RIを介してdCDNに送信されます。前のセクションで説明したように、相互認証されたTLSを使用すると、許可されたdCDN以外の者がこの情報にアクセスできなくなります。
Regardless of whether the uCDN and dCDN use the RI, a successful redirect from a uCDN to a dCDN will make that dCDN aware of the UA's IP address. As such, the fact that this information is transmitted across the RI does not allow the dCDN to learn new information. On the other hand, if a uCDN uses the RI to check with multiple candidate dCDNs, those candidates that do not end up getting redirected to do obtain information regarding end-user IP addresses and requested URIs that they would not have if the RI not been used.
uCDNとdCDNがRIを使用するかどうかに関係なく、uCDNからdCDNへのリダイレクトが成功すると、そのdCDNはUAのIPアドレスを認識します。そのため、この情報がRIを介して送信されるという事実は、dCDNが新しい情報を学習することを許可しません。一方、uCDNがRIを使用して複数の候補dCDNをチェックする場合、リダイレクトされない結果となる候補は、エンドユーザーのIPアドレスに関する情報を取得し、RIがない場合には得られなかったURIを要求します。中古。
While it is technically possible to mask some information in the RI Request, such as the last bits of the UA IP address, it is important to note that this will reduce the effectiveness of the RI in certain cases. CDN deployments need to strike a balance between end-user privacy and the features impacted by such masking. This balance is likely to vary from one deployment to another. As an example, when the UA and its DNS resolver is behind a Carrier-grade NAT, and the RI is used to find an appropriate delivery node behind the same NAT, the full IP address might be necessary. Another potential issue when using IP anonymization is that it is no longer possible to correlate an RI Request with a subsequent UA request.
UA IPアドレスの最後のビットなど、RIリクエストの一部の情報をマスクすることは技術的には可能ですが、特定のケースではRIの有効性が低下することに注意することが重要です。 CDNの展開では、エンドユーザーのプライバシーと、そのようなマスキングによって影響を受ける機能とのバランスをとる必要があります。このバランスは、展開ごとに異なる可能性があります。たとえば、UAとそのDNSリゾルバーがキャリアグレードのNATの背後にあり、RIを使用して同じNATの背後にある適切な配信ノードを見つける場合、完全なIPアドレスが必要になることがあります。 IP匿名化を使用する場合のもう1つの潜在的な問題は、RI要求を後続のUA要求と関連付けることができなくなることです。
IANA has registered the following two new Payload Types in the "Content Delivery Network Interconnection (CDNI) Parameters" registry for use with the application/cdni MIME media type.
IANAは、application / cdni MIMEメディアタイプで使用するために、次の2つの新しいペイロードタイプを「コンテンツ配信ネットワーク相互接続（CDNI）パラメータ」レジストリに登録しました。
+----------------------+---------------+
| Payload Type | Specification |
+----------------------+---------------+
| redirection-request | RFC 7975 |
| | |
| redirection-response | RFC 7975 |
+----------------------+---------------+
Table 9
表9
Purpose: The purpose of this payload type is to distinguish RI request messages.
目的：このペイロードタイプの目的は、RI要求メッセージを区別することです。
Interface: RI
インターフェース：RI
Encoding: See Section 4.4.1 and Section 4.5.1
エンコーディング：セクション4.4.1およびセクション4.5.1を参照
Purpose: The purpose of this payload type is to distinguish RI response messages.
目的：このペイロードタイプの目的は、RI応答メッセージを区別することです。
Interface: RI
インターフェース：RI
Encoding: See Section 4.4.2 and Section 4.5.2
エンコーディング：セクション4.4.2およびセクション4.5.2を参照
IANA has created a new "CDNI RI Error response code" subregistry within the "Content Delivery Network Interconnection (CDNI) Parameters" registry. The "CDNI RI Error response code" namespace defines the valid values for the error-code key in RI error responses. The CDNI RI Error response code MUST be a three-digit integer.
IANAは、「コンテンツ配信ネットワーク相互接続（CDNI）パラメータ」レジストリ内に新しい「CDNI RIエラー応答コード」サブレジストリを作成しました。 「CDNI RIエラー応答コード」名前空間は、RIエラー応答のエラーコードキーの有効な値を定義します。 CDNI RIエラー応答コードは3桁の整数でなければなりません。
Additions to the "RI Error response registry" will be made via "Specification Required" as defined in [RFC5226].
[RIエラーレスポンスレジストリ]への追加は、[RFC5226]で定義されている「指定が必要」を介して行われます。
The Designated Expert will verify that new error-code registrations do not duplicate existing error-code definitions (in name or functionality), ensure that the new error-code is in accordance with the error classes defined in Section 4.7 of this document, prevent gratuitous additions to the namespace, and prevent any additions to the namespace that would impair the interoperability of CDNI implementations.
Designated Expertは、新しいエラーコード登録が既存のエラーコード定義（名前または機能）と重複していないことを確認し、新しいエラーコードがこのドキュメントのセクション4.7で定義されているエラークラスに従っていることを確認します。名前空間への追加、およびCDNI実装の相互運用性を損なう名前空間への追加を防止します。
New registrations are required to provide the following information:
次の情報を提供するには、新規登録が必要です。
Code: A three-digit numeric error-code, in accordance with the error classes defined in Section 4.7 of this document.
コード：このドキュメントのセクション4.7で定義されているエラークラスに準拠した3桁の数値エラーコード。
Reason: A string that provides further information related to the error that will be included in the JSON error dictionary with the 'reason'-key. Depending on the error-code semantics, the value of this field may be determined dynamically. In that case, the registration should set this value to '<reason>' and define its semantics in the description field.
理由：JSONのエラーディクショナリに「reason」キーで含まれるエラーに関連する詳細情報を提供する文字列。エラーコードのセマンティクスに応じて、このフィールドの値は動的に決定される場合があります。その場合、登録ではこの値を「<reason>」に設定し、説明フィールドでそのセマンティクスを定義する必要があります。
Description: A brief description of the error-code semantics.
説明：エラーコードのセマンティクスの簡単な説明。
Specification: Reference to the specification that defines the error-code in more detail.
仕様：エラーコードをより詳細に定義する仕様への参照。
The entries in Table 8 are registered by this document, with the value of the 'Specification' field set to RFC 7975 (this document).
表8のエントリは、このドキュメントによって登録され、[Specification]フィールドの値はRFC 7975（このドキュメント）に設定されています。
[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>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<http：/ /www.rfc-editor.org/info/rfc3986>。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<http://www.rfc-editor.org/info/rfc4291>。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, <http://www.rfc-editor.org/info/rfc5952>.
[RFC5952] Kawamura、S. and M. Kawashima、 "A Recommendation for IPv6 Address Text Representation"、RFC 5952、DOI 10.17487 / RFC5952、August 2010、<http://www.rfc-editor.org/info/rfc5952> 。
[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]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<http://www.rfc-editor.org/info/ rfc7230>。
[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>。
[RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, April 2013, <http://www.rfc-editor.org/info/rfc6895>.
[RFC6895] Eastlake 3rd、D。、「ドメインネームシステム（DNS）IANAに関する考慮事項」、BCP 42、RFC 6895、DOI 10.17487 / RFC6895、2013年4月、<http://www.rfc-editor.org/info/rfc6895 >。
[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>。
[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>。
[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>。
[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>。
[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>。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <http://www.rfc-editor.org/info/rfc5890>.
[RFC5890] Klensin、J。、「Internationalized Domain Names for Applications（IDNA）：Definitions and Document Framework」、RFC 5890、DOI 10.17487 / RFC5890、2010年8月、<http://www.rfc-editor.org/info/ rfc5890>。
[RTMP] Adobe Systems Incorporated, "Real-Time Messaging Protocol (RTMP) specification", December 2012, <http://www.adobe.com/go/spec_rtmp>.
[RTMP] Adobe Systems Incorporated、「Real-Time Messaging Protocol（RTMP）仕様」、2012年12月、<http://www.adobe.com/go/spec_rtmp>。
[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.、Ed。 Y.リー、編、「コンテンツ配布ネットワーク相互接続（CDNI）の要件」、RFC 7337、DOI 10.17487 / RFC7337、2014年8月、<http://www.rfc-editor.org/info/rfc7337>。
[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>。
[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>。
Acknowledgements
謝辞
The authors would like to thank Taesang Choi, Francois Le Faucheur, Matt Miller, Scott Wainner, and Kevin J. Ma for their valuable comments and input to this document.
著者は、貴重なコメントとこのドキュメントへの入力について、テサンチェ、フランソワルフォシェール、マットミラー、スコットウェインナー、およびケビンJ.マーに感謝します。
Contributors
貢献者
The following persons have participated as co-authors to this document:
次の人物がこのドキュメントの共著者として参加しています。
Wang Danhua Huawei Email: wangdanhua@huawei.com
Wang DanはH UAを電子メールとして描画します：Wang Danhua@Huawei.com
He Xiaoyan Huawei Email: hexiaoyan@huawei.com
hex i奥眼hu A is email：何晓燕@ Huawei.com
Ge Chen China Telecom Email: cheng@gsta.com
Ge Chen China Telecomメール：cheng@gsta.com
Ni Wei China Mobile Email: niwei@chinamobile.com
NI Wei China Mobileメール：無味@China Mobile.com
Yunfei Zhang Email: hishigh@gmail.com
Y UN非張メール：彼のhigh@Gmail.com
Spencer Dawkins Huawei Email: spencer@wonderhamster.org
Spencer Dawkins Huaweiメール：spencer@wonderhamster.org
Authors' Addresses
著者のアドレス
Ben Niven-Jenkins (editor) Nokia 3 Ely Road Milton, Cambridge CB24 6DD United Kingdom
Ben Niven-Jenkins（編集者）Nokia 3 Ely Roadミルトン、ケンブリッジCB24 6DDイギリス
Email: ben.niven-jenkins@nokia.com
Ray van Brandenburg (editor) TNO Anna van Buerenplein 1 The Hague 2595DA The Netherlands
レイ・ファン・ブランデンブルク（編集者）TNOアンナ・ファン・ビューレンプレイン1ハーグ2595DAオランダ
Phone: +31-88-866-7000
Email: ray.vanbrandenburg@tno.nl