Internet Engineering Task Force (IETF) L. Peterson
Request for Comments: 7336 Akamai Technologies, Inc.
Obsoletes: 3466 B. Davie
Category: Informational VMware, Inc.
ISSN: 2070-1721 R. van Brandenburg, Ed.
TNO
August 2014
Internet Engineering Task Force (IETF) L. Peterson
Request for Comments: 7336 Akamai Technologies, Inc.
Obsoletes: 3466 B. Davie
Category: Informational VMware, Inc.
ISSN: 2070-1721 R. van Brandenburg, Ed.
TNO
August 2014
Framework for Content Distribution Network Interconnection (CDNI)
内容分发网络互连（CDNI）框架
Abstract
摘要
This document presents a framework for Content Distribution Network Interconnection (CDNI). The purpose of the framework is to provide an overall picture of the problem space of CDNI and to describe the relationships among the various components necessary to interconnect CDNs. CDNI requires the specification of interfaces and mechanisms to address issues such as request routing, distribution metadata exchange, and logging information exchange across CDNs. The intent of this document is to outline what each interface needs to accomplish and to describe how these interfaces and mechanisms fit together, while leaving their detailed specification to other documents. This document, in combination with RFC 6707, obsoletes RFC 3466.
本文档介绍内容分发网络互连（CDNI）的框架。该框架的目的是提供CDNI问题空间的总体图，并描述互连CDN所需的各种组件之间的关系。CDNI需要接口和机制的规范，以解决请求路由、分发元数据交换和跨CDN的日志信息交换等问题。本文档的目的是概述每个接口需要完成的任务，并描述这些接口和机制如何组合在一起，同时将其详细规范留给其他文档。本文件与RFC 6707一起废除了RFC 3466。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7336.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7336.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Terminology ................................................4
1.2. Reference Model ............................................6
1.3. Structure of This Document ................................10
2. Building Blocks ................................................10
2.1. Request Redirection .......................................10
2.1.1. DNS Redirection ....................................10
2.1.2. HTTP Redirection ...................................12
3. Overview of CDNI Operation .....................................12
3.1. Preliminaries .............................................14
3.2. Iterative HTTP Redirect Example ...........................15
3.3. Recursive HTTP Redirection Example ........................21
3.4. Iterative DNS-Based Redirection Example ...................25
3.4.1. Notes on Using DNSSEC ..............................28
3.5. Dynamic Footprint Discovery Example .......................29
3.6. Content Removal Example ...................................31
3.7. Pre-positioned Content Acquisition Example ................32
3.8. Asynchronous CDNI Metadata Example ........................33
3.9. Synchronous CDNI Metadata Acquisition Example .............35
3.10. Content and Metadata Acquisition with Multiple
Upstream CDNs ............................................37
4. Main Interfaces ................................................38
4.1. In-Band versus Out-of-Band Interfaces .....................39
4.2. Cross-Interface Concerns ..................................40
4.3. Request Routing Interfaces ................................40
4.4. CDNI Logging Interface ....................................41
4.5. CDNI Control Interface ....................................43
4.6. CDNI Metadata Interface ...................................43
4.7. HTTP Adaptive Streaming Concerns ..........................44
4.8. URI Rewriting .............................................46
5. Deployment Models ..............................................47
5.1. Meshed CDNs ...............................................47
5.2. CSP Combined with CDN .....................................48
5.3. CSP Using CDNI Request Routing Interface ..................49
5.4. CDN Federations and CDN Exchanges .........................50
6. Trust Model ....................................................53
7. Privacy Considerations .........................................54
8. Security Considerations ........................................55
8.1. Security of CDNI Interfaces ...............................56
8.2. Digital Rights Management .................................56
9. Contributors ...................................................56
10. Acknowledgements ..............................................57
11. Informative References ........................................57
1. Introduction ....................................................4
1.1. Terminology ................................................4
1.2. Reference Model ............................................6
1.3. Structure of This Document ................................10
2. Building Blocks ................................................10
2.1. Request Redirection .......................................10
2.1.1. DNS Redirection ....................................10
2.1.2. HTTP Redirection ...................................12
3. Overview of CDNI Operation .....................................12
3.1. Preliminaries .............................................14
3.2. Iterative HTTP Redirect Example ...........................15
3.3. Recursive HTTP Redirection Example ........................21
3.4. Iterative DNS-Based Redirection Example ...................25
3.4.1. Notes on Using DNSSEC ..............................28
3.5. Dynamic Footprint Discovery Example .......................29
3.6. Content Removal Example ...................................31
3.7. Pre-positioned Content Acquisition Example ................32
3.8. Asynchronous CDNI Metadata Example ........................33
3.9. Synchronous CDNI Metadata Acquisition Example .............35
3.10. Content and Metadata Acquisition with Multiple
Upstream CDNs ............................................37
4. Main Interfaces ................................................38
4.1. In-Band versus Out-of-Band Interfaces .....................39
4.2. Cross-Interface Concerns ..................................40
4.3. Request Routing Interfaces ................................40
4.4. CDNI Logging Interface ....................................41
4.5. CDNI Control Interface ....................................43
4.6. CDNI Metadata Interface ...................................43
4.7. HTTP Adaptive Streaming Concerns ..........................44
4.8. URI Rewriting .............................................46
5. Deployment Models ..............................................47
5.1. Meshed CDNs ...............................................47
5.2. CSP Combined with CDN .....................................48
5.3. CSP Using CDNI Request Routing Interface ..................49
5.4. CDN Federations and CDN Exchanges .........................50
6. Trust Model ....................................................53
7. Privacy Considerations .........................................54
8. Security Considerations ........................................55
8.1. Security of CDNI Interfaces ...............................56
8.2. Digital Rights Management .................................56
9. Contributors ...................................................56
10. Acknowledgements ..............................................57
11. Informative References ........................................57
This document provides an overview of the various components necessary to interconnect CDNs, expanding on the problem statement and use cases introduced in [RFC6770] and [RFC6707]. It describes the necessary interfaces and mechanisms in general terms and outlines how they fit together to form a complete system for CDN Interconnection. Detailed specifications are left to other documents. This document makes extensive use of message flow examples to illustrate the operation of interconnected CDNs, but these examples should be considered illustrative rather than prescriptive.
本文档概述了互连CDN所需的各种组件，扩展了[RFC6770]和[RFC6707]中介绍的问题陈述和用例。它概括地描述了必要的接口和机制，并概述了它们如何结合在一起，形成一个完整的CDN互连系统。详细规格由其他文件决定。本文档广泛使用消息流示例来说明互连CDN的操作，但这些示例应被视为说明性的，而不是说明性的。
[RFC3466] uses different terminology and models for "Content (distribution) Internetworking (CDI)". It is also less prescriptive in terms of interfaces. To avoid confusion, this document obsoletes [RFC3466].
[RFC3466]对“内容（分发）互联网（CDI）”使用不同的术语和模型。它在接口方面也不太规范。为避免混淆，本文件废除了[RFC3466]。
This document uses the core terminology defined in [RFC6707]. It also introduces the following terms:
本文件使用[RFC6707]中定义的核心术语。它还介绍了以下术语：
CDN-Domain: a hostname (Fully Qualified Domain Name -- FQDN) at the beginning of a URL (excluding port and scheme), representing a set of content that is served by a given CDN. For example, in the URL http://cdn.csp.example/...rest of URL..., the CDN-Domain is cdn.csp.example. A major role of CDN-Domain is to identify a region (subset) of the URI space relative to which various CDNI rules and policies apply. For example, a record of CDNI Metadata might be defined for the set of resources corresponding to some CDN-Domain.
CDN-Domain: a hostname (Fully Qualified Domain Name -- FQDN) at the beginning of a URL (excluding port and scheme), representing a set of content that is served by a given CDN. For example, in the URL http://cdn.csp.example/...rest of URL..., the CDN-Domain is cdn.csp.example. A major role of CDN-Domain is to identify a region (subset) of the URI space relative to which various CDNI rules and policies apply. For example, a record of CDNI Metadata might be defined for the set of resources corresponding to some CDN-Domain.translate error, please retry
Distinguished CDN-Domain: a CDN-Domain that is allocated by a CDN for the purposes of communication with a peer CDN but that is not found in client requests. Such CDN-Domains may be used for inter-CDN acquisition, or as redirection targets, and enable a CDN to distinguish a request from a peer CDN from an end-user request.
可分辨CDN域：CDN为与对等CDN通信而分配的CDN域，但在客户端请求中找不到。此类CDN域可用于CDN间获取，或用作重定向目标，并使CDN能够区分请求、对等CDN和最终用户请求。
Delivering CDN: the CDN that ultimately delivers a piece of content to the end user. The last in a potential sequence of Downstream CDNs.
交付CDN：最终向最终用户交付内容的CDN。下游CDN潜在序列中的最后一个。
Iterative CDNI Request Redirection: When an Upstream CDN elects to redirect a request towards a Downstream CDN, the Upstream CDN can base its redirection purely on a local decision (and without attempting to take into account how the Downstream CDN may in turn redirect the user agent). In that case, the Upstream CDN redirects the request to the Request Routing system in the Downstream CDN, which in turn will decide how to redirect that request: this approach is referred to as "Iterative" CDNI Request Redirection.
迭代CDNI请求重定向：当上游CDN选择将请求重定向到下游CDN时，上游CDN可以将其重定向完全基于本地决策（并且不尝试考虑下游CDN如何反过来重定向用户代理）。在这种情况下，上游CDN将请求重定向到下游CDN中的请求路由系统，后者将决定如何重定向该请求：这种方法称为“迭代”CDNI请求重定向。
Recursive CDNI Request Redirection: When an Upstream CDN elects to redirect a request towards a Downstream CDN, the Upstream CDN can query the Downstream CDN Request Routing system via the CDNI Request Routing Redirection interface (or use information cached from earlier similar queries) to find out how the Downstream CDN wants the request to be redirected. This allows the Upstream CDN to factor in the Downstream CDN response when redirecting the user agent. This approach is referred to as "Recursive" CDNI Request Redirection. Note that the Downstream CDN may elect to have the request redirected directly to a Surrogate inside the Downstream CDN, or to any other element in the Downstream CDN (or in another CDN), to handle the redirected request appropriately.
递归CDNI请求重定向：当上游CDN选择将请求重定向到下游CDN时，上游CDN可以通过CDNI请求路由重定向接口查询下游CDN请求路由系统（或使用先前类似查询中缓存的信息）了解下游CDN希望如何重定向请求。这允许上游CDN在重定向用户代理时考虑下游CDN响应。这种方法称为“递归”CDNI请求重定向。注意，下游CDN可以选择将请求直接重定向到下游CDN内的代理，或者重定向到下游CDN（或另一CDN）中的任何其他元素，以适当地处理重定向的请求。
Synchronous CDNI operations: operations between CDNs that happen during the process of servicing a user request, i.e., between the time that the user agent begins its attempt to obtain content and the time at which that request is served.
同步CDNI操作：在为用户请求提供服务的过程中发生的CDN之间的操作，即从用户代理开始尝试获取内容到为该请求提供服务之间的操作。
Asynchronous CDNI operations: operations between CDNs that happen independently of any given user request, such as advertisement of footprint information or pre-positioning of content for later delivery.
异步CDNI操作：CDN之间独立于任何给定用户请求而发生的操作，如示意图信息的广告或内容的预定位以供以后交付。
Trigger Interface: a subset of the CDNI Control interface that includes operations to pre-position, revalidate, and purge both metadata and content. These operations are typically called in response to some action (Trigger) by the Content Service Provider (CSP) on the Upstream CDN.
触发器接口：CDNI控制接口的子集，包括预定位、重新验证和清除元数据和内容的操作。这些操作通常是响应上游CDN上的内容服务提供商（CSP）的某些操作（触发器）而调用的。
We also sometimes use uCDN and dCDN as shorthand for Upstream CDN and Downstream CDN (see [RFC6707]), respectively.
我们有时也使用uCDN和dCDN分别作为上游CDN和下游CDN的缩写（参见[RFC6707]）。
At various points in this document, the concept of a CDN footprint is used. For a discussion on what constitutes a CDN footprint, the reader is referred to [FOOTPRINT-CAPABILITY].
在本文档的不同点上，使用了CDN封装外形的概念。关于什么构成CDN封装外形的讨论，请参阅[footprint-CAPABILITY]。
This document uses the reference model in Figure 1, which expands the reference model originally defined in [RFC6707]. (The difference is that the expanded model splits the Request Routing interface into its two distinct parts: the Request Routing Redirection interface and the Footprint & Capabilities Advertisement interface, as described below.)
本文档使用图1中的参考模型，它扩展了[RFC6707]中最初定义的参考模型。（不同之处在于，扩展模型将请求路由接口分为两个不同的部分：请求路由重定向接口和Footprint&Capabilities播发接口，如下所述。）
--------
/ \
| CSP |
\ /
--------
*
*
* /\
* / \
---------------------- |CDNI| ----------------------
/ Upstream CDN \ | | / Downstream CDN \
| +-------------+ | | CI | | +-------------+ |
|******* Control |<======|====|=======>| Control *******|
|* +------*----*-+ | | | | +-*----*------+ *|
|* * * | | | | * * *|
|* +------*------+ | | LI | | +------*------+ *|
|* ***** Logging |<======|====|=======>| Logging ***** *|
|* * +-*-----------+ | | | | +-----------*-+ * *|
|* * * * | | | | * * * *|
.....*...+-*---------*-+ | | RI | | +-*---------*-+...*.*...
. |* * | |<======|====|=======>| | * *| .
. |* * | Req-Routing | | |FCI | | | Req-Routing | * *| .
. |* * *** |<======|====|=======>| |** * *| .
. |* * * +-------------+.| | | | +-------------+ * * *| .
. |* * * . | | | * * *| .
. |* * * +-------------+ |. | MI | | +-------------+ * * *| .
. |* * * | Distribution|<==.===|====|=======>| Distribution| * * *| .
. |* * * | | | . \ / | | | * * *| .
. |* * * |+---------+ | | . \/ | | +---------+| * * *| .
. |* * ***| +---------+| | ...Request......+---------+ |*** * *| .
. |* *****+-|Surrogate|***********************|Surrogate|-+***** *| .
. |******* +---------+| | Acquisition | |+----------+ *******| .
. | +-------------+ | | +-------*-----+ | .
. \ / \ * / .
. ---------------------- ---------*------------ .
. * .
. * Delivery .
. * .
. +--*---+ .
...............Request............................| User |..Request..
| Agent|
+------+
--------
/ \
| CSP |
\ /
--------
*
*
* /\
* / \
---------------------- |CDNI| ----------------------
/ Upstream CDN \ | | / Downstream CDN \
| +-------------+ | | CI | | +-------------+ |
|******* Control |<======|====|=======>| Control *******|
|* +------*----*-+ | | | | +-*----*------+ *|
|* * * | | | | * * *|
|* +------*------+ | | LI | | +------*------+ *|
|* ***** Logging |<======|====|=======>| Logging ***** *|
|* * +-*-----------+ | | | | +-----------*-+ * *|
|* * * * | | | | * * * *|
.....*...+-*---------*-+ | | RI | | +-*---------*-+...*.*...
. |* * | |<======|====|=======>| | * *| .
. |* * | Req-Routing | | |FCI | | | Req-Routing | * *| .
. |* * *** |<======|====|=======>| |** * *| .
. |* * * +-------------+.| | | | +-------------+ * * *| .
. |* * * . | | | * * *| .
. |* * * +-------------+ |. | MI | | +-------------+ * * *| .
. |* * * | Distribution|<==.===|====|=======>| Distribution| * * *| .
. |* * * | | | . \ / | | | * * *| .
. |* * * |+---------+ | | . \/ | | +---------+| * * *| .
. |* * ***| +---------+| | ...Request......+---------+ |*** * *| .
. |* *****+-|Surrogate|***********************|Surrogate|-+***** *| .
. |******* +---------+| | Acquisition | |+----------+ *******| .
. | +-------------+ | | +-------*-----+ | .
. \ / \ * / .
. ---------------------- ---------*------------ .
. * .
. * Delivery .
. * .
. +--*---+ .
...............Request............................| User |..Request..
| Agent|
+------+
<==> interfaces inside the scope of CDNI
<==> interfaces inside the scope of CDNI
**** and .... interfaces outside the scope of CDNI
**** and .... interfaces outside the scope of CDNI
Figure 1: CDNI Expanded Model and CDNI Interfaces
图1:CDNI扩展模型和CDNI接口
While some interfaces in the reference model are "out of scope" for the CDNI WG (in the sense that there is no need to define new protocols for those interfaces), we note that we still need to refer to them in this document to explain the overall operation of CDNI.
虽然参考模型中的一些接口“超出了CDNI工作组的范围”（在这个意义上，不需要为这些接口定义新协议），但我们注意到，我们仍需要在本文档中引用它们来解释CDNI的总体操作。
We also note that, while we generally show only one Upstream CDN serving a given CSP, it is entirely possible that multiple uCDNs can serve a single CSP. In fact, this situation effectively exists today in the sense that a single CSP can currently delegate its content delivery to more than one CDN.
我们还注意到，虽然我们通常只显示一个上游CDN服务于给定的CSP，但多个UCDN完全可能服务于单个CSP。事实上，这种情况在今天有效地存在，因为单个CSP当前可以将其内容交付委托给多个CDN。
The following briefly describes the five CDNI interfaces, paraphrasing the definitions given in [RFC6707]. We discuss these interfaces in more detail in Section 4.
以下简要介绍了五个CDNI接口，解释了[RFC6707]中给出的定义。我们将在第4节中更详细地讨论这些接口。
o CDNI Control interface (CI): Operations to bootstrap and parameterize the other CDNI interfaces, as well as operations to pre-position, revalidate, and purge both metadata and content. The latter subset of operations is sometimes collectively called the "Trigger interface".
o CDNI控制接口（CI）：引导和参数化其他CDNI接口的操作，以及预定位、重新验证和清除元数据和内容的操作。后一个操作子集有时统称为“触发器接口”。
o CDNI Request Routing interface: Operations to determine what CDN (and optionally what Surrogate within a CDN) is to serve end-user requests. This interface is actually a logical bundling of two separate, but related, interfaces:
o CDNI请求路由接口：用于确定哪些CDN（以及CDN中的可选代理）将服务于最终用户请求的操作。该接口实际上是两个独立但相关的接口的逻辑捆绑：
* CDNI Footprint & Capabilities Advertisement interface (FCI): Asynchronous operations to exchange routing information (e.g., the network footprint and capabilities served by a given CDN) that enables CDN selection for subsequent user requests; and
* CDNI示意图和功能广告接口（FCI）：交换路由信息（例如，给定CDN所服务的网络示意图和功能）的异步操作，以便为后续用户请求选择CDN；和
* CDNI Request Routing Redirection interface (RI): Synchronous operations to select a delivery CDN (Surrogate) for a given user request.
* CDNI请求路由重定向接口（RI）：为给定用户请求选择传递CDN（代理）的同步操作。
o CDNI Metadata interface (MI): Operations to communicate metadata that governs how the content is delivered by interconnected CDNs. Examples of CDNI Metadata include geo-blocking directives, availability windows, access control mechanisms, and purge directives. It may include a combination of:
o CDNI元数据接口（MI）：用于传递元数据的操作，该元数据控制互连CDN交付内容的方式。CDNI元数据的示例包括地理阻止指令、可用性窗口、访问控制机制和清除指令。它可以包括以下组合：
* Asynchronous operations to exchange metadata that govern subsequent user requests for content; and
* 用于交换元数据的异步操作，这些元数据控制后续用户对内容的请求；和
* Synchronous operations that govern behavior for a given user request for content.
* 控制给定用户内容请求行为的同步操作。
o CDNI Logging interface (LI): Operations that allow interconnected CDNs to exchange relevant activity logs. It may include a combination of:
o CDNI日志接口（LI）：允许互连CDN交换相关活动日志的操作。它可以包括以下组合：
* Real-time exchanges, suitable for runtime traffic monitoring; and
* 实时交换，适用于运行时流量监控；和
* Offline exchanges, suitable for analytics and billing.
* 离线交换，适用于分析和计费。
The division between the sets of Trigger-based operations in the CDNI Control interface and the CDNI Metadata interface is somewhat arbitrary. For both cases, the information passed from the Upstream CDN to the Downstream CDN can broadly be viewed as metadata that describes how content is to be managed by the Downstream CDN. For example, the information conveyed by the CI to pre-position, revalidate, or purge metadata is similar to the information conveyed by posting updated metadata via the MI. Even the CI operation to purge content could be viewed as a metadata update for that content: purge simply says that the availability window for the named content ends now. The two interfaces share much in common, so minimally, there will need to be a consistent data model that spans both.
CDNI控制接口和CDNI元数据接口中基于触发器的操作集之间的划分有些随意。对于这两种情况，从上游CDN传递到下游CDN的信息可以广泛地视为元数据，用于描述下游CDN如何管理内容。例如，CI向预定位、重新验证或清除元数据传递的信息类似于通过MI发布更新的元数据所传递的信息。甚至清除内容的CI操作也可以被视为该内容的元数据更新：清除只是表示命名内容的可用性窗口现在结束。这两个接口有很多共同之处，因此至少需要一个跨这两个接口的一致数据模型。
The distinction we draw has to do with what the uCDN knows about the successful application of the metadata by the dCDN. In the case of the CI, the Downstream CDN returning a successful status message guarantees that the operation has been successfully completed; for example, the content has been purged or pre-positioned. This implies that the Downstream CDN accepts responsibility for having successfully completed the requested operation. In contrast, metadata passed between CDNs via the MI carries no such completion guarantee. Returning success implies successful receipt of the metadata, but nothing can be inferred about precisely when the metadata will take effect in the Downstream CDN, only that it will take effect eventually. This is because of the challenge in globally synchronizing updates to metadata with end-user requests that are currently in progress (or indistinguishable from currently being in progress). Clearly, a CDN will not be viewed as a trusted peer if "eventually" often becomes an indefinite period of time, but the acceptance of responsibility cannot be as crisply defined for the MI.
我们得出的区别与uCDN对dCDN成功应用元数据的了解有关。对于CI，返回成功状态消息的下游CDN保证操作已成功完成；例如，内容已被清除或预先定位。这意味着下游CDN接受成功完成请求操作的责任。相反，通过MI在CDN之间传递的元数据没有此类完成保证。返回success意味着成功接收元数据，但无法准确推断元数据在下游CDN中何时生效，只能推断它最终会生效。这是因为在将元数据更新与当前正在进行的最终用户请求（或与当前正在进行的请求无法区分）进行全局同步方面存在挑战。显然，如果“最终”往往成为一个不确定的时间段，CDN将不会被视为一个受信任的对等方，但是责任的接受不能像MI那样清晰地定义。
Finally, there is a practical issue that impacts all of the CDNI interfaces, and that is whether or not to optimize CDNI for HTTP Adaptive Streaming (HAS). We highlight specific issues related to delivering HAS content throughout this document, but for a more thorough treatment of the topic, see [RFC6983].
最后，还有一个影响所有CDNI接口的实际问题，即是否为HTTP自适应流（HAS）优化CDNI。在本文档中，我们强调了与交付HAS内容相关的具体问题，但有关该主题的更全面的处理，请参见[RFC6983]。
The remainder of this document is organized as follows:
本文件其余部分的组织结构如下：
o Section 2 describes some essential building blocks for CDNI, notably the various options for redirecting user requests to a given CDN.
o 第2节描述了CDNI的一些基本构建块，特别是将用户请求重定向到给定CDN的各种选项。
o Section 3 provides a number of illustrative examples of various CDNI operations.
o 第3节提供了各种CDNI操作的一些示例。
o Section 4 describes the functionality of the main CDNI interfaces.
o 第4节描述了主要CDNI接口的功能。
o Section 5 shows how various deployment models of CDNI may be achieved using the defined interfaces.
o 第5节展示了如何使用定义的接口实现CDNI的各种部署模型。
o Section 6 describes the trust model of CDNI and the issues of transitive trust in particular that CDNI raises.
o 第6节描述了CDNI的信任模型，特别是CDNI提出的传递性信任问题。
At its core, CDNI requires the redirection of requests from one CDN to another. For any given request that is received by an Upstream CDN, it will either respond to the request directly, or somehow redirect the request to a Downstream CDN. Two main mechanisms are available for redirecting a request to a Downstream CDN. The first leverages the DNS name resolution process and the second uses application-layer redirection mechanisms such as the HTTP 302 or Real-Time Streaming Protocol (RTSP) 302 redirection responses. While there exists a large variety of application-layer protocols that include some form of redirection mechanism, this document will use HTTP (and HTTPS) in its examples. Similar mechanisms can be applied to other application-layer protocols. What follows is a short discussion of both DNS- and HTTP-based redirection, before presenting some examples of their use in Section 3.
CDNI的核心要求将请求从一个CDN重定向到另一个CDN。对于上游CDN接收到的任何给定请求，它要么直接响应请求，要么以某种方式将请求重定向到下游CDN。有两种主要机制可用于将请求重定向到下游CDN。第一种方法利用DNS名称解析过程，第二种方法使用应用层重定向机制，如HTTP 302或实时流协议（RTSP）302重定向响应。虽然存在各种各样的应用层协议，其中包括某种形式的重定向机制，但本文档将在其示例中使用HTTP（和HTTPS）。类似的机制可以应用于其他应用层协议。下面是对基于DNS和HTTP的重定向的简短讨论，然后在第3节中介绍它们的一些使用示例。
DNS redirection is based on returning different IP addresses for the same DNS name, for example, to balance server load or to account for the client's location in the network. A DNS server, sometimes called the Local DNS (LDNS), resolves DNS names on behalf of an end user. The LDNS server in turn queries other DNS servers until it reaches the authoritative DNS server for the CDN-Domain. The network operator typically provides the LDNS server, although the user is free to choose other DNS servers (e.g., OpenDNS, Google Public DNS).
DNS重定向基于为同一DNS名称返回不同的IP地址，例如，以平衡服务器负载或说明客户端在网络中的位置。DNS服务器，有时称为本地DNS（LDNS），代表最终用户解析DNS名称。LDNS服务器依次查询其他DNS服务器，直到到达CDN域的权威DNS服务器。网络运营商通常提供LDNS服务器，但用户可以自由选择其他DNS服务器（例如OpenDNS、谷歌公共DNS）。
This latter possibility is important because the authoritative DNS server sees only the IP address of the DNS server that queries it, not the IP address of the original end user.
后一种可能性很重要，因为权威DNS服务器只看到查询它的DNS服务器的IP地址，而不是原始最终用户的IP地址。
The advantage of DNS redirection is that it is completely transparent to the end user; the user sends a DNS name to the LDNS server and gets back an IP address. On the other hand, DNS redirection is problematic because the DNS request comes from the LDNS server, not the end user. This may affect the accuracy of server selection that is based on the user's location. The transparency of DNS redirection is also a problem in that there is no opportunity to take the attributes of the user agent or the URI path component into account. We consider two main forms of DNS redirection: simple and CNAME-based.
DNS重定向的优点是对最终用户完全透明；用户向LDNS服务器发送DNS名称并返回IP地址。另一方面，DNS重定向是有问题的，因为DNS请求来自LDNS服务器，而不是最终用户。这可能会影响基于用户位置的服务器选择的准确性。DNS重定向的透明度也是一个问题，因为没有机会考虑用户代理或URI路径组件的属性。我们考虑DNS重定向的两种主要形式：简单的和基于CNNE的。
In simple DNS redirection, the authoritative DNS server for the name simply returns an IP address from a set of possible IP addresses. The answer is chosen from the set based on characteristics of the set (e.g., the relative loads on the servers) or characteristics of the client (e.g., the location of the client relative to the servers). Simple redirection is straightforward. The only caveats are (1) there is a limit to the number of alternate IP addresses a single DNS server can manage; and (2) DNS responses are cached by Downstream servers so the Time to Live (TTL) on the response must be set to an appropriate value so as to preserve the freshness of the redirection.
在简单DNS重定向中，该名称的权威DNS服务器仅从一组可能的IP地址返回IP地址。根据集合的特征（例如，服务器上的相对负载）或客户端的特征（例如，客户端相对于服务器的位置），从集合中选择答案。简单的重定向很简单。唯一需要注意的是（1）单个DNS服务器可以管理的备用IP地址数量有限制；和（2）DNS响应由下游服务器缓存，因此响应的生存时间（TTL）必须设置为适当的值，以保持重定向的新鲜度。
In CNAME-based DNS redirection, the authoritative server returns a CNAME response to the DNS request, telling the LDNS server to restart the name lookup using a new name. A CNAME is essentially a symbolic link in the DNS namespace, and like a symbolic link, redirection is transparent to the client; the LDNS server gets the CNAME response and re-executes the lookup. Only when the name has been resolved to an IP address does it return the result to the user. Note that DNAME would be preferable to CNAME if it becomes widely supported.
在基于CNAME的DNS重定向中，权威服务器返回对DNS请求的CNAME响应，通知LDNS服务器使用新名称重新启动名称查找。CNAME本质上是DNS名称空间中的符号链接，与符号链接一样，重定向对客户端是透明的；LDNS服务器获取CNAME响应并重新执行查找。只有当名称解析为IP地址时，才会将结果返回给用户。请注意，如果DNAME得到广泛支持，它将比CNAME更可取。
One of the advantages of DNS redirection compared to HTTP redirection is that it can be cached, reducing load on the redirecting CDN's DNS server. However, this advantage can also be a drawback, especially when a given DNS resolver doesn't strictly adhere to the TTL, which is a known problem in some real-world environments. In such cases, an end user might end up at a dCDN without first having passed through the uCDN, which might be an undesirable scenario from a uCDN point of view.
与HTTP重定向相比，DNS重定向的优点之一是它可以缓存，从而减少重定向CDN的DNS服务器上的负载。然而，这一优势也可能是一个缺点，特别是当给定的DNS解析程序没有严格遵守TTL时，这在一些实际环境中是一个已知的问题。在这种情况下，最终用户可能会在没有首先通过uCDN的情况下到达dCDN，从uCDN的角度来看，这可能是不希望出现的情况。
HTTP redirection makes use of the redirection response of the HTTP protocol (e.g.,"302" or "307"). This response contains a new URL that the application should fetch instead of the original URL. By changing the URL appropriately, the server can cause the user to redirect to a different server. The advantages of HTTP redirection are that (1) the server can change the URL fetched by the client to include, for example, both the DNS name of the particular server to use, as well as the original HTTP server that was being accessed; (2) the client sends the HTTP request to the server, so that its IP address is known and can be used in selecting the server; and (3) other attributes (e.g., content type, user agent type) are visible to the redirection mechanism.
HTTP重定向利用HTTP协议的重定向响应（例如，“302”或“307”）。此响应包含应用程序应获取的新URL，而不是原始URL。通过适当地更改URL，服务器可以使用户重定向到其他服务器。HTTP重定向的优点是：（1）服务器可以更改客户端获取的URL，以包括（例如）要使用的特定服务器的DNS名称以及正在访问的原始HTTP服务器；（2） 客户端向服务器发送HTTP请求，以便其IP地址已知并可用于选择服务器；和（3）重定向机制可见的其他属性（例如，内容类型、用户代理类型）。
Just as is the case for DNS redirection, there are some potential disadvantages of using HTTP redirection. For example, it may affect application behavior; web browsers will not send cookies if the URL changes to a different domain. In addition, although this might also be an advantage, results of HTTP redirection are not cached so that all redirections must go through to the uCDN.
就像DNS重定向一样，使用HTTP重定向也有一些潜在的缺点。例如，它可能会影响应用程序行为；如果URL更改为其他域，web浏览器将不会发送cookie。此外，尽管这可能也是一个优势，但HTTP重定向的结果不会被缓存，因此所有重定向都必须通过uCDN。
To provide a big-picture overview of the various components of CDNI, we walk through a "day in the life" of a content item that is made available via a pair of interconnected CDNs. This will serve to illustrate many of the functions that need to be supported in a complete CDNI solution. We give examples using both DNS-based and HTTP-based redirection. We begin with very simple examples and then show how additional capabilities, such as recursive request redirection and content removal, might be added.
为了全面介绍CDNI的各个组成部分，我们将通过一对相互连接的CDN浏览内容项的“生命中的一天”。这将有助于说明在完整的CDNI解决方案中需要支持的许多功能。我们给出了使用基于DNS和基于HTTP的重定向的示例。我们从非常简单的示例开始，然后展示如何添加其他功能，例如递归请求重定向和内容删除。
Before walking through the specific examples, we present a high-level view of the operations that may take place. This high-level overview is illustrated in Figure 2. Note that most operations will involve only a subset of all the messages shown below, and that the order and number of operations may vary considerably, as the more detailed examples illustrate.
在浏览具体示例之前，我们先介绍可能发生的操作的高级视图。图2说明了这一高级概述。请注意，大多数操作只涉及下面显示的所有消息的子集，并且操作的顺序和数量可能会有很大的不同，如更详细的示例所示。
The following shows Operator A as the Upstream CDN (uCDN) and Operator B as the Downstream CDN (dCDN), where the former has a relationship with a content provider and the latter is the CDN selected by Operator A to deliver content to the end user. The interconnection relationship may be symmetric between these two CDN operators, but each direction can be considered as operating independently of the other; for simplicity, we show the interaction in one direction only.
以下显示运营商A作为上游CDN（uCDN），运营商B作为下游CDN（dCDN），其中前者与内容提供商有关系，后者是运营商A选择的向最终用户交付内容的CDN。这两个CDN运营商之间的互连关系可能是对称的，但每个方向都可以被视为独立于另一个方向运行；为了简单起见，我们只在一个方向上显示交互。
End User Operator B Operator A
| | |
| | |
| | [Async FCI Push] | (1)
| | |
| | [MI pre-positioning] | (2)
| | |
| CONTENT REQUEST | |
|-------------------------------------------------->| (3)
| | |
| | [Sync RI Pull] | (4)
| | |
| CONTENT REQUEST REDIRECTION |
|<--------------------------------------------------| (5)
| | |
| | |
| CONTENT REQUEST | |
|------------------------>| | (6)
| | |
| | [Sync MI Pull] | (7)
| | |
| | ACQUISITION REQUEST |
| X------------------------>| (8)
| X |
| X CONTENT DATA |
| X<------------------------| (9)
| | |
| CONTENT DATA | |
|<------------------------| | (10)
| | |
: : :
: [Other content requests] :
: : :
| | [CI: Content Purge] | (11)
: : :
| | [LI: Log exchange] | (12)
| | |
End User Operator B Operator A
| | |
| | |
| | [Async FCI Push] | (1)
| | |
| | [MI pre-positioning] | (2)
| | |
| CONTENT REQUEST | |
|-------------------------------------------------->| (3)
| | |
| | [Sync RI Pull] | (4)
| | |
| CONTENT REQUEST REDIRECTION |
|<--------------------------------------------------| (5)
| | |
| | |
| CONTENT REQUEST | |
|------------------------>| | (6)
| | |
| | [Sync MI Pull] | (7)
| | |
| | ACQUISITION REQUEST |
| X------------------------>| (8)
| X |
| X CONTENT DATA |
| X<------------------------| (9)
| | |
| CONTENT DATA | |
|<------------------------| | (10)
| | |
: : :
: [Other content requests] :
: : :
| | [CI: Content Purge] | (11)
: : :
| | [LI: Log exchange] | (12)
| | |
Figure 2: Overview of Operation
图2：操作概述
The operations shown in the figure are as follows:
图中所示的操作如下：
1. The dCDN uses the FCI to advertise information relevant to its delivery footprint and capabilities prior to any content requests being redirected.
1. 在重定向任何内容请求之前，dCDN使用FCI发布与其交付足迹和功能相关的信息。
2. Prior to any content request, the uCDN uses the MI to pre-position CDNI Metadata to the dCDN, thereby making that metadata available in readiness for later content requests.
2. 在任何内容请求之前，uCDN使用MI将CDNI元数据预先定位到dCDN，从而使该元数据为以后的内容请求做好准备。
3. A content request from a user agent arrives at the uCDN.
3. 来自用户代理的内容请求到达uCDN。
4. The uCDN may use the RI to synchronously request information from the dCDN regarding its delivery capabilities to decide if the dCDN is a suitable target for redirection of this request.
4. uCDN可以使用RI从dCDN同步请求关于其传递能力的信息，以确定dCDN是否是重定向该请求的合适目标。
5. The uCDN redirects the request to the dCDN by sending some response (DNS, HTTP) to the user agent.
5. uCDN通过向用户代理发送一些响应（DNS、HTTP），将请求重定向到dCDN。
6. The user agent requests the content from the dCDN.
6. 用户代理从dCDN请求内容。
7. The dCDN may use the MI to synchronously request metadata related to this content from uCDN, e.g., to decide whether to serve it.
7. dCDN可以使用MI从uCDN同步请求与此内容相关的元数据，例如，决定是否为其提供服务。
8. If the content is not already in a suitable cache in the dCDN, the dCDN may acquire it from the uCDN.
8. 如果内容不在dCDN中的适当缓存中，dCDN可能会从uCDN获取该内容。
9. The content is delivered to the dCDN from the uCDN.
9. 内容从uCDN传递到dCDN。
10. The content is delivered to the user agent by the dCDN.
10. 内容由dCDN交付给用户代理。
11. Some time later, perhaps at the request of the CSP (not shown) the uCDN may use the CI to instruct the dCDN to purge the content, thereby ensuring it is not delivered again.
11. 一段时间后，可能应CSP（未显示）的请求，uCDN可以使用CI指示dCDN清除内容，从而确保不会再次交付内容。
12. After one or more content delivery actions by the dCDN, a log of delivery actions may be provided to the uCDN using the LI.
12. dCDN执行一个或多个内容交付操作后，可以使用LI向uCDN提供交付操作日志。
The following sections show some more specific examples of how these operations may be combined to perform various delivery, control, and logging operations across a pair of CDNs.
以下各节显示了如何组合这些操作以跨一对CDN执行各种传递、控制和日志记录操作的一些更具体的示例。
Initially, we assume that there is at least one CSP that has contracted with an Upstream CDN (uCDN) to deliver content on its behalf. We are not particularly concerned with the interface between the CSP and uCDN, other than to note that it is expected to be the same as in the "traditional" (non-interconnected) CDN case. Existing mechanisms such as DNS CNAMEs or HTTP redirects (Section 2) can be used to direct a user request for a piece of content from the CSP towards the CSP's chosen Upstream CDN.
最初，我们假设至少有一个CSP与上游CDN（uCDN）签订合同，代表其交付内容。我们并不特别关注CSP和uCDN之间的接口，只是注意到它与“传统”（非互连）CDN情况下的接口相同。DNS CNAMEs或HTTP重定向（第2节）等现有机制可用于将用户对CSP内容的请求定向到CSP选择的上游CDN。
We assume Operator A provides an Upstream CDN that serves content on behalf of a CSP with CDN-Domain cdn.csp.example. We assume that Operator B provides a Downstream CDN. An end user at some point makes a request for URL
我们假设运营商A提供了一个上游CDN，该CDN代表具有CDN域CDN.CSP.example的CSP提供内容。我们假设运营商B提供下游CDN。最终用户在某个时刻发出URL请求
http://cdn.csp.example/...rest of URL...
http://cdn.csp.example/...rest 的URL。。。
It may well be the case that cdn.csp.example is just a CNAME for some other CDN-Domain (such as csp.op-a.example). Nevertheless, the HTTP request in the examples that follow is assumed to be for the example URL above.
很可能cdn.csp.example只是其他一些cdn域（例如csp.op-a.example）的CNAME。然而，下面示例中的HTTP请求被假定为用于上面的示例URL。
Our goal is to enable content identified by the above URL to be served by the CDN of Operator B. In the following sections, we will walk through some scenarios in which content is served as well as other CDNI operations such as the removal of content from a Downstream CDN.
我们的目标是使上述URL标识的内容能够由运营商B的CDN提供服务。在以下部分中，我们将介绍提供内容的一些场景以及其他CDNI操作，例如从下游CDN中删除内容。
In this section, we walk through a simple, illustrative example using HTTP redirection from a uCDN to a dCDN. The example also assumes the use of HTTP redirection inside the uCDN and dCDN; however, this is independent of the choice of redirection approach across CDNs, so an alternative example could be constructed still showing HTTP redirection from the uCDN to dCDN but using DNS for the handling of the request inside each CDN.
在本节中，我们将介绍一个使用HTTP重定向从uCDN到dCDN的简单示例。该示例还假设在uCDN和dCDN内使用HTTP重定向；但是，这与跨CDN的重定向方法的选择无关，因此可以构造一个替代示例，该示例仍然显示从uCDN到dCDN的HTTP重定向，但使用DNS处理每个CDN内的请求。
For this example, we assume that Operators A and B have established an agreement to interconnect their CDNs, with A being Upstream and B being Downstream.
在本例中，我们假设运营商A和B已签订协议，将其CDN互连，其中A为上游，B为下游。
The operators agree that a CDN-Domain peer-a.op-b.example will be used as the target of redirections from the uCDN to dCDN. We assume the name of this domain is communicated by some means to each CDN. (This could be established out of band or via a CDNI interface.) We refer to this domain as a "distinguished" CDN-Domain to convey the fact that its use is limited to the interconnection mechanism; such a domain is never used directly by a CSP.
运营商同意将CDN域peer-a.op-b.example用作从uCDN重定向到dCDN的目标。我们假设此域的名称通过某种方式与每个CDN通信。（这可以在带外或通过CDNI接口建立。）我们将此域称为“区分”CDN域，以表明其使用仅限于互连机制的事实；CSP从未直接使用过这样的域。
We assume the operators also agree on some distinguished CDN-Domain that will be used for inter-CDN acquisition of the CSP's content from the uCDN by the dCDN. In this example, we'll use op-b-acq.op-a.example.
我们假设运营商还同意一些可区分的CDN域，这些域将用于dCDN从uCDN跨CDN获取CSP的内容。在本例中，我们将使用op-b-acq.op-a.example。
We assume the operators also exchange information regarding which requests the dCDN is prepared to serve. For example, the dCDN may be prepared to serve requests from clients in a given geographical region or a set of IP address prefixes. This information may again be provided out of band or via a defined CDNI interface.
我们假设操作员还交换有关dCDN准备服务哪些请求的信息。例如，dCDN可以准备为来自给定地理区域或一组IP地址前缀中的客户端的请求提供服务。该信息可再次在带外或通过定义的CDNI接口提供。
We assume DNS is configured in the following way:
我们假设DNS的配置方式如下：
o The content provider is configured to make Operator A the authoritative DNS server for cdn.csp.example (or to return a CNAME for cdn.csp.example for which Operator A is the authoritative DNS server).
o 内容提供商配置为使运营商A成为cdn.csp.example的权威DNS服务器（或返回运营商A为其权威DNS服务器的cdn.csp.example的CNAME）。
o Operator A is configured so that a DNS request for op-b-acq.op-a.example returns a Request Router in Operator A.
o 操作员A的配置使得op-b-acq.op-A的DNS请求返回操作员A中的请求路由器。
o Operator B is configured so that a DNS request for peer-a.op-b.example/cdn.csp.example returns a Request Router in Operator B.
o 对运营商B进行配置，以便对等方a.op-B.example/cdn.csp.example的DNS请求返回运营商B中的请求路由器。
Figure 3 illustrates how a client request for
图3说明了客户端如何请求
http://cdn.csp.example/...rest of URL...
http://cdn.csp.example/...rest 的URL。。。
is handled.
处理好了。
End User Operator B Operator A
|DNS cdn.csp.example | |
|-------------------------------------------------->|
| | |(1)
|IPaddr of A's Request Router |
|<--------------------------------------------------|
|HTTP cdn.csp.example | |
|-------------------------------------------------->|
| | |(2)
|302 peer-a.op-b.example/cdn.csp.example |
|<--------------------------------------------------|
|DNS peer-a.op-b.example | |
|------------------------>| |
| |(3) |
|IPaddr of B's Request Router |
|<------------------------| |
| | |
|HTTP peer-a.op-b.example/cdn.csp.example |
|------------------------>| |
End User Operator B Operator A
|DNS cdn.csp.example | |
|-------------------------------------------------->|
| | |(1)
|IPaddr of A's Request Router |
|<--------------------------------------------------|
|HTTP cdn.csp.example | |
|-------------------------------------------------->|
| | |(2)
|302 peer-a.op-b.example/cdn.csp.example |
|<--------------------------------------------------|
|DNS peer-a.op-b.example | |
|------------------------>| |
| |(3) |
|IPaddr of B's Request Router |
|<------------------------| |
| | |
|HTTP peer-a.op-b.example/cdn.csp.example |
|------------------------>| |
| |(4) |
|302 node1.peer-a.op-b.example/cdn.csp.example |
|<------------------------| |
|DNS node1.peer-a.op-b.example |
|------------------------>| |
| |(5) |
|IPaddr of B's Delivery Node |
|<------------------------| |
| | |
|HTTP node1.peer-a.op-b.example/cdn.csp.example |
|------------------------>| |
| |(6) |
| |DNS op-b-acq.op-a.example|
| |------------------------>|
| | |(7)
| |IPaddr of A's Request Router
| |<------------------------|
| |HTTP op-b-acq.op-a.example
| |------------------------>|
| | |(8)
| |302 node2.op-b-acq.op-a.example
| |<------------------------|
| |DNS node2.op-b-acq.op-a.example
| |------------------------>|
| | |(9)
| |IPaddr of A's Delivery Node
| |<------------------------|
| | |
| |HTTP node2.op-b-acq.op-a.example
| |------------------------>|
| | |(10)
| |Data |
| |<------------------------|
|Data | |
|<------------------------| |
| |(4) |
|302 node1.peer-a.op-b.example/cdn.csp.example |
|<------------------------| |
|DNS node1.peer-a.op-b.example |
|------------------------>| |
| |(5) |
|IPaddr of B's Delivery Node |
|<------------------------| |
| | |
|HTTP node1.peer-a.op-b.example/cdn.csp.example |
|------------------------>| |
| |(6) |
| |DNS op-b-acq.op-a.example|
| |------------------------>|
| | |(7)
| |IPaddr of A's Request Router
| |<------------------------|
| |HTTP op-b-acq.op-a.example
| |------------------------>|
| | |(8)
| |302 node2.op-b-acq.op-a.example
| |<------------------------|
| |DNS node2.op-b-acq.op-a.example
| |------------------------>|
| | |(9)
| |IPaddr of A's Delivery Node
| |<------------------------|
| | |
| |HTTP node2.op-b-acq.op-a.example
| |------------------------>|
| | |(10)
| |Data |
| |<------------------------|
|Data | |
|<------------------------| |
Figure 3: Message Flow for Iterative HTTP Redirection
图3：迭代HTTP重定向的消息流
The steps illustrated in the figure are as follows:
图中所示的步骤如下：
1. A DNS resolver for Operator A processes the DNS request for its customer based on CDN-Domain cdn.csp.example. It returns the IP address of a Request Router in Operator A.
1. 运营商A的DNS解析程序基于CDN域CDN.csp.example处理其客户的DNS请求。它返回操作员a中请求路由器的IP地址。
2. A Request Router for Operator A processes the HTTP request and recognizes that the end user is best served by another CDN, specifically one provided by Operator B, and so it returns a 302 redirect message for a new URL constructed by "stacking"
2. 运营商A的请求路由器处理HTTP请求，并识别出终端用户最好由另一个CDN服务，特别是运营商B提供的CDN，因此它返回302重定向消息，用于“堆叠”构造的新URL
Operator B's distinguished CDN-Domain (peer-a.op-b.example) on the front of the original URL. (Note that more complex URL manipulations are possible, such as replacing the initial CDN-Domain by some opaque handle.)
运营商B的专有CDN域（peer-a.op-B.example）位于原始URL前面。（请注意，更复杂的URL操作是可能的，例如用一些不透明的句柄替换初始CDN域。）
3. The end user does a DNS lookup using Operator B's distinguished CDN-Domain (peer-a.op-b.example). B's DNS resolver returns the IP address of a Request Router for Operator B. Note that if request routing within the dCDN was performed using DNS instead of HTTP redirection, B's DNS resolver would also behave as the Request Router and directly return the IP address of a delivery node.
3. 最终用户使用运营商B的专有CDN域（peer-a.op-B.example）进行DNS查找。B的DNS解析器为操作员B返回请求路由器的IP地址。请注意，如果使用DNS而不是HTTP重定向执行dCDN内的请求路由，B的DNS解析器也将充当请求路由器，并直接返回传递节点的IP地址。
4. The Request Router for Operator B processes the HTTP request and selects a suitable delivery node to serve the end-user request, and it returns a 302 redirect message for a new URL constructed by replacing the hostname with a subdomain of the Operator B's distinguished CDN-Domain that points to the selected delivery node.
4. 运营商B的请求路由器处理HTTP请求并选择合适的传递节点来服务最终用户请求，并返回302重定向消息，该消息针对通过将主机名替换为运营商B指向所选传递节点的可分辨CDN域的子域而构建的新URL。
5. The end user does a DNS lookup using Operator B's delivery node subdomain (node1.peer-a.op-b.example). B's DNS resolver returns the IP address of the delivery node.
5. 最终用户使用运营商B的交付节点子域（node1.peer-a.op-B.example）进行DNS查找。B的DNS解析器返回传递节点的IP地址。
6. The end user requests the content from B's delivery node. In the case of a cache hit, steps 6, 7, 8, 9, and 10 below do not happen, and the content data is directly returned by the delivery node to the end user. In the case of a cache miss, the content needs to be acquired by the dCDN from the uCDN (not the CSP). The distinguished CDN-Domain peer-a.op-b.example indicates to the dCDN that this content is to be acquired from the uCDN; stripping the CDN-Domain reveals the original CDN-Domain cdn.csp.example, and the dCDN may verify that this CDN-Domain belongs to a known peer (so as to avoid being tricked into serving as an open proxy). It then does a DNS request for an inter-CDN acquisition CDN-Domain as agreed above (in this case, op-b-acq.op-a.example).
6. 最终用户从B的交付节点请求内容。在缓存命中的情况下，下面的步骤6、7、8、9和10不会发生，内容数据由交付节点直接返回给最终用户。在缓存未命中的情况下，dCDN需要从uCDN（而不是CSP）获取内容。可分辨CDN域peer-a.op-b.example向dCDN指示该内容将从uCDN获取；剥离CDN域将显示原始CDN域CDN.csp.example，dCDN可能会验证此CDN域是否属于已知对等方（以避免被欺骗为开放代理）。然后，它对CDN间获取CDN域执行DNS请求，如上所述（在本例中为op-b-acq.op-a.example）。
7. Operator A's DNS resolver processes the DNS request and returns the IP address of a Request Router in Operator A.
7. 运营商A的DNS解析器处理DNS请求并返回运营商A中请求路由器的IP地址。
8. The Request Router for Operator A processes the HTTP request from Operator B's delivery node. Operator A's Request Router recognizes that the request is from a peer CDN rather than an end user because of the dedicated inter-CDN acquisition domain (op-b-acq.op-a.example). (Note that without this specially defined inter-CDN acquisition domain, Operator A would be at risk of redirecting the request back to Operator B, resulting in
8. 运营商A的请求路由器处理来自运营商B的交付节点的HTTP请求。运营商A的请求路由器识别出该请求来自对等CDN而非最终用户，因为该请求是专用的CDN间采集域（op-b-acq.op-A.example）。（请注意，如果没有此专门定义的CDN间获取域，运营商A将面临将请求重定向回运营商B的风险，从而导致
an infinite loop). The Request Router for Operator A selects a suitable delivery node in uCDN to serve the inter-CDN acquisition request and returns a 302 redirect message for a new URL constructed by replacing the hostname with a subdomain of the Operator A's distinguished inter-CDN acquisition domain that points to the selected delivery node.
无限循环）。运营商A的请求路由器在uCDN中选择一个合适的传递节点来服务CDN间获取请求，并返回302重定向消息，该消息针对通过将主机名替换为运营商A指向所选传递节点的可分辨CDN间获取域的子域而构建的新URL。
9. Operator A's DNS resolver processes the DNS request and returns the IP address of the delivery node in Operator A.
9. 运营商A的DNS解析程序处理DNS请求并返回运营商A中传递节点的IP地址。
10. Operator B requests (acquires) the content from Operator A. Although not shown, Operator A processes the rest of the URL: it extracts information identifying the origin server, validates that this server has been registered, and determines the content provider that owns the origin server. It may also perform its own content acquisition steps if needed before returning the content to dCDN.
10. 操作员B向操作员A请求（获取）内容。虽然未显示，但操作员A处理URL的其余部分：它提取标识源服务器的信息，验证此服务器是否已注册，并确定拥有源服务器的内容提供商。如果需要，它还可以在将内容返回到dCDN之前执行自己的内容获取步骤。
The main advantage of this design is that it is simple: each CDN need only know the distinguished CDN-Domain for each peer, with the Upstream CDN "pushing" the Downstream CDN-Domain onto the URL as part of its redirect (step 2), and the Downstream CDN "popping" its CDN-Domain off the URL to expose a CDN-Domain that the Upstream CDN can correctly process. Neither CDN need be aware of the internal structure of the other's URLs. Moreover, the inter-CDN redirection is entirely supported by a single HTTP redirect; neither CDN need be aware of the other's internal redirection mechanism (i.e., whether it is DNS or HTTP based).
这种设计的主要优点是它很简单：每个CDN只需要知道每个对等方的可分辨CDN域，上游CDN将下游CDN域“推”到URL上作为其重定向的一部分（步骤2），下游CDN“弹出”它的CDN域脱离URL，以公开上游CDN可以正确处理的CDN域。两个CDN都不需要知道对方URL的内部结构。此外，CDN间重定向完全由单个HTTP重定向支持；两个CDN都不需要知道对方的内部重定向机制（即，它是基于DNS还是基于HTTP）。
One disadvantage is that the end user's browser is redirected to a new URL that is not in the same domain of the original URL. This has implications on a number of security or validation mechanisms sometimes used on endpoints. For example, it is important that any redirected URL be in the same domain (e.g., csp.example) if the browser is expected to send any cookies associated with that domain. As another example, some video players enforce validation of a cross-domain policy that needs to accommodate the domains involved in the CDN redirection. These problems are generally solvable, but the solutions complicate the example, so we do not discuss them further in this document.
一个缺点是，最终用户的浏览器被重定向到与原始URL不在同一域中的新URL。这会对端点上有时使用的许多安全或验证机制产生影响。例如，如果期望浏览器发送与该域关联的任何cookie，则任何重定向的URL必须位于同一域（例如，csp）中，这一点很重要。另一个例子是，一些视频播放器强制验证跨域策略，该策略需要适应CDN重定向中涉及的域。这些问题通常是可以解决的，但解决方案使示例复杂化，因此我们在本文中不再进一步讨论它们。
We note that this example begins to illustrate some of the interfaces that may be required for CDNI, but it does not require all of them. For example, obtaining information from a dCDN regarding the set of client IP addresses or geographic regions it might be able to serve is an aspect of request routing (specifically of the CDNI Footprint & Capabilities Advertisement interface). Important configuration information such as the distinguished names used for redirection and
我们注意到，这个示例开始说明CDNI可能需要的一些接口，但并不需要所有接口。例如，从dCDN获取关于它可能能够服务的一组客户端IP地址或地理区域的信息是请求路由的一个方面（特别是CDNI Footprint&Capabilities广告接口）。重要的配置信息，如用于重定向和
inter-CDN acquisition could also be conveyed via a CDNI interface (e.g., perhaps the CDNI Control interface). The example also shows how existing HTTP-based methods suffice for the acquisition interface. Arguably, the absolute minimum metadata required for CDNI is the information required to acquire the content, and this information was provided "in-band" in this example by means of the URI handed to the client in the HTTP 302 response. The example also assumes that the CSP does not require any distribution policy (e.g., time window or geo-blocking) or delivery processing to be applied by the interconnected CDNs. Hence, there is no explicit CDNI Metadata interface invoked in this example. There is also no explicit CDNI Logging interface discussed in this example.
CDN间采集也可以通过CDNI接口（例如，可能是CDNI控制接口）进行传输。该示例还显示了现有的基于HTTP的方法如何满足采集接口的要求。可以说，CDNI所需的绝对最小元数据是获取内容所需的信息，在本例中，该信息是通过HTTP 302响应中传递给客户端的URI“带内”提供的。该示例还假设CSP不需要互连CDN应用任何分发策略（例如，时间窗口或地理阻塞）或交付处理。因此，在本例中没有显式调用CDNI元数据接口。本例中也没有讨论明确的CDNI日志接口。
We also note that the step of deciding when a request should be redirected to the dCDN rather than served by the uCDN has been somewhat glossed over. It may be as simple as checking the client IP address against a list of prefixes, or it may be considerably more complex, involving a wide range of factors, such as the geographic location of the client (perhaps determined from a third-party service), CDN load, or specific business rules.
我们还注意到，决定何时将请求重定向到dCDN而不是由uCDN提供服务的步骤有些模糊。它可能与对照前缀列表检查客户端IP地址一样简单，也可能相当复杂，涉及广泛的因素，例如客户端的地理位置（可能由第三方服务确定）、CDN负载或特定的业务规则。
This example uses the "iterative" CDNI request redirection approach. That is, a uCDN performs part of the request redirection function by redirecting the client to a Request Router in the dCDN, which then performs the rest of the redirection function by redirecting to a suitable Surrogate. If request routing is performed in the dCDN using HTTP redirection, this translates in the end user experiencing two successive HTTP redirections. By contrast, the alternative approach of "recursive" CDNI request redirection effectively coalesces these two successive HTTP redirections into a single one, sending the end user directly to the right delivery node in the dCDN. This "recursive" CDNI request routing approach is discussed in the next section.
本例使用“迭代”CDNI请求重定向方法。也就是说，uCDN通过将客户端重定向到dCDN中的请求路由器来执行部分请求重定向功能，该请求路由器然后通过重定向到合适的代理来执行其余的重定向功能。如果使用HTTP重定向在dCDN中执行请求路由，则最终用户将经历两次连续的HTTP重定向。相比之下，“递归”CDNI请求重定向的替代方法有效地将这两个连续的HTTP重定向合并为一个，将最终用户直接发送到dCDN中的正确传递节点。下一节将讨论这种“递归”CDNI请求路由方法。
While the example above uses HTTP, the iterative HTTP redirection mechanism would work over HTTPS in a similar fashion. In order to make sure an end user's HTTPS request is not downgraded to HTTP along the redirection path, it is necessary for every Request Router along the path from the initial uCDN Request Router to the final Surrogate in the dCDN to respond to an incoming HTTPS request with an HTTP redirect containing an HTTPS URL. It should be noted that using HTTPS will have the effect of increasing the total redirection process time and increasing the load on the Request Routers, especially when the redirection path includes many redirects and thus many Secure Socket Layer/Transport Layer Security (SSL/TLS) sessions. In such cases, a recursive HTTP redirection mechanism, as described in an example in the next section, might help to reduce some of these issues.
虽然上面的示例使用HTTP，但迭代HTTP重定向机制将以类似的方式在HTTPS上工作。为了确保最终用户的HTTPS请求不会沿着重定向路径降级为HTTP，从初始uCDN请求路由器到dCDN中最终代理的路径上的每个请求路由器都必须使用包含HTTPS URL的HTTP重定向响应传入的HTTPS请求。应该注意的是，使用HTTPS将增加总重定向处理时间并增加请求路由器上的负载，特别是当重定向路径包括许多重定向，从而包括许多安全套接字层/传输层安全（SSL/TLS）会话时。在这种情况下，递归HTTP重定向机制（如下一节中的示例所述）可能有助于减少其中一些问题。
The following example builds on the previous one to illustrate the use of the request routing interface (specifically, the CDNI Request Routing Redirection interface) to enable "recursive" CDNI request routing. We build on the HTTP-based redirection approach because it illustrates the principles and benefits clearly, but it is equally possible to perform recursive redirection when DNS-based redirection is employed.
下面的示例建立在前一个示例的基础上，以说明如何使用请求路由接口（特别是CDNI请求路由重定向接口）来启用“递归”CDNI请求路由。我们以基于HTTP的重定向方法为基础，因为它清楚地说明了原理和好处，但在使用基于DNS的重定向时，同样可以执行递归重定向。
In contrast to the prior example, the operators need not agree in advance on a CDN-Domain to serve as the target of redirections from the uCDN to dCDN. We assume that the operators agree on some distinguished CDN-Domain that will be used for inter-CDN acquisition of the CSP's content by dCDN. In this example, we'll use op-b-acq.op-a.example.
与前面的示例相反，运营商无需事先就CDN域达成一致，即可作为从uCDN重定向到dCDN的目标。我们假设运营商同意一些可区分的CDN域，这些域将用于dCDN对CSP内容的CDN间获取。在本例中，我们将使用op-b-acq.op-a.example。
We assume the operators also exchange information regarding which requests the dCDN is prepared to serve. For example, the dCDN may be prepared to serve requests from clients in a given geographical region or a set of IP address prefixes. This information may again be provided out of band or via a defined protocol.
我们假设操作员还交换有关dCDN准备服务哪些请求的信息。例如，dCDN可以准备为来自给定地理区域或一组IP地址前缀中的客户端的请求提供服务。该信息可再次在带外或通过定义的协议提供。
We assume DNS is configured in the following way:
我们假设DNS的配置方式如下：
o The content provider is configured to make Operator A the authoritative DNS server for cdn.csp.example (or to return a CNAME for cdn.csp.example for which Operator A is the authoritative DNS server).
o 内容提供商配置为使运营商A成为cdn.csp.example的权威DNS服务器（或返回运营商A为其权威DNS服务器的cdn.csp.example的CNAME）。
o Operator A is configured so that a DNS request for op-b-acq.op-a.example returns a Request Router in Operator A.
o 操作员A的配置使得op-b-acq.op-A的DNS请求返回操作员A中的请求路由器。
o Operator B is configured so that a request for node1.op-b.example/ cdn.csp.example returns the IP address of a delivery node. Note that there might be a number of such delivery nodes.
o 操作员B的配置使得对node1.op-B.example/cdn.csp.example的请求返回传递节点的IP地址。请注意，可能有许多这样的交付节点。
Figure 3 illustrates how a client request for
图3说明了客户端如何请求
http://cdn.csp.example/...rest of URL...
http://cdn.csp.example/...rest 的URL。。。
is handled.
处理好了。
End User Operator B Operator A
|DNS cdn.csp.example | |
|-------------------------------------------------->|
| | |(1)
|IPaddr of A's Request Router |
|<--------------------------------------------------|
|HTTP cdn.csp.example | |
|-------------------------------------------------->|
| | |(2)
| |RR/RI REQ cdn.csp.example|
| |<------------------------|
| | |
| |RR/RI RESP node1.op-b.example
| |------------------------>|
| | |(3)
|302 node1.op-b.example/cdn.csp.example |
|<--------------------------------------------------|
|DNS node1.op-b.example | |
|------------------------>| |
| |(4) |
|IPaddr of B's Delivery Node |
|<------------------------| |
|HTTP node1.op-b.example/cdn.csp.example |
|------------------------>| |
| |(5) |
| |DNS op-b-acq.op-a.example|
| |------------------------>|
| | |(6)
| |IPaddr of A's Request Router
| |<------------------------|
| |HTTP op-b-acq.op-a.example
| |------------------------>|
| | |(7)
End User Operator B Operator A
|DNS cdn.csp.example | |
|-------------------------------------------------->|
| | |(1)
|IPaddr of A's Request Router |
|<--------------------------------------------------|
|HTTP cdn.csp.example | |
|-------------------------------------------------->|
| | |(2)
| |RR/RI REQ cdn.csp.example|
| |<------------------------|
| | |
| |RR/RI RESP node1.op-b.example
| |------------------------>|
| | |(3)
|302 node1.op-b.example/cdn.csp.example |
|<--------------------------------------------------|
|DNS node1.op-b.example | |
|------------------------>| |
| |(4) |
|IPaddr of B's Delivery Node |
|<------------------------| |
|HTTP node1.op-b.example/cdn.csp.example |
|------------------------>| |
| |(5) |
| |DNS op-b-acq.op-a.example|
| |------------------------>|
| | |(6)
| |IPaddr of A's Request Router
| |<------------------------|
| |HTTP op-b-acq.op-a.example
| |------------------------>|
| | |(7)
| |302 node2.op-b-acq.op-a.example
| |<------------------------|
| |DNS node2.op-b-acq.op-a.example
| |------------------------>|
| | |(8)
| |IPaddr of A's Delivery Node
| |<------------------------|
| | |
| |HTTP node2.op-b-acq.op-a.example
| |------------------------>|
| | |(9)
| |Data |
| |<------------------------|
|Data | |
|<------------------------| |
| |302 node2.op-b-acq.op-a.example
| |<------------------------|
| |DNS node2.op-b-acq.op-a.example
| |------------------------>|
| | |(8)
| |IPaddr of A's Delivery Node
| |<------------------------|
| | |
| |HTTP node2.op-b-acq.op-a.example
| |------------------------>|
| | |(9)
| |Data |
| |<------------------------|
|Data | |
|<------------------------| |
Figure 4: Message Flow for Recursive HTTP Redirection
图4：递归HTTP重定向的消息流
The steps illustrated in the figure are as follows:
图中所示的步骤如下：
1. A DNS resolver for Operator A processes the DNS request for its customer based on CDN-Domain cdn.csp.example. It returns the IP address of a Request Router in Operator A.
1. 运营商A的DNS解析程序基于CDN域CDN.csp.example处理其客户的DNS请求。它返回操作员a中请求路由器的IP地址。
2. A Request Router for Operator A processes the HTTP request and recognizes that the end user is best served by another CDN -- specifically one provided by Operator B -- so it queries the CDNI Request Routing Redirection interface of Operator B, providing a set of information about the request including the URL requested. Operator B replies with the DNS name of a delivery node.
2. 运营商A的请求路由器处理HTTP请求，并识别出另一个CDN（特别是运营商B提供的CDN）最适合为最终用户提供服务，因此它查询运营商B的CDNI请求路由重定向接口，提供一组关于请求的信息，包括请求的URL。运营商B使用传递节点的DNS名称进行回复。
3. Operator A returns a 302 redirect message for a new URL obtained from the RI.
3. 操作员A为从RI获得的新URL返回302重定向消息。
4. The end user does a DNS lookup using the hostname of the URL just provided (node1.op-b.example). B's DNS resolver returns the IP address of the corresponding delivery node. Note that, since the name of the delivery node was already obtained from B using the RI, there should not be any further redirection here (in contrast to the iterative method described above.)
4. 最终用户使用刚才提供的URL的主机名进行DNS查找（node1.op-b.example）。B的DNS解析器返回相应传递节点的IP地址。注意，由于交付节点的名称已经使用RI从B获得，因此这里不应该有任何进一步的重定向（与上面描述的迭代方法相反）
5. The end user requests the content from B's delivery node, potentially resulting in a cache miss. In the case of a cache miss, the content needs to be acquired from the uCDN (not the CSP.) The distinguished CDN-Domain op-b.example indicates to the dCDN that this content is to be acquired from another CDN; stripping the CDN-Domain reveals the original CDN-Domain cdn.csp.example. The dCDN may verify that this CDN-Domain
5. 最终用户从B的交付节点请求内容，这可能导致缓存未命中。在缓存未命中的情况下，需要从uCDN（而不是CSP）获取内容。可分辨CDN域op-b。示例向dCDN指示该内容将从另一个CDN获取；剥离CDN域将显示原始CDN域CDN.csp.example。dCDN可以验证此CDN域
belongs to a known peer (so as to avoid being tricked into serving as an open proxy). It then does a DNS request for the inter-CDN Acquisition "distinguished" CDN-Domain as agreed above (in this case, op-b-acq.op-a.example).
属于已知对等方（以避免被骗充当开放代理）。然后，它按照上述约定对CDN间获取“可分辨”CDN域执行DNS请求（在本例中为op-b-acq.op-a.example）。
6. Operator A's DNS resolver processes the DNS request and returns the IP address of a Request Router in Operator A.
6. 运营商A的DNS解析器处理DNS请求并返回运营商A中请求路由器的IP地址。
7. The Request Router for Operator A processes the HTTP request from Operator B's delivery node. Operator A's Request Router recognizes that the request is from a peer CDN rather than an end user because of the dedicated inter-CDN acquisition domain (op-b-acq.op-a.example). (Note that without this specially defined inter-CDN acquisition domain, Operator A would be at risk of redirecting the request back to Operator B, resulting in an infinite loop). The Request Router for Operator A selects a suitable delivery node in the uCDN to serve the inter-CDN acquisition request and returns a 302 redirect message for a new URL constructed by replacing the hostname with a subdomain of the Operator A's distinguished inter-CDN acquisition domain that points to the selected delivery node.
7. 运营商A的请求路由器处理来自运营商B的交付节点的HTTP请求。运营商A的请求路由器识别出该请求来自对等CDN而非最终用户，因为该请求是专用的CDN间采集域（op-b-acq.op-A.example）。（注意，如果没有这个专门定义的CDN间捕获域，运营商A将面临将请求重定向回运营商B的风险，从而导致无限循环）。运营商A的请求路由器在uCDN中选择合适的传递节点来服务CDN间获取请求，并返回302重定向消息，该消息针对通过将主机名替换为运营商A指向所选传递节点的可分辨CDN间获取域的子域而构建的新URL。
8. Operator A recognizes that the DNS request is from a peer CDN rather than an end user (due to the internal CDN-Domain) and so returns the address of a delivery node. (Note that without this specially defined internal domain, Operator A would be at risk of redirecting the request back to Operator B, resulting in an infinite loop.)
8. 操作员A识别出DNS请求来自对等CDN而不是最终用户（由于内部CDN域），因此返回传递节点的地址。（请注意，如果没有这个专门定义的内部域，运营商A将面临将请求重定向回运营商B的风险，从而导致无限循环。）
9. Operator B requests (acquires) the content from Operator A. Operator A serves content for the requested CDN-Domain to the dCDN. Although not shown, it is at this point that Operator A processes the rest of the URL: it extracts information identifying the origin server, validates that this server has been registered, and determines the content provider that owns the origin server. It may also perform its own content acquisition steps if needed before returning the content to the dCDN.
9. 运营商B从运营商A请求（获取）内容。运营商A向dCDN提供所请求CDN域的内容。虽然未显示，但操作员A此时处理URL的其余部分：它提取标识源服务器的信息，验证此服务器是否已注册，并确定拥有源服务器的内容提供商。如果需要，它还可以在将内容返回到dCDN之前执行自己的内容获取步骤。
Recursive redirection has the advantage (over iterative redirection) of being more transparent from the end user's perspective but the disadvantage of each CDN exposing more of its internal structure (in particular, the addresses of edge caches) to peer CDNs. By contrast, iterative redirection does not require the dCDN to expose the addresses of its edge caches to the uCDN.
递归重定向的优点（相对于迭代重定向）是从最终用户的角度来看更加透明，但缺点是每个CDN向对等CDN公开更多的内部结构（特别是边缘缓存的地址）。相反，迭代重定向不需要dCDN向uCDN公开其边缘缓存的地址。
This example happens to use HTTP-based redirection in both CDN A and CDN B, but a similar example could be constructed using DNS-based redirection in either CDN. Hence, the key point to take away here is simply that the end user only sees a single redirection of some type, as opposed to the pair of redirections in the prior (iterative) example.
此示例碰巧在CDN A和CDN B中都使用了基于HTTP的重定向，但在任一CDN中都可以使用基于DNS的重定向构建类似的示例。因此，这里要说明的关键点是，最终用户只看到某种类型的单一重定向，而不是前面（迭代）示例中的一对重定向。
The use of the RI requires that the request routing mechanism be appropriately configured and bootstrapped, which is not shown here. More discussion on the bootstrapping of interfaces is provided in Section 4
RI的使用需要适当地配置和引导请求路由机制，这里没有显示。第4节提供了关于接口引导的更多讨论
In this section we walk through a simple example using DNS-based redirection for request redirection from the uCDN to the dCDN (as well as for request routing inside the dCDN and the uCDN). As noted in Section 2.1, DNS-based redirection has certain advantages over HTTP-based redirection (notably, it is transparent to the end user) as well as some drawbacks (notably, the client IP address is not visible to the Request Router).
在本节中，我们将介绍一个简单的示例，使用基于DNS的重定向将请求从uCDN重定向到dCDN（以及dCDN和uCDN内的请求路由）。如第2.1节所述，与基于HTTP的重定向相比，基于DNS的重定向具有某些优势（值得注意的是，它对最终用户是透明的），同时也存在一些缺点（值得注意的是，客户端IP地址对请求路由器不可见）。
As before, Operator A has to learn the set of requests that the dCDN is willing or able to serve (e.g., which client IP address prefixes or geographic regions are part of the dCDN footprint). We assume Operator B has and makes known to Operator A some unique identifier that can be used for the construction of a distinguished CDN-Domain, as shown in more detail below. (This identifier strictly needs only to be unique within the scope of Operator A, but a globally unique identifier, such as an Autonomous System (AS) number assigned to B, is one easy way to achieve that.) Also, Operator A obtains the NS records for Operator B's externally visible redirection servers. Also, as before, a distinguished CDN-Domain, such as op-b-acq.op-a.example, must be assigned for inter-CDN acquisition.
与之前一样，运营商A必须了解dCDN愿意或能够服务的请求集（例如，哪些客户端IP地址前缀或地理区域是dCDN足迹的一部分）。我们假设运营商B拥有并使运营商A知道一些可用于构建可分辨CDN域的唯一标识符，如下所示。（该标识符严格来说只需要在运营商A的范围内是唯一的，但全局唯一的标识符，例如分配给B的自治系统（as）号，是实现这一点的一种简单方法。）此外，运营商A获得运营商B外部可见重定向服务器的NS记录。此外，与前面一样，必须为CDN间采集分配可分辨CDN域，例如op-b-acq.op-a.example。
We assume DNS is configured in the following way:
我们假设DNS的配置方式如下：
o The CSP is configured to make Operator A the authoritative DNS server for cdn.csp.example (or to return a CNAME for cdn.csp.example for which Operator A is the authoritative DNS server).
o CSP配置为使运营商A成为cdn.CSP.example的权威DNS服务器（或返回运营商A为其权威DNS服务器的cdn.CSP.example的CNAME）。
o When uCDN sees a request best served by the dCDN, it returns CNAME and NS records for "b.cdn.csp.example", where "b" is the unique identifier assigned to Operator B. (It may, for example, be an AS number assigned to Operator B.)
o 当uCDN看到dCDN最适合处理的请求时，它返回“b.cdn.csp.example”的CNAME和NS记录，其中“b”是分配给操作员b的唯一标识符。（例如，它可能是分配给操作员b的AS号。）
o The dCDN is configured so that a request for "b.cdn.csp.example" returns a delivery node in the dCDN.
o dCDN的配置使对“b.cdn.csp.example”的请求返回dCDN中的传递节点。
o The uCDN is configured so that a request for "op-b-acq.op-a.example" returns a delivery node in the uCDN.
o uCDN的配置使“op-b-acq.op-a.example”请求返回uCDN中的传递节点。
Figure 5 depicts the exchange of DNS and HTTP requests. The main differences from Figure 3 are the lack of HTTP redirection and transparency to the end user.
图5描述了DNS和HTTP请求的交换。与图3的主要区别在于缺少HTTP重定向和对最终用户的透明性。
End User Operator B Operator A
|DNS cdn.csp.example | |
|-------------------------------------------------->|
| | |(1)
|CNAME b.cdn.csp.example | |
|<--------------------------------------------------|
| | |
|DNS b.cdn.csp.example | |
|-------------------------------------------------->|
| | |(2)
|NS records for b.cdn.csp.example + |
|Glue AAAA/A records for b.cdn.csp.example |
|<--------------------------------------------------|
| | |
|DNS b.cdn.csp.example | |
|------------------------>| |
| |(3) |
|IPaddr of B's Delivery Node |
|<------------------------| |
|HTTP cdn.csp.example | |
|------------------------>| |
| |(4) |
| |DNS op-b-acq.op-a.example|
| |------------------------>|
| | |(5)
| |IPaddr of A's Delivery Node
| |<------------------------|
| |HTTP op-b-acq.op-a.example
| |------------------------>|
| | |(6)
| |Data |
| |<------------------------|
|Data | |
|<------------------------| |
End User Operator B Operator A
|DNS cdn.csp.example | |
|-------------------------------------------------->|
| | |(1)
|CNAME b.cdn.csp.example | |
|<--------------------------------------------------|
| | |
|DNS b.cdn.csp.example | |
|-------------------------------------------------->|
| | |(2)
|NS records for b.cdn.csp.example + |
|Glue AAAA/A records for b.cdn.csp.example |
|<--------------------------------------------------|
| | |
|DNS b.cdn.csp.example | |
|------------------------>| |
| |(3) |
|IPaddr of B's Delivery Node |
|<------------------------| |
|HTTP cdn.csp.example | |
|------------------------>| |
| |(4) |
| |DNS op-b-acq.op-a.example|
| |------------------------>|
| | |(5)
| |IPaddr of A's Delivery Node
| |<------------------------|
| |HTTP op-b-acq.op-a.example
| |------------------------>|
| | |(6)
| |Data |
| |<------------------------|
|Data | |
|<------------------------| |
Figure 5: Message Flow for DNS-Based Redirection
图5：基于DNS的重定向的消息流
The steps illustrated in the figure are as follows:
图中所示的步骤如下：
1. The Request Router for Operator A processes the DNS request for CDN-Domain cdn.csp.example and recognizes that the end user is best served by another CDN. (This may depend on the IP address of the user's LDNS resolver, or other information discussed below.) The Request Router returns a DNS CNAME response by "stacking" the distinguished identifier for Operator B onto the original CDN-Domain (e.g., b.cdn.csp.example).
1. 运营商A的请求路由器处理CDN域CDN.csp.example的DNS请求，并识别最终用户最好由另一个CDN服务。（这可能取决于用户的LDNS解析器的IP地址，或下面讨论的其他信息。）请求路由器通过将运营商B的可分辨标识符“堆叠”到原始CDN域（例如，B.CDN.csp）来返回DNS CNAME响应。
2. The end user sends a DNS query for the modified CDN-Domain (i.e., b.cdn.csp.example) to Operator A's DNS server. The Request Router for Operator A processes the DNS request and returns a delegation to b.cdn.csp.example by sending an NS record plus glue records pointing to Operator B's DNS server. (This extra step is necessary since typical DNS implementation won't follow an NS record when it is sent together with a CNAME record, thereby necessitating a two-step approach.)
2. 最终用户向运营商a的DNS服务器发送修改后的CDN域（即b.CDN.csp.示例）的DNS查询。运营商A的请求路由器处理DNS请求并返回到b.cdn.csp的委派。例如，通过发送指向运营商b的DNS服务器的NS记录和粘合记录。（这一额外步骤是必要的，因为当NS记录与CNAME记录一起发送时，典型的DNS实现不会遵循NS记录，因此需要两步方法。）
3. The end user sends a DNS query for the modified CDN-Domain (i.e., b.cdn.csp.example) to Operator B's DNS server, using the NS and AAAA/A records received in step 2. This causes B's Request Router to respond with a suitable delivery node.
3. 最终用户使用在步骤2中接收到的NS和AAAA/a记录，向运营商b的DNS服务器发送修改后的CDN域（即b.CDN.csp.example）的DNS查询。这会导致B的请求路由器使用合适的传递节点进行响应。
4. The end user requests the content from B's delivery node. The requested URL contains the name cdn.csp.example. (Note that the returned CNAME does not affect the URL.) At this point, the delivery node has the correct IP address of the end user and can do an HTTP 302 redirect if the redirections in steps 2 and 3 were incorrect. Otherwise, B verifies that this CDN-Domain belongs to a known peer (so as to avoid being tricked into serving as an open proxy). It then does a DNS request for an "internal" CDN-Domain as agreed above (op-b-acq.op-a.example).
4. 最终用户从B的交付节点请求内容。请求的URL包含名称cdn.csp.example。（请注意，返回的CNAME不会影响URL。）此时，传递节点具有最终用户的正确IP地址，如果步骤2和3中的重定向不正确，则可以执行HTTP 302重定向。否则，B将验证该CDN域是否属于已知对等方（以避免被欺骗而充当开放代理）。然后，它按照上述约定对“内部”CDN域执行DNS请求（op-b-acq.op-a.example）。
5. Operator A recognizes that the DNS request is from a peer CDN rather than an end user (due to the internal CDN-Domain) and so returns the address of a delivery node in uCDN.
5. 操作员A识别出DNS请求来自对等CDN而不是最终用户（由于内部CDN域），因此返回uCDN中传递节点的地址。
6. Operator A serves content to dCDN. Although not shown, it is at this point that Operator A processes the rest of the URL: it extracts information identifying the origin server, validates that this server has been registered, and determines the content provider that owns the origin server.
6. 操作员A向dCDN提供内容。虽然未显示，但操作员A此时处理URL的其余部分：它提取标识源服务器的信息，验证此服务器是否已注册，并确定拥有源服务器的内容提供商。
The advantages of this approach are that it is more transparent to the end user and requires fewer round trips than HTTP-based redirection (in its worst case, i.e., when none of the needed DNS information is cached). A potential problem is that the Upstream CDN
这种方法的优点是，它对最终用户更透明，需要的往返次数比基于HTTP的重定向少（在最坏的情况下，即没有缓存所需的DNS信息时）。一个潜在的问题是上游CDN
depends on being able to learn the correct Downstream CDN that serves the end user from the client address in the DNS request. In standard DNS operation, the uCDN will only obtain the address of the client's LDNS resolver, which is not guaranteed to be in the same network (or geographic region) as the client. If not (e.g., the end user uses a global DNS service), then the Upstream CDN cannot determine the appropriate Downstream CDN to serve the end user. In this case, and assuming the uCDN is capable of detecting that situation, one option is for the Upstream CDN to treat the end user as it would any user not connected to a peer CDN. Another option is for the Upstream CDN to "fall back" to a pure HTTP-based redirection strategy in this case (i.e., use the first method). Note that this problem affects existing CDNs that rely on DNS to determine where to redirect client requests, but the consequences are arguably less serious for CDNI since the LDNS is likely in the same network as the dCDN serves.
取决于能否从DNS请求中的客户端地址了解为最终用户服务的正确下游CDN。在标准DNS操作中，uCDN将仅获取客户端的LDNS解析程序的地址，该地址不保证与客户端位于同一网络（或地理区域）。如果没有（例如，最终用户使用全局DNS服务），则上游CDN无法确定为最终用户服务的适当下游CDN。在这种情况下，并且假设uCDN能够检测到这种情况，一个选项是上游CDN将最终用户视为未连接到对等CDN的任何用户。另一种选择是，在这种情况下，上游CDN“退回”到纯基于HTTP的重定向策略（即，使用第一种方法）。请注意，此问题会影响依赖DNS确定将客户端请求重定向到何处的现有CDN，但由于LDN可能与dCDN位于同一网络中，因此CDNI的后果可能不那么严重。
As with the prior example, this example partially illustrates the various interfaces involved in CDNI. Operator A could learn dynamically from Operator B the set of prefixes or regions that B is willing and able to serve via the CDNI Footprint & Capabilities Advertisement interface. The distinguished name used for acquisition and the identifier for Operator B that is prepended to the CDN-Domain on redirection are examples of information elements that might also be conveyed by CDNI interfaces (or, alternatively, statically configured). As before, minimal metadata sufficient to obtain the content is carried "in-band" as part of the redirection process, and standard HTTP is used for inter-CDN acquisition. There is no explicit CDNI Logging interface discussed in this example.
与前面的示例一样，本示例部分说明了CDNI中涉及的各种接口。运营商A可以通过CDNI Footprint&Capabilities广告界面从运营商B动态学习B愿意并能够提供服务的前缀或区域集。用于获取的可分辨名称和重定向时前置到CDN域的操作员B的标识符是也可能由CDNI接口（或者静态配置）传送的信息元素的示例。如前所述，作为重定向过程的一部分，“带内”携带足以获取内容的最小元数据，并且使用标准HTTP进行CDN间的获取。本例中没有讨论明确的CDNI日志接口。
Although it is possible to use DNSSEC in combination with the Iterative DNS-based Redirection mechanism explained above, it is important to note that the uCDN might have to sign records on the fly, since the CNAME returned, and thus the signature provided, can potentially be different for each incoming query. Although there is nothing preventing a uCDN from performing such on-the-fly signing, this might be computationally expensive. In the case where the number of dCDNs, and thus the number of different CNAMEs to return, is relatively stable, an alternative solution would be for the uCDN to pre-generate signatures for all possible CNAMEs. For each incoming query, the uCDN would then determine the appropriate CNAME and return it together with the associated pre-generated signature. Note: In the latter case, maintaining the serial number and signature of Start of Authority (SOA) might be an issue since, technically, it should change every time a different CNAME is used. However, since,
尽管可以将DNSSEC与上面解释的基于DNS的迭代重定向机制结合使用，但需要注意的是，uCDN可能必须动态地对记录进行签名，因为CNAME返回，因此提供的签名对于每个传入查询都可能不同。尽管没有任何东西阻止uCDN执行这种动态签名，但这可能会导致计算成本高昂。在dcdn的数量以及由此返回的不同CNAMEs的数量相对稳定的情况下，另一种解决方案是uCDN为所有可能的CNAMEs预生成签名。对于每个传入的查询，uCDN随后将确定适当的CNAME，并将其与相关的预生成签名一起返回。注意：在后一种情况下，维护授权启动（SOA）的序列号和签名可能是一个问题，因为从技术上讲，每次使用不同的CNAME时，它都应该更改。但是,，
in practice, direct SOA queries are relatively rare, a uCDN could defer incrementing the serial number and resigning the SOA until it is queried and then do it on-the-fly.
在实践中，直接SOA查询相对较少，uCDN可以推迟增加序列号和重新指定SOA，直到查询到它，然后动态执行。
Note also that the NS record and the glue records used in step 2 in the previous section should generally be identical to those of their authoritative zone managed by Operator B. Even if they differ, this will not make the DNS resolution process fail, but the client DNS server will prefer the authoritative data in its cache and use it for subsequent queries. Such inconsistency is a general operational issue of DNS, but it may be more important for this architecture because the uCDN (Operator A) would rely on the consistency to make the resulting redirection work as intended. In general, it is the administrator's responsibility to make them consistent.
还请注意，前一节步骤2中使用的NS记录和glue记录通常应与其由运营商B管理的权威区域的记录相同。即使它们不同，这也不会导致DNS解析过程失败，但是客户端DNS服务器将更喜欢缓存中的权威数据，并将其用于后续查询。这种不一致性是DNS的一个普遍操作问题，但对于这种体系结构来说可能更为重要，因为uCDN（运营商a）将依赖于一致性使结果重定向按预期工作。总的来说，管理员有责任使它们保持一致。
There could be situations where being able to dynamically discover the set of requests that a given dCDN is willing and able to serve is beneficial. For example, a CDN might at one time be able to serve a certain set of client IP prefixes, but that set might change over time due to changes in the topology and routing policies of the IP network. The following example illustrates this capability. We have chosen the example of DNS-based redirection, but HTTP-based redirection could equally well use this approach.
在某些情况下，能够动态发现给定dCDN愿意并能够服务的请求集是有益的。例如，CDN可能在某一时间能够为某一组客户端IP前缀提供服务，但该组前缀可能会随着时间的推移而变化，这是由于IP网络的拓扑和路由策略发生了变化。下面的示例说明了此功能。我们选择了基于DNS的重定向示例，但是基于HTTP的重定向同样可以很好地使用这种方法。
End User Operator B Operator A
|DNS cdn.csp.example | |
|-------------------------------------------------->|
| | |(1)
| | RI REQ op-b.example |
| |<------------------------|
| | |(2)
| | RI REPLY |
| |------------------------>|
| | |(3)
|CNAME b.cdn.csp.example | |
|NS records for b.cdn.csp.example |
|<--------------------------------------------------|
|DNS b.cdn.csp.example | |
|------------------------>| |
| |(2) |
|IPaddr of B's Delivery Node |
|<------------------------| |
|HTTP cdn.csp.example | |
|------------------------>| |
| |(3) |
| |DNS op-b-acq.op-a.example|
| |------------------------>|
| | |(4)
| |IPaddr of A's Delivery Node
| |<------------------------|
| |HTTP op-b-acq.op-a.example
| |------------------------>|
| | |(5)
| |Data |
| |<------------------------|
|Data | |
|<------------------------| |
End User Operator B Operator A
|DNS cdn.csp.example | |
|-------------------------------------------------->|
| | |(1)
| | RI REQ op-b.example |
| |<------------------------|
| | |(2)
| | RI REPLY |
| |------------------------>|
| | |(3)
|CNAME b.cdn.csp.example | |
|NS records for b.cdn.csp.example |
|<--------------------------------------------------|
|DNS b.cdn.csp.example | |
|------------------------>| |
| |(2) |
|IPaddr of B's Delivery Node |
|<------------------------| |
|HTTP cdn.csp.example | |
|------------------------>| |
| |(3) |
| |DNS op-b-acq.op-a.example|
| |------------------------>|
| | |(4)
| |IPaddr of A's Delivery Node
| |<------------------------|
| |HTTP op-b-acq.op-a.example
| |------------------------>|
| | |(5)
| |Data |
| |<------------------------|
|Data | |
|<------------------------| |
Figure 6: Message Flow for Dynamic Footprint Discovery
图6：动态足迹发现的消息流
This example differs from the one in Figure 5 only in the addition of an RI request (step 2) and corresponding response (step 3). The RI REQ could be a message such as "Can you serve clients from this IP Prefix?" or it could be "Provide the list of client IP prefixes you can currently serve". In either case the response might be cached by Operator A to avoid repeatedly asking the same question. Alternatively, or in addition, Operator B may spontaneously advertise to Operator A information (or changes) on the set of requests it is willing and able to serve on behalf of Operator A; in that case, Operator B may spontaneously issue RR/RI REPLY messages that are not
该示例与图5中的示例不同，只是添加了一个RI请求（步骤2）和相应的响应（步骤3）。RI REQ可以是一条消息，例如“您可以从此IP前缀为客户端提供服务吗？”或者可以是“提供您当前可以提供服务的客户端IP前缀列表”。在任何一种情况下，操作员A都可能缓存响应，以避免重复询问相同的问题。或者，或者另外，运营商B可以自发地向运营商A发布其愿意并能够代表运营商A服务的一组请求的信息（或变更）；在这种情况下，操作员B可能会自发地发出RR/RI回复消息，但这些消息不是
in direct response to a corresponding RR/RI REQ message. (Note that the issues of determining the client's subnet from DNS requests, as described above, are exactly the same here as in Section 3.4.)
直接响应相应的RR/RI REQ消息。（请注意，如上所述，通过DNS请求确定客户端子网的问题与第3.4节中的问题完全相同。）
Once Operator A obtains the RI response, it is now able to determine that Operator B's CDN is an appropriate dCDN for this request and therefore a valid candidate dCDN to consider in its redirection decision. If that dCDN is selected, the redirection and serving of the request proceeds as before (i.e., in the absence of dynamic footprint discovery).
一旦操作员A获得RI响应，现在就能够确定运营商B的CDN是该请求的合适的DCDN，因此是在其重定向决策中考虑的有效候选DCDN。如果选择了该dCDN，则请求的重定向和服务将一如既往地进行（即，在没有动态足迹发现的情况下）。
The following example illustrates how the CDNI Control interface may be used to achieve pre-positioning of an item of content in the dCDN. In this example, user requests for a particular content, and corresponding redirection of such requests from Operator A to Operator B CDN, may (or may not) have taken place earlier. Then, at some point in time, the uCDN (for example, in response to a corresponding Trigger from the Content Provider) uses the CI to request that content identified by a particular URL be removed from dCDN. The following diagram illustrates the operation. It should be noted that a uCDN will typically not know whether a dCDN has cached a given content item; however, it may send the content removal request to make sure no cached versions remain to satisfy any contractual obligations it may have.
以下示例说明了如何使用CDNI控制接口来实现dCDN中内容项的预定位。在此示例中，用户对特定内容的请求，以及从运营商a到运营商B CDN的此类请求的相应重定向，可能（也可能不）发生在更早的时候。然后，在某个时间点，uCDN（例如，响应来自内容提供商的相应触发器）使用CI请求从dCDN中删除由特定URL标识的内容。下图说明了该操作。应该注意，uCDN通常不知道dCDN是否缓存了给定的内容项；但是，它可能会发送内容删除请求，以确保没有保留任何缓存版本来满足其可能承担的任何合同义务。
End User Operator B Operator A
| |CI purge cdn.csp.example/...
| |<------------------------|
| | |
| |CI OK |
| |------------------------>|
| | |
End User Operator B Operator A
| |CI purge cdn.csp.example/...
| |<------------------------|
| | |
| |CI OK |
| |------------------------>|
| | |
Figure 7: Message Flow for Content Removal
图7：内容删除的消息流
The CI is used to convey the request from the uCDN to the dCDN that some previously acquired content should be deleted. The URL in the request specifies which content to remove. This example corresponds to a DNS-based redirection scenario such as Section 3.4. If HTTP-based redirection had been used, the URL for removal would be of the form peer-a.op-b.example/cdn.csp.example/...
CI用于将uCDN的请求传递给dCDN，要求删除一些以前获取的内容。请求中的URL指定要删除的内容。此示例对应于基于DNS的重定向场景，如第3.4节。如果使用了基于HTTP的重定向，则要删除的URL的格式为peer-a.op-b.example/cdn.csp.example/。。。
The dCDN is expected to confirm to the uCDN, as illustrated by the CI OK message, the completion of the removal of the targeted content from all the caches in the dCDN.
如CI OK消息所示，dCDN将向uCDN确认完成从dCDN中的所有缓存中删除目标内容。
The following example illustrates how the CI may be used to pre-position an item of content in the dCDN. In this example, Operator A uses the CDNI Metadata interface to request that content identified by a particular URL be pre-positioned into Operator B CDN.
以下示例说明了如何使用CI在dCDN中预先定位内容项。在此示例中，运营商A使用CDNI元数据接口请求将特定URL标识的内容预先定位到运营商B CDN中。
End User Operator B Operator A
最终用户操作员B操作员A
| |CI pre-position cdn.csp.example/...
| |<------------------------|
| | |(1)
| |CI OK |
| |------------------------>|
| | |
| |DNS op-b-acq.op-a.example|
| |------------------------>|
| | |(2)
| |IPaddr of A's Delivery Node
| |<------------------------|
| |HTTP op-b-acq.op-a.example
| |------------------------>|
| | |(3)
| |Data |
| |<------------------------|
|DNS cdn.csp.example | |
|--------------------------------------------->|
| | |(4)
|IPaddr of A's Request Router |
|<---------------------------------------------|
|HTTP cdn.csp.example| |
|--------------------------------------------->|
| | |(5)
|302 peer-a.op-b.example/cdn.csp.example |
|<---------------------------------------------|
|DNS peer-a.op-b.example |
|------------------->| |
| |(6) |
|IPaddr of B's Delivery Node |
|<-------------------| |
|HTTP peer-a.op-b.example/cdn.csp.example |
|------------------->| |
| |(7) |
|Data | |
|<-------------------| |
| |CI pre-position cdn.csp.example/...
| |<------------------------|
| | |(1)
| |CI OK |
| |------------------------>|
| | |
| |DNS op-b-acq.op-a.example|
| |------------------------>|
| | |(2)
| |IPaddr of A's Delivery Node
| |<------------------------|
| |HTTP op-b-acq.op-a.example
| |------------------------>|
| | |(3)
| |Data |
| |<------------------------|
|DNS cdn.csp.example | |
|--------------------------------------------->|
| | |(4)
|IPaddr of A's Request Router |
|<---------------------------------------------|
|HTTP cdn.csp.example| |
|--------------------------------------------->|
| | |(5)
|302 peer-a.op-b.example/cdn.csp.example |
|<---------------------------------------------|
|DNS peer-a.op-b.example |
|------------------->| |
| |(6) |
|IPaddr of B's Delivery Node |
|<-------------------| |
|HTTP peer-a.op-b.example/cdn.csp.example |
|------------------->| |
| |(7) |
|Data | |
|<-------------------| |
Figure 8: Message Flow for Content Pre-Positioning
图8：内容预定位的消息流
The steps illustrated in the figure are as follows:
图中所示的步骤如下：
1. Operator A uses the CI to request that Operator B pre-position a particular content item identified by its URL. Operator B responds by confirming that it is willing to perform this operation.
1. 操作员A使用CI请求操作员B预先定位由其URL标识的特定内容项。操作员B的回应是确认其愿意执行此操作。
Steps 2 and 3 are exactly the same as steps 5 and 6 of Figure 3, only this time those steps happen as the result of the Pre-positioning request instead of as the result of a cache miss.
步骤2和3与图3的步骤5和6完全相同，只是这次这些步骤是由于预定位请求而不是缓存未命中而发生的。
Steps 4, 5, 6, and 7 are exactly the same as steps 1, 2, 3, and 4 of Figure 3, only this time, Operator B's CDN can serve the end-user request without triggering dynamic content acquisition, since the content has been pre-positioned in the dCDN. Note that, depending on dCDN operations and policies, the content pre-positioned in the dCDN may be pre-positioned to all, or a subset of, dCDN caches. In the latter case, intra-CDN dynamic content acquisition may take place inside the dCDN serving requests from caches on which the content has not been pre-positioned; however, such intra-CDN dynamic acquisition would not involve the uCDN.
步骤4、5、6和7与图3的步骤1、2、3和4完全相同，只是这一次，运营商B的CDN可以在不触发动态内容获取的情况下为最终用户请求提供服务，因为内容已经预先定位在dCDN中。注意，根据dCDN操作和策略，预先定位在dCDN中的内容可以预先定位到所有dCDN缓存或dCDN缓存的子集。在后一种情况下，CDN内动态内容获取可以发生在dCDN内部，该dCDN服务于来自未预先定位内容的缓存的请求；然而，这种CDN内动态捕获将不涉及uCDN。
In this section, we walk through a simple example illustrating a scenario of asynchronously exchanging CDNI Metadata, where the Downstream CDN obtains CDNI Metadata for content ahead of a corresponding content request. The example that follows assumes that HTTP-based inter-CDN redirection and recursive CDNI request routing are used, as in Section 3.3. However, Asynchronous exchange of CDNI Metadata is similarly applicable to DNS-based inter-CDN redirection and iterative request routing (in which cases the CDNI Metadata may be used at slightly different processing stages of the message flows).
在本节中，我们将通过一个简单的示例演示异步交换CDNI元数据的场景，其中下游CDN在相应的内容请求之前获取内容的CDNI元数据。下面的示例假设使用基于HTTP的CDN间重定向和递归CDNI请求路由，如第3.3节所示。然而，CDNI元数据的异步交换同样适用于基于DNS的CDN间重定向和迭代请求路由（在这种情况下，CDNI元数据可在消息流的稍微不同的处理阶段使用）。
End User Operator B Operator A
| | |
| |CI pre-position (Trigger)|
| |<------------------------|(1)
| | |
| |CI OK |
| |------------------------>|(2)
| | |
| |MI pull REQ |
| |------------------------>|(3)
| | |
| |MI metadata REP |(4)
| | |
| | |
| CONTENT REQUEST | |
|-------------------------------------------------->|(5)
| | |
| | RI REQ |
| |<------------------------|(6)
| | |
| | RI RESP |
| |------------------------>|(7)
| | |
| CONTENT REDIRECTION | |
|<--------------------------------------------------|(8)
| | |
| CONTENT REQUEST | |
|------------------------>|(9) |
| | |
: : :
| CONTENT DATA | |
|<------------------------| |(10)
End User Operator B Operator A
| | |
| |CI pre-position (Trigger)|
| |<------------------------|(1)
| | |
| |CI OK |
| |------------------------>|(2)
| | |
| |MI pull REQ |
| |------------------------>|(3)
| | |
| |MI metadata REP |(4)
| | |
| | |
| CONTENT REQUEST | |
|-------------------------------------------------->|(5)
| | |
| | RI REQ |
| |<------------------------|(6)
| | |
| | RI RESP |
| |------------------------>|(7)
| | |
| CONTENT REDIRECTION | |
|<--------------------------------------------------|(8)
| | |
| CONTENT REQUEST | |
|------------------------>|(9) |
| | |
: : :
| CONTENT DATA | |
|<------------------------| |(10)
Figure 9: Message Flow for Asynchronous CDNI Metadata
图9：异步CDNI元数据的消息流
The steps illustrated in the figure are as follows:
图中所示的步骤如下：
1. Operator A uses the CI to trigger the signaling of the availability of CDNI Metadata to Operator B.
1. 运营商A使用CI触发向运营商B发送CDNI元数据可用性的信令。
2. Operator B acknowledges the receipt of this Trigger.
2. 操作员B确认收到该触发器。
3. Operator B requests the latest metadata from Operator A using the MI.
3. 操作员B使用MI从操作员A请求最新元数据。
4. Operator A replies with the requested metadata. This document does not constrain how the CDNI Metadata information is actually represented. For the purposes of this example, we assume that Operator A provides CDNI Metadata to Operator B indicating that:
4. 操作员A使用请求的元数据进行答复。本文档不限制CDNI元数据信息的实际表示方式。在本例中，我们假设操作员A向操作员B提供CDNI元数据，表明：
* this CDNI Metadata is applicable to any content referenced by some CDN-Domain.
* 此CDNI元数据适用于某些CDN域引用的任何内容。
* this CDNI Metadata consists of a distribution policy requiring enforcement by the delivery node of a specific per-request authorization mechanism (e.g., URI signature or token validation).
* 此CDNI元数据由一个分发策略组成，该分发策略要求交付节点强制执行特定的每请求授权机制（例如，URI签名或令牌验证）。
5. A Content Request occurs as usual.
5. 内容请求照常发生。
6. A CDNI Request Routing Redirection request (RI REQ) is issued by Operator A's CDN, as discussed in Section 3.3. Operator B's Request Router can access the CDNI Metadata that are relevant to the requested content and that have been pre-positioned as per Steps 1-4, which may or may not affect the response.
6. CDNI请求路由重定向请求（RI REQ）由运营商A的CDN发出，如第3.3节所述。运营商B的请求路由器可以访问与请求内容相关的CDNI元数据，这些元数据已经按照步骤1-4预先定位，这可能会影响响应，也可能不会影响响应。
7. Operator B's Request Router issues a CDNI Request Routing Redirection response (RI RESP) as in Section 3.3.
7. 运营商B的请求路由器发出CDNI请求路由重定向响应（RI RESP），如第3.3节所述。
8. Operator B performs content redirection as discussed in Section 3.3.
8. 操作员B执行第3.3节中讨论的内容重定向。
9. On receipt of the Content Request by the end user, the delivery node detects that previously acquired CDNI Metadata is applicable to the requested content. In accordance with the specific CDNI metadata of this example, the delivery node will invoke the appropriate per-request authorization mechanism, before serving the content. (Details of this authorization are not shown.)
9. 在最终用户接收到内容请求时，交付节点检测到先前获取的CDNI元数据适用于请求的内容。根据本例的特定CDNI元数据，交付节点将在服务内容之前调用适当的每请求授权机制。（未显示此授权的详细信息。）
10. Assuming successful per-request authorization, serving of Content Data (possibly preceded by inter-CDN acquisition) proceeds as in Section 3.3.
10. 假设每个请求的授权成功，内容数据的服务（可能在CDN间获取之前）将按照第3.3节进行。
In this section we walk through a simple example illustrating a scenario of Synchronous CDNI Metadata acquisition, in which the Downstream CDN obtains CDNI Metadata for content at the time of handling a first request for the corresponding content. As in the preceding section, this example assumes that HTTP-based inter-CDN
在本节中，我们将通过一个简单的示例演示同步CDNI元数据获取的场景，其中下游CDN在处理对相应内容的第一个请求时获取内容的CDNI元数据。如前一节所述，本示例假设基于HTTP的CDN之间
redirection and recursive CDNI request routing are used (as in Section 3.3), but dynamic CDNI Metadata acquisition is applicable to other variations of request routing.
使用重定向和递归CDNI请求路由（如第3.3节所述），但动态CDNI元数据获取适用于请求路由的其他变体。
End User Operator B Operator A
| | |
| CONTENT REQUEST | |
|-------------------------------------------------->|(1)
| | |
| | RI REQ |
| (2)|<------------------------|
| | |
| | MI REQ |
| (3)|------------------------>|
| | MI RESP |
| |<------------------------|(4)
| | |
| | RI RESP |
| |------------------------>|(5)
| | |
| | |
| CONTENT REDIRECTION | |
|<--------------------------------------------------|(6)
| | |
| CONTENT REQUEST | |
|------------------------>|(7) |
| | |
| | MI REQ |
| (8)|------------------------>|
| | MI RESP |
| |<------------------------|(9)
| | |
: : :
| CONTENT DATA | |
|<------------------------| |(10)
End User Operator B Operator A
| | |
| CONTENT REQUEST | |
|-------------------------------------------------->|(1)
| | |
| | RI REQ |
| (2)|<------------------------|
| | |
| | MI REQ |
| (3)|------------------------>|
| | MI RESP |
| |<------------------------|(4)
| | |
| | RI RESP |
| |------------------------>|(5)
| | |
| | |
| CONTENT REDIRECTION | |
|<--------------------------------------------------|(6)
| | |
| CONTENT REQUEST | |
|------------------------>|(7) |
| | |
| | MI REQ |
| (8)|------------------------>|
| | MI RESP |
| |<------------------------|(9)
| | |
: : :
| CONTENT DATA | |
|<------------------------| |(10)
Figure 10: Message Flow for Synchronous CDNI Metadata Acquisition
图10：同步CDNI元数据获取的消息流
The steps illustrated in the figure are as follows:
图中所示的步骤如下：
1. A Content Request arrives as normal.
1. 内容请求正常到达。
2. An RI request occurs as in the prior example.
2. RI请求如前一示例中所示发生。
3. On receipt of the CDNI Request Routing Request, Operator B's CDN initiates Synchronous acquisition of CDNI Metadata that are needed for routing of the end-user request. We assume the URI for the a metadata server is known ahead of time through some out-of-band means.
3. 在收到CDNI请求路由请求后，运营商B的CDN启动同步获取最终用户请求路由所需的CDNI元数据。我们假设元数据服务器的URI是通过一些带外方式提前知道的。
4. On receipt of a CDNI Metadata request, Operator A's CDN responds, making the corresponding CDNI Metadata information available to Operator B's CDN. This metadata is considered by Operator B's CDN before responding to the Request Routing request. (In a simple case, the metadata could simply be an allow or deny response for this particular request.)
4. 在收到CDNI元数据请求后，运营商a的CDN将作出响应，使相应的CDNI元数据信息可供运营商B的CDN使用。在响应请求路由请求之前，运营商B的CDN会考虑此元数据。（在一个简单的情况下，元数据可以是对该特定请求的允许或拒绝响应。）
5. Response to the RI request as normal.
5. 正常响应RI请求。
6. Redirection message is sent to the end user.
6. 将重定向消息发送给最终用户。
7. A delivery node of Operator B receives the end user request.
7. 操作员B的交付节点接收最终用户请求。
8. The delivery node Triggers dynamic acquisition of additional CDNI Metadata that are needed to process the end-user content request. Note that there may exist cases where this step need not happen, for example, because the metadata were already acquired previously.
8. 交付节点触发动态获取处理最终用户内容请求所需的其他CDNI元数据。请注意，可能存在不需要执行此步骤的情况，例如，因为元数据之前已经获取。
9. Operator A's CDN responds to the CDNI Metadata Request and makes the corresponding CDNI Metadata available to Operator B. This metadata influence how Operator B's CDN processes the end-user request.
9. 运营商A的CDN响应CDNI元数据请求，并向运营商B提供相应的CDNI元数据。此元数据影响运营商B的CDN处理最终用户请求的方式。
10. Content is served (possibly preceded by inter-CDN acquisition) as in Section 3.3.
10. 按照第3.3节提供内容（可能在CDN间获取之前）。
A single dCDN may receive end-user requests from multiple uCDNs. When a dCDN receives an end-user request, it must determine the identity of the uCDN from which it should acquire the requested content.
单个dCDN可以从多个UCDN接收最终用户请求。当dCDN收到最终用户请求时，它必须确定uCDN的标识，从该标识获取请求的内容。
Ideally, the acquisition path of an end-user request will follow the redirection path of the request. The dCDN should acquire the content from the same uCDN that redirected the request.
理想情况下，最终用户请求的获取路径将遵循请求的重定向路径。dCDN应从重定向请求的同一uCDN获取内容。
Determining the acquisition path requires the dCDN to reconstruct the redirection path based on information in the end-user request. The method for reconstructing the redirection path differs based on the redirection approach: HTTP or DNS.
确定采集路径需要dCDN根据最终用户请求中的信息重建重定向路径。重建重定向路径的方法因重定向方法而异：HTTP或DNS。
With HTTP-redirection, the rewritten URI should include sufficient information for the dCDN to directly or indirectly determine the uCDN when the end-user request is received. The HTTP-redirection approach can be further broken-down based on the how the URL is rewritten during redirection: HTTP redirection with or without Site Aggregation. HTTP redirection with Site Aggregation hides the identity of the original CSP. HTTP redirection without Site Aggregation does not attempt to hide the identity of the original CSP. With both approaches, the rewritten URI includes enough information to identify the immediate neighbor uCDN.
通过HTTP重定向，重写的URI应该包含足够的信息，以便dCDN在接收到最终用户请求时直接或间接确定uCDN。HTTP重定向方法可以根据重定向过程中URL的重写方式进一步细分：有无站点聚合的HTTP重定向。带有站点聚合的HTTP重定向隐藏了原始CSP的标识。没有站点聚合的HTTP重定向不会试图隐藏原始CSP的标识。对于这两种方法，重写的URI都包含足够的信息来标识直接相邻的uCDN。
With DNS-redirection, the dCDN receives the published URI (instead of a rewritten URI) and does not have sufficient information for the dCDN to identify the appropriate uCDN. The dCDN may narrow the set of viable uCDNs by examining the CDNI Metadata from each to determine which uCDNs are hosting metadata for the requested content. If there is a single uCDN hosting metadata for the requested content, the dCDN can assume that the request redirection is coming from this uCDN and can acquire content from that uCDN. If there are multiple uCDNs hosting metadata for the requested content, the dCDN may be ready to trust any of these uCDNs to acquire the content (provided the uCDN is in a position to serve it). If the dCDN is not ready to trust any of these uCDNs, it needs to ensure via out of band arrangements that, for a given content, only a single uCDN will ever redirect requests to the dCDN.
通过DNS重定向，dCDN接收已发布的URI（而不是重写的URI），并且没有足够的信息供dCDN识别适当的uCDN。dCDN可以通过检查每个UCDN的CDNI元数据来确定哪些UCDN承载请求内容的元数据，从而缩小可行UCDN集的范围。如果存在一个承载请求内容元数据的uCDN，则dCDN可以假定请求重定向来自该uCDN，并可以从该uCDN获取内容。如果存在多个承载请求内容元数据的uCDN，则dCDN可能准备好信任这些uCDN中的任何一个来获取内容（前提是uCDN能够为其提供服务）。如果dCDN不准备信任这些uCDN中的任何一个，则需要通过带外安排确保对于给定内容，只有单个uCDN将请求重定向到dCDN。
Content acquisition may be preceded by content metadata acquisition. If possible, the acquisition path for metadata should also follow the redirection path. Additionally, we assume metadata is indexed based on rewritten URIs in the case of HTTP redirection and is indexed based on published URIs in the case of DNS-redirection. Thus, the RI and the MI are tightly coupled in that the result of request routing (a rewritten URI pointing to the dCDN) serves as an input to metadata lookup. If the content metadata includes information for acquiring the content, then the MI is also tightly coupled with the acquisition interface in that the result of the metadata lookup (an acquisition URL likely hosted by the uCDN) should serve as input to the content acquisition.
内容获取可以在内容元数据获取之前进行。如果可能，元数据的获取路径也应遵循重定向路径。此外，我们假设元数据在HTTP重定向的情况下基于重写的URI进行索引，在DNS重定向的情况下基于已发布的URI进行索引。因此，RI和MI紧密耦合，请求路由的结果（指向dCDN的重写URI）作为元数据查找的输入。如果内容元数据包括用于获取内容的信息，则MI还与获取接口紧密耦合，因为元数据查找的结果（可能由uCDN托管的获取URL）应作为内容获取的输入。
Figure 1 illustrates the main interfaces that are in scope for the CDNI WG, along with several others. The detailed specifications of these interfaces are left to other documents, but see [RFC6707] and [RFC7337] for some discussion of the interfaces.
图1说明了CDNI工作组范围内的主要接口以及其他几个接口。这些接口的详细规范留给其他文件，但有关接口的一些讨论，请参见[RFC6707]和[RFC7337]。
One interface that is not shown in Figure 1 is the interface between the user and the CSP. While for the purposes of CDNI that interface is out of scope, it is worth noting that it does exist and can provide useful functions, such as end-to-end performance monitoring and some forms of authentication and authorization.
图1中未显示的一个界面是用户和CSP之间的界面。虽然就CDNI而言，该接口超出了范围，但值得注意的是，它确实存在，并且可以提供有用的功能，例如端到端性能监控以及某些形式的身份验证和授权。
There is also an important interface between the user and the Request Routing function of both uCDN and dCDN (shown as the "Request" interface in Figure 1). As we saw in some of the preceding examples, that interface can be used as a way of passing metadata, such as the minimum information that is required for dCDN to obtain the content from the uCDN.
用户和uCDN和dCDN的请求路由功能之间还有一个重要的接口（如图1中的“请求”接口所示）。正如我们在前面的一些示例中看到的，该接口可以用作传递元数据的方式，例如dCDN从uCDN获取内容所需的最小信息。
In this section we will provide an overview of the functions performed by each of the CDNI interfaces and discuss how they fit into the overall solution. We also examine some of the design trade-offs, and explore several cross-interface concerns. We begin with an examination of one such trade-off that affects all the interfaces -- the use of in-band or out-of-band communication.
在本节中，我们将概述每个CDNI接口所执行的功能，并讨论它们如何适合整体解决方案。我们还研究了一些设计权衡，并探讨了几个跨接口问题。我们首先研究一种影响所有接口的权衡——带内或带外通信的使用。
Before getting to the individual interfaces, we observe that there is a high-level design choice for each, involving the use of existing in-band communication channels versus defining new out-of-band interfaces.
在讨论各个接口之前，我们注意到每个接口都有一个高级别的设计选择，包括使用现有的带内通信信道，而不是定义新的带外接口。
It is possible that the information needed to carry out various interconnection functions can be communicated between peer CDNs using existing in-band protocols. The use of HTTP 302 redirect is an example of how certain aspects of request routing can be implemented in-band (embedded in URIs). Note that using existing in-band protocols does not imply that the CDNI interfaces are null; it is still necessary to establish the rules (conventions) by which such protocols are used to implement the various interface functions.
可以使用现有带内协议在对等cdn之间传送执行各种互连功能所需的信息。HTTP 302重定向的使用是如何在带内（嵌入URI中）实现请求路由的某些方面的一个示例。注意，使用现有带内协议并不意味着CDNI接口为空；仍然需要建立规则（约定），通过这些规则（约定）使用这些协议来实现各种接口功能。
There are other opportunities for in-band communication beyond HTTP redirects. For example, many of the HTTP directives used by proxy servers can also be used by peer CDNs to inform each other of caching activity. Of these, one that is particularly relevant is the If-Modified-Since directive, which is used with the GET method to make it conditional: if the requested object has not been modified since the time specified in this field, a copy of the object will not be returned, and instead, a 304 (not modified) response will be returned.
除了HTTP重定向之外，还有其他的带内通信机会。例如，对等CDN也可以使用代理服务器使用的许多HTTP指令来相互通知缓存活动。其中一个特别相关的是If-Modified-Since指令，它与GET方法一起使用以使其有条件：如果请求的对象自该字段中指定的时间以来未被修改，则不会返回该对象的副本，而是返回304（未修改）响应。
Although the CDNI interfaces are largely independent, there are a set of conventions practiced consistently across all interfaces. Most important among these is how resources are named, for example, how the CDNI Metadata and Control interfaces identify the set of resources to which a given directive applies or the CDNI Logging interface identifies the set of resources for which a summary record applies.
尽管CDNI接口在很大程度上是独立的，但在所有接口中都有一组一致的约定。其中最重要的是资源的命名方式，例如，CDNI元数据和控制接口如何标识应用给定指令的资源集，或者CDNI日志接口如何标识应用摘要记录的资源集。
While, theoretically, the CDNI interfaces could explicitly identify every individual resource, in practice, they name resource aggregates (sets of URIs) that are to be treated in a similar way. For example, URI aggregates can be identified by a CDN-Domain (i.e., the FQDN at the beginning of a URI) or by a URI-Filter (i.e., a regular expression that matches a subset of URIs contained in some CDN-Domain). In other words, CDN-Domains and URI-Filters provide a uniform means to aggregate sets (and subsets) of URIs for the purpose of defining the scope for some operation in one of the CDNI interfaces.
虽然从理论上讲，CDNI接口可以显式地标识每个单独的资源，但在实践中，它们命名了要以类似方式处理的资源聚合（URI集）。例如，URI聚合可以由CDN域（即URI开头的FQDN）或URI筛选器（即，匹配某个CDN域中包含的URI子集的正则表达式）来标识。换句话说，CDN域和URI过滤器提供了一种统一的方法来聚合URI集（和子集），以定义其中一个CDNI接口中某些操作的范围。
The Request Routing interface comprises two parts: the Asynchronous interface used by a dCDN to advertise footprint and capabilities (denoted FCI) to a uCDN, allowing the uCDN to decide whether to redirect particular user requests to that dCDN; and the Synchronous interface used by the uCDN to redirect a user request to the dCDN (denoted RI). (These are somewhat analogous to the operations of routing and forwarding in IP.)
请求路由接口包括两部分：dCDN用于向uCDN公布封装外形和功能（表示为FCI）的异步接口，允许uCDN决定是否将特定用户请求重定向到该dCDN；以及uCDN用于将用户请求重定向到dCDN的同步接口（表示为RI）。（这在某种程度上类似于IP中的路由和转发操作。）
As illustrated in Section 3, the RI part of request routing may be implemented in part by DNS and HTTP. Naming conventions may be established by which CDN peers communicate whether a request should be routed or content served.
如第3节所示，请求路由的RI部分可以部分地通过DNS和HTTP实现。可以建立命名约定，CDN对等方通过该约定来通信是否应该路由请求或提供内容服务。
We also note that RI plays a key role in enabling recursive redirection, as illustrated in Section 3.3. It enables the user to be redirected to the correct delivery node in dCDN with only a single redirection step (as seen by the user). This may be particularly valuable as the chain of interconnected CDNs increases beyond two CDNs. For further discussion on the RI, see [REDIRECTION].
我们还注意到，RI在实现递归重定向方面起着关键作用，如第3.3节所示。它只需一个重定向步骤（如用户所见），即可将用户重定向到dCDN中的正确传递节点。这可能特别有价值，因为互连的CDN链增加到超过两个CDN。有关RI的进一步讨论，请参阅[重定向]。
In support of these redirection requests, it is necessary for CDN peers to exchange additional information with each other, and this is the role of the FCI part of request routing. Depending on the method(s) supported, this might include:
为了支持这些重定向请求，CDN对等方必须彼此交换附加信息，这是请求路由的FCI部分的作用。根据支持的方法，这可能包括：
o The operator's unique id (operator-id) or distinguished CDN-Domain (operator-domain);
o 运营商的唯一id（运营商id）或可分辨CDN域（运营商域）；
o NS records for the operator's set of externally visible Request Routers;
o 操作员的一组外部可见请求路由器的NS记录；
o The set of requests the dCDN operator is prepared to serve (e.g., a set of client IP prefixes or geographic regions that may be served by the dCDN).
o dCDN运营商准备服务的一组请求（例如，一组客户端IP前缀或可能由dCDN服务的地理区域）。
o Additional capabilities of the dCDN, such as its ability to support different CDNI Metadata requests.
o dCDN的其他功能，例如支持不同CDNI元数据请求的能力。
Note that the set of requests that a dCDN is willing to serve could in some cases be relatively static (e.g., a set of IP prefixes), could be exchanged off-line, or might even be negotiated as part of a peering agreement. However, it may also be more dynamic, in which case the exchange supported by FCI would be helpful. A further discussion of the Footprint & Capability Advertisement interface can be found in [FOOTPRINT-CAPABILITY].
请注意，dCDN愿意服务的请求集在某些情况下可能是相对静态的（例如，一组IP前缀），可以离线交换，甚至可以作为对等协议的一部分进行协商。但是，它也可能更具动态性，在这种情况下，FCI支持的exchange将有所帮助。有关Footprint&Capability广告界面的进一步讨论，请参见[Footprint-Capability]。
It is necessary for the Upstream CDN to have visibility into the delivery of content that it redirected to a Downstream CDN. This allows the Upstream CDN to properly bill its customers for multiple deliveries of content cached by the Downstream CDN, as well as to report accurate traffic statistics to those content providers. This is one role of the LI.
上游CDN必须能够看到其重定向到下游CDN的内容的交付。这使得上游CDN能够为下游CDN缓存的内容的多次交付向其客户正确计费，并向这些内容提供商报告准确的流量统计数据。这是李的一个角色。
Other operational data that may be relevant to CDNI can also be exchanged by the LI. For example, a dCDN may report the amount of content it has acquired from uCDN, and how much cache storage has been consumed by content cached on behalf of uCDN.
与CDNI相关的其他运行数据也可由LI交换。例如，dCDN可以报告它从uCDN获取的内容量，以及代表uCDN缓存的内容消耗了多少缓存存储。
Traffic logs are easily exchanged off-line. For example, the following traffic log is a small deviation from the Apache log file format, where entries include the following fields:
流量日志很容易离线交换。例如，以下流量日志与Apache日志文件格式略有不同，其中条目包括以下字段：
o Domain - the full domain name of the origin server
o Domain—源服务器的完整域名
o IP address - the IP address of the client making the request
o IP地址—发出请求的客户端的IP地址
o End time - the ending time of the transfer
o 结束时间-传输的结束时间
o Time zone - any time zone modifier for the end time
o 时区-结束时间的任何时区修改器
o Method - the transfer command itself (e.g., GET, POST, HEAD)
o 方法-传输命令本身（例如GET、POST、HEAD）
o URL - the requested URL
o URL-请求的URL
o Version - the protocol version, such as HTTP/1.0
o 版本-协议版本，如HTTP/1.0
o Response - a numeric response code indicating transfer result
o 响应-表示传输结果的数字响应代码
o Bytes Sent - the number of bytes in the body sent to the client
o Bytes Sent—正文中发送到客户端的字节数
o Request ID - a unique identifier for this transfer
o 请求ID-此传输的唯一标识符
o User agent - the user agent, if supplied
o 用户代理-用户代理（如果提供）
o Duration - the duration of the transfer in milliseconds
o Duration—传输的持续时间（以毫秒为单位）
o Cached Bytes - the number of body bytes served from the cache
o Cached Bytes—缓存提供的正文字节数
o Referrer - the referrer string from the client, if supplied
o referer-客户端的referer字符串（如果提供）
Of these, only the Domain field is indirect in the Downstream CDN -- it is set to the CDN-Domain used by the Upstream CDN rather than the actual origin server. This field could then used to filter traffic log entries so only those entries matching the Upstream CDN are reported to the corresponding operator. Further discussion of the LI can be found in [LOGGING].
其中，只有域字段在下游CDN中是间接的——它被设置为上游CDN使用的CDN域，而不是实际的源服务器。然后，该字段可用于过滤流量日志条目，以便仅向相应的运营商报告与上游CDN匹配的条目。关于LI的进一步讨论可在[LOGGING]中找到。
One open question is who does the filtering. One option is that the Downstream CDN filters its own logs and passes the relevant records directly to each Upstream peer. This requires that the Downstream CDN know the set of CDN-Domains that belong to each Upstream peer. If this information is already exchanged between peers as part of another interface, then direct peer-to-peer reporting is straightforward. If it is not available, and operators do not wish to advertise the set of CDN-Domains they serve to their peers, then the second option is for each CDN to send both its non-local traffic records and the set of CDN-Domains it serves to an independent third party (i.e., a CDN Exchange), which subsequently filters, merges, and distributes traffic records on behalf of each participating CDN operator.
一个悬而未决的问题是谁进行过滤。一种选择是，下游CDN过滤自己的日志，并将相关记录直接传递给每个上游对等方。这要求下游CDN知道属于每个上游对等方的CDN域集。如果这些信息已经作为另一个接口的一部分在对等方之间交换，那么直接的对等报告就很简单了。如果不可用，且运营商不希望向其对等方公布其服务的CDN域集，则第二个选项是每个CDN将其非本地流量记录和其服务的CDN域集发送给独立的第三方（即CDN交换），后者随后进行过滤、合并，并代表每个参与CDN运营商分发流量记录。
A second open question is how timely traffic information should be. For example, in addition to offline traffic logs, accurate real-time traffic monitoring might also be useful, but such information requires that the Downstream CDN inform the Upstream CDN each time it serves Upstream content from its cache. The Downstream CDN can do this, for example, by sending a conditional HTTP GET request (If-Modified-Since) to the Upstream CDN each time it receives an HTTP GET request from one of its end users. This allows the Upstream CDN
第二个悬而未决的问题是交通信息应该如何及时。例如，除了离线流量日志外，准确的实时流量监控也可能有用，但此类信息要求下游CDN在每次从其缓存服务上游内容时通知上游CDN。下游CDN可以做到这一点，例如，每次从其一个最终用户接收HTTP GET请求时，都向上游CDN发送一个有条件的HTTP GET请求（如果自那时起进行了修改）。这允许上游CDN
to record that a request has been issued for the purpose of real-time traffic monitoring. The Upstream CDN can also use this information to validate the traffic logs received later from the Downstream CDN.
记录已发出用于实时流量监控的请求。上游CDN还可以使用该信息来验证稍后从下游CDN接收的流量日志。
There is obviously a trade-off between accuracy of such monitoring and the overhead of the Downstream CDN having to go back to the Upstream CDN for every request.
显然，在这种监视的准确性和下游CDN必须为每个请求返回到上游CDN的开销之间存在权衡。
Another design trade-off in the LI is the degree of aggregation or summarization of data. One situation that lends itself to summarization is the delivery of HTTP Adaptive Streaming (HAS), since the large number of individual chunk requests potentially results in large volumes of logging information. This case is discussed below, but other forms of aggregation may also be useful. For example, there may be situations where bulk metrics such as bytes delivered per hour may suffice rather than the detailed per-request logs outlined above. It seems likely that a range of granularities of logging will be needed along with ways to specify the type and degree of aggregation required.
LI中的另一个设计权衡是数据的聚合或汇总程度。一种适合于摘要的情况是HTTP自适应流（HAS）的交付，因为大量的单个块请求可能会导致大量日志信息。下面将讨论这种情况，但其他形式的聚合也可能有用。例如，在某些情况下，批量度量（例如每小时交付的字节数）可能就足够了，而不是上面列出的详细的每请求日志。似乎需要一系列日志粒度，以及指定所需聚合类型和程度的方法。
The CDNI Control interface is initially used to bootstrap the other interfaces. As a simple example, it could be used to provide the address of the logging server in the dCDN to the uCDN in order to bootstrap the CDNI Logging interface. It may also be used, for example, to establish security associations for the other interfaces.
CDNI控制接口最初用于引导其他接口。作为一个简单的示例，它可以用于向uCDN提供dCDN中日志服务器的地址，以便引导CDNI日志接口。例如，它还可用于为其他接口建立安全关联。
The other role the CI plays is to allow the uCDN to pre-position, revalidate, or purge metadata and content on a dCDN. These operations, sometimes collectively called the "Trigger interface", are discussed further in [CONTROL-TRIGGERS].
CI扮演的另一个角色是允许uCDN在dCDN上预定位、重新验证或清除元数据和内容。这些操作有时统称为“触发器接口”，将在[控制触发器]中进一步讨论。
The role of the CDNI Metadata interface is to enable CDNI distribution metadata to be conveyed to the Downstream CDN by the Upstream CDN. Such metadata includes geo-blocking restrictions, availability windows, access-control policies, and so on. It may also include information to facilitate acquisition of content by a dCDN (e.g., alternate sources for the content, authorization information needed to acquire the content from the source). For a full discussion of the CDNI Metadata interface, see [METADATA]
CDNI元数据接口的作用是使上游CDN能够将CDNI分发元数据传送到下游CDN。此类元数据包括地理阻止限制、可用性窗口、访问控制策略等。它还可以包括有助于dCDN获取内容的信息（例如，内容的替代源、从源获取内容所需的授权信息）。有关CDNI元数据接口的完整讨论，请参阅[元数据]
Some distribution metadata may be partially emulated using in-band mechanisms. For example, in case of any geo-blocking restrictions or availability windows, the Upstream CDN can elect to redirect a request to the Downstream CDN only if that CDN's advertised delivery
可以使用带内机制部分模拟某些分发元数据。例如，在任何地理阻塞限制或可用性窗口的情况下，上游CDN可以选择将请求重定向到下游CDN，前提是该CDN的广告交付
footprint is acceptable for the requested URL. Similarly, the request could be forwarded only if the current time is within the availability window. However, such approaches typically come with shortcomings such as inability to prevent from replay outside the time window or inability to make use of a Downstream CDN that covers a broader footprint than the geo-blocking restrictions.
请求的URL可接受封装外形。同样，只有在当前时间在可用性窗口内时，才能转发请求。然而，此类方法通常具有缺点，例如无法防止在时间窗口外重播，或者无法利用覆盖范围比地理阻塞限制更广的下游CDN。
Similarly, some forms of access control may also be performed on a per-request basis using HTTP directives. For example, being able to respond to a conditional GET request gives the Upstream CDN an opportunity to influence how the Downstream CDN delivers its content. Minimally, the Upstream CDN can invalidate (purge) content previously cached by the Downstream CDN.
类似地，也可以使用HTTP指令在每个请求的基础上执行某些形式的访问控制。例如，能够响应有条件的GET请求使上游CDN有机会影响下游CDN如何交付其内容。至少，上游CDN可以使先前由下游CDN缓存的内容无效（清除）。
All of these in-band techniques serve to illustrate that uCDNs have the option of enforcing some of their access control policies themselves (at the expense of increased inter-CDN signaling load), rather than delegating enforcement to dCDNs using the MI. As a consequence, the MI could provide a means for the uCDN to express its desire to retain enforcement for itself. For example, this might be done by including a "check with me" flag in the metadata associated with certain content. The realization of such in-band techniques over the various inter-CDN acquisition protocols (e.g., HTTP) requires further investigation and may require small extensions or semantic changes to the acquisition protocol.
所有这些带内技术都用于说明UCDN可以选择自己强制实施一些访问控制策略（以增加CDN间信令负载为代价），而不是使用MI将强制授权给DCDN。因此，MI可以为uCDN提供一种手段，以表达其保留强制执行的愿望。例如，这可以通过在与特定内容关联的元数据中包含“与我一起检查”标志来实现。在各种CDN间捕获协议（例如HTTP）上实现这种带内技术需要进一步研究，并且可能需要对捕获协议进行小的扩展或语义更改。
We consider HTTP Adaptive Streaming (HAS) and the impact it has on the CDNI interfaces because large objects (e.g., videos) are broken into a sequence of small, independent chunks. For each of the following, a more thorough discussion, including an overview of the trade-offs involved in alternative designs, can be found in RFC 6983.
我们考虑HTTP自适应流（FAS）及其对CDNI接口的影响，因为大对象（例如，视频）被分解成小的、独立的块序列。对于以下各项，RFC 6983中可以找到更全面的讨论，包括替代设计中涉及的权衡概述。
First, with respect to Content Acquisition and File Management, which are out of scope for the CDNI interfaces but, nonetheless, relevant to the overall operation, we assume no additional measures are required to deal with large numbers of chunks. This means that the dCDN is not explicitly made aware of any relationship between different chunks, and the dCDN handles each chunk as if it were an individual and independent content item. The result is that content acquisition between uCDN and dCDN also happens on a per-chunk basis. This approach is in line with the recommendations made in RFC 6983, which also identifies potential improvements in this area that might be considered in the future.
首先，关于内容获取和文件管理，这超出了CDNI接口的范围，但与整体操作相关，我们假设不需要额外的措施来处理大量块。这意味着dCDN没有明确地意识到不同块之间的任何关系，dCDN处理每个块就像它是一个独立的内容项一样。结果是uCDN和dCDN之间的内容获取也是基于每个块进行的。该方法符合RFC 6983中提出的建议，该建议还确定了未来可能考虑的该领域的潜在改进。
Second, with respect to request routing, we note that HAS manifest files have the potential to interfere with request routing since manifest files contain URLs pointing to the location of content chunks. To make sure that a manifest file does not hinder CDNI request routing and does not place excessive load on CDNI resources, either the use of manifest files could be limited to those containing relative URLs or the uCDN could modify the URLs in the manifest. Our approach for dealing with these issues is twofold. As a mandatory requirement, CDNs should be able to handle unmodified manifest files containing either relative or absolute URLs. To limit the number of redirects, and thus the load placed on the CDNI interfaces, as an optional feature uCDNs can use the information obtained through the CDNI Request Routing Redirection interface to modify the URLs in the manifest file. Since the modification of the manifest file is an optional uCDN-internal process, this does not require any standardization effort beyond being able to communicate chunk locations in the CDNI Request Routing Redirection interface.
其次，关于请求路由，我们注意到HAS清单文件可能会干扰请求路由，因为清单文件包含指向内容块位置的URL。为了确保清单文件不会妨碍CDNI请求路由，也不会对CDNI资源造成过多负载，清单文件的使用可以限制为包含相对URL的文件，或者uCDN可以修改清单中的URL。我们处理这些问题的方法是双重的。作为一项强制性要求，CDN应该能够处理包含相对或绝对URL的未修改清单文件。为了限制重定向的数量，从而限制CDNI接口上的负载，作为可选功能，uCDNs可以使用通过CDNI请求路由重定向接口获得的信息来修改清单文件中的URL。由于清单文件的修改是可选的uCDN内部过程，因此除了能够在CDNI请求路由重定向接口中通信区块位置之外，不需要任何标准化工作。
Third, with respect to the CDNI Logging interface, there are several potential issues, including the large number of individual chunk requests potentially resulting in large volumes of logging information, and the desire to correlate logging information for chunk requests that correspond to the same HAS session. For the initial CDNI specification, our approach is to expect participating CDNs to support per-chunk logging (e.g., logging each chunk request as if it were an independent content request) over the CDNI Logging interface. Optionally, the LI may include a Content Collection IDentifier (CCID) and/or a Session IDentifier (SID) as part of the logging fields, thereby facilitating correlation of per-chunk logs into per-session logs for applications benefiting from such session level information (e.g., session-based analytics). This approach is in line with the recommendations made in RFC 6983, which also identifies potential improvements in this area that might be considered in the future.
第三，关于CDNI日志接口，存在几个潜在的问题，包括大量的单个区块请求可能导致大量日志信息，以及希望将对应于同一HAS会话的区块请求的日志信息关联起来。对于最初的CDNI规范，我们的方法是期望参与的CDN通过CDNI日志接口支持每个区块日志记录（例如，记录每个区块请求，就像它是一个独立的内容请求一样）。可选地，LI可以包括内容收集标识符（CCID）和/或会话标识符（SID）作为日志字段的一部分，从而促进每区块日志与每会话日志的关联，以用于受益于此类会话级信息的应用（例如，基于会话的分析）。该方法符合RFC 6983中提出的建议，该建议还确定了未来可能考虑的该领域的潜在改进。
Fourth, with respect to the CDNI Control interface, and in particular purging HAS chunks from a given CDN, our approach is to expect each CDN supports per-chunk content purge (e.g., purging of chunks as if they were individual content items). Optionally, a CDN may support content purge on the basis of a "Purge IDentifier (Purge-ID)" allowing the removal of all chunks related to a given Content Collection with a single reference. It is possible that this Purge-ID could be merged with the CCID discussed above for HAS Logging, or alternatively, they may remain distinct.
第四，关于CDNI控制接口，特别是清除具有来自给定CDN的块，我们的方法是期望每个CDN支持每个块内容清除（例如，清除块，就好像它们是单个内容项一样）。可选地，CDN可以支持基于“清除标识符（清除ID）”的内容清除，允许使用单个引用删除与给定内容集合相关的所有区块。这个清除ID可能与上面讨论的用于HAS日志记录的CCID合并，或者，它们可能保持不同。
When using HTTP redirection, content URIs may be rewritten when redirection takes place within a uCDN, from a uCDN to a dCDN, and within the dCDN. In the case of cascaded CDNs, content URIs may be rewritten at every CDN hop (e.g., between the uCDN and the dCDN acting as the transit CDN, and between the transit CDN and the dCDN serving the request). The content URI used between any uCDN/dCDN pair becomes a common handle that can be referred to without ambiguity by both CDNs in all their inter-CDN communications. This handle allows the uCDN and dCDN to correlate information exchanged using other CDNI interfaces in both the Downstream direction (e.g., when using the MI) and the Upstream direction (e.g., when using the LI).
使用HTTP重定向时，在uCDN内、从uCDN到dCDN以及dCDN内发生重定向时，可能会重写内容URI。在级联CDN的情况下，可以在每个CDN跃点处重写内容uri（例如，在uCDN和充当传输CDN的dCDN之间，以及在传输CDN和服务于请求的dCDN之间）。任何uCDN/dCDN对之间使用的内容URI成为一个公共句柄，两个CDN在其所有CDN间通信中都可以无歧义地引用该句柄。此句柄允许uCDN和dCDN在下游方向（例如，当使用MI时）和上游方向（例如，当使用LI时）关联使用其他CDNI接口交换的信息。
Consider the simple case of a single uCDN/dCDN pair using HTTP redirection. We introduce the following terminology for content URIs to simplify the discussion:
考虑使用HTTP重定向的单个UCDN/DCDN对的简单情况。我们为内容URI引入以下术语以简化讨论：
"u-URI" represents a content URI in a request presented to the uCDN;
“u-URI”表示呈现给uCDN的请求中的内容URI；
"ud-URI" is a content URI acting as the common handle across uCDN and dCDN for requests redirected by the uCDN to a specific dCDN;
“ud URI”是一个内容URI，作为uCDN和dCDN之间的公共句柄，用于uCDN重定向到特定dCDN的请求；
"d-URI" represents a content URI in a request made within the delegate dCDN.
“d-URI”表示在委托dCDN内发出的请求中的内容URI。
In our simple pair-wise example, the "ud-URI" effectively becomes the handle that the uCDN/dCDN pair use to correlate all CDNI information. In particular, for a given pair of CDNs executing the HTTP redirection, the uCDN needs to map the u-URI to the ud-URI handle for all MI message exchanges, while the dCDN needs to map the d-URI to the ud-URI handle for all LI message exchanges.
在我们简单的成对示例中，“uduri”实际上成为uCDN/dCDN对用来关联所有CDNI信息的句柄。特别是，对于执行HTTP重定向的给定CDN对，uCDN需要将所有MI消息交换的u-URI映射到ud URI句柄，而dCDN需要将所有LI消息交换的d-URI映射到ud URI句柄。
In the case of cascaded CDNs, the transit CDN will rewrite the content URI when redirecting to the dCDN, thereby establishing a new handle between the transit CDN and the dCDN, that is different from the handle between the uCDN and transit CDN. It is the responsibility of the transit CDN to manage its mapping across handles so the right handle for all pairs of CDNs is always used in its CDNI communication.
在级联CDN的情况下，传输CDN将在重定向到dCDN时重写内容URI，从而在传输CDN和dCDN之间建立新的句柄，这与uCDN和传输CDN之间的句柄不同。transit CDN负责管理其跨句柄的映射，因此在其CDNI通信中始终使用所有CDN对的正确句柄。
In summary, all CDNI interfaces between a given pair of CDNs need to always use the "ud-URI" handle for that specific CDN pair as their content URI reference.
总之，给定CDN对之间的所有CDNI接口都需要始终使用该特定CDN对的“ud URI”句柄作为其内容URI引用。
In this section, we describe a number of possible deployment models that may be achieved using the CDNI interfaces described above. We note that these models are by no means exhaustive and that many other models may be possible.
在本节中，我们将介绍使用上述CDNI接口可以实现的一些可能的部署模型。我们注意到，这些模型并非详尽无遗，许多其他模型可能是可能的。
Although the reference model of Figure 1 shows all CDN functions on each side of the CDNI interface, deployments can rely on entities that are involved in any subset of these functions, and therefore only support the relevant subset of CDNI interfaces. As already noted in Section 3, effective CDNI deployments can be built without necessarily implementing all the interfaces. Some examples of such deployments are shown below.
尽管图1的参考模型显示了CDNI接口每侧的所有CDN功能，但部署可以依赖于这些功能的任何子集所涉及的实体，因此只支持CDNI接口的相关子集。如第3节所述，可以构建有效的CDNI部署，而不必实现所有接口。下面显示了此类部署的一些示例。
Note that, while we refer to Upstream and Downstream CDNs, this distinction applies to specific content items and transactions. That is, a given CDN may be Upstream for some transactions and Downstream for others, depending on many factors such as location of the requesting client and the particular piece of content requested.
请注意，虽然我们指的是上游和下游CDN，但这种区别适用于特定的内容项和事务。也就是说，给定CDN可能是某些事务的上游，而其他事务的下游，这取决于许多因素，例如请求客户端的位置和请求的特定内容。
Although the reference model illustrated in Figure 1 shows a unidirectional CDN interconnection with a single uCDN and a single dCDN, any arbitrary CDNI meshing can be built from this, such as the example meshing illustrated in Figure 11. (Support for arbitrary meshing may or may not be in the initial scope for the working group, but the model allows for it.)
尽管图1所示的参考模型显示了具有单个uCDN和单个dCDN的单向CDN互连，但可以由此构建任意CDNI网格，如图11所示的示例网格。（对任意网格的支持可能在工作组的初始范围内，也可能不在工作组的初始范围内，但模型允许这种支持。）
------------- -----------
/ CDN A \<==CDNI===>/ CDN B \
\ / \ /
------------- -----------
/\ \\ /\
|| \\ ||
CDNI \==CDNI===\\ CDNI
|| \\ ||
\/ \/ \/
------------- -----------
/ CDN C \===CDNI===>/ CDN D \
\ / \ /
------------- -----------
/\
||
CDNI
||
\/
-------------
/ CDN E \
\ /
-------------
------------- -----------
/ CDN A \<==CDNI===>/ CDN B \
\ / \ /
------------- -----------
/\ \\ /\
|| \\ ||
CDNI \==CDNI===\\ CDNI
|| \\ ||
\/ \/ \/
------------- -----------
/ CDN C \===CDNI===>/ CDN D \
\ / \ /
------------- -----------
/\
||
CDNI
||
\/
-------------
/ CDN E \
\ /
-------------
===> CDNI interfaces, with right-hand side CDN acting as dCDN
to left-hand side CDN
<==> CDNI interfaces, with right-hand side CDN acting as dCDN
to left-hand side CDN and with left-hand side CDN acting
as dCDN to right-hand side CDN
===> CDNI interfaces, with right-hand side CDN acting as dCDN
to left-hand side CDN
<==> CDNI interfaces, with right-hand side CDN acting as dCDN
to left-hand side CDN and with left-hand side CDN acting
as dCDN to right-hand side CDN
Figure 11: CDNI Deployment Model: CDN Meshing Example
图11:CDNI部署模型：CDN网格化示例
Note that our terminology refers to functional roles and not economic or business roles. That is, a given organization may be operating as both a CSP and a fully fledged uCDN when we consider the functions performed, as illustrated in Figure 12.
请注意，我们的术语指的是职能角色，而不是经济或业务角色。也就是说，当我们考虑执行的功能时，给定的组织可以作为CSP和完全成熟的UCDN来操作，如图12所示。
##################################### ##################
# # # #
# Organization A # # Organization B #
# # # #
# -------- ------------- # # ----------- #
# / CSP \ / uCDN \ # # / dCDN \ #
# | | | +----+ | # # | +----+ | #
# | | | | C | | # # | | C | | #
# | | | +----+ | # # | +----+ | #
# | | | +----+ | # # | +----+ | #
# | | | | L | | # # | | L | | #
# | |*****| +----+ |===CDNI===>| +----+ | #
# | | | +----+ | # # | +----+ | #
# | | | | RR | | # # | | RR | | #
# | | | +----+ | # # | +----+ | #
# | | | +----+ | # # | +----+ | #
# | | | | D | | # # | | D | | #
# | | | +----+ | # # | +----+ | #
# \ / \ / # # \ / #
# -------- ------------- # # ----------- #
# # # #
##################################### ##################
##################################### ##################
# # # #
# Organization A # # Organization B #
# # # #
# -------- ------------- # # ----------- #
# / CSP \ / uCDN \ # # / dCDN \ #
# | | | +----+ | # # | +----+ | #
# | | | | C | | # # | | C | | #
# | | | +----+ | # # | +----+ | #
# | | | +----+ | # # | +----+ | #
# | | | | L | | # # | | L | | #
# | |*****| +----+ |===CDNI===>| +----+ | #
# | | | +----+ | # # | +----+ | #
# | | | | RR | | # # | | RR | | #
# | | | +----+ | # # | +----+ | #
# | | | +----+ | # # | +----+ | #
# | | | | D | | # # | | D | | #
# | | | +----+ | # # | +----+ | #
# \ / \ / # # \ / #
# -------- ------------- # # ----------- #
# # # #
##################################### ##################
===> CDNI interfaces, with right-hand side CDN acting as dCDN
to left-hand side CDN
**** interfaces outside the scope of CDNI
C Control component of the CDN
L Logging component of the CDN
RR Request Routing component of the CDN
D Distribution component of the CDN
===> CDNI interfaces, with right-hand side CDN acting as dCDN
to left-hand side CDN
**** interfaces outside the scope of CDNI
C Control component of the CDN
L Logging component of the CDN
RR Request Routing component of the CDN
D Distribution component of the CDN
Figure 12: CDNI Deployment Model: Organization Combining CSP & uCDN
图12:CDNI部署模型：结合CSP和uCDN的组织
As another example, a content provider organization may choose to run its own Request Routing function as a way to select among multiple candidate CDN providers; in this case, the content provider may be modeled as the combination of a CSP and of a special, restricted case of a CDN. In that case, as illustrated in Figure 13, the CDNI Request Routing interfaces can be used between the restricted CDN operated by the content provider Organization and the CDN operated by the full CDN organization acting as a dCDN in the request routing control plane. Interfaces outside the scope of the CDNI work can be used between the CSP functional entities of the content provider organization and the CDN operated by the full CDN organization acting as a uCDN) in the CDNI control planes other than the request routing plane (i.e., Control, Distribution, Logging).
作为另一示例，内容提供商组织可以选择运行其自己的请求路由功能，作为在多个候选CDN提供商中进行选择的方式；在这种情况下，可以将内容提供商建模为CSP和CDN的特殊、受限情况的组合。在这种情况下，如图13所示，CDNI请求路由接口可以在由内容提供商组织操作的受限CDN和由作为请求路由控制平面中的dCDN的完整CDN组织操作的CDN之间使用。CDNI工作范围之外的接口可用于内容提供商组织的CSP功能实体与CDNI控制平面（而非请求路由平面（即控制、分发、日志记录）中由完整CDN组织（作为uCDN）操作的CDN之间。
##################################### ##################
# # # #
# Organization A # # Organization B #
# # # #
# -------- ------------- # # ----------- #
# / CSP \ / uCDN(RR) \ # # / dCDN(RR) \ #
# | | | +----+ | # # | +----+ | #
# | |*****| | RR |==========CDNI=====>| RR | | #
# | | | +----+ | # RR # | +----+ | #
# | | \ / # # | | #
# | | ------------- # # |uCDN(C,L,D)| #
# | | # # | +----+ | #
# | | # # | | C | | #
# | |*******************************| +----+ | #
# | | # # | +----+ | #
# | | # # | | L | | #
# | | # # | +----+ | #
# | | # # | +----+ | #
# | | # # | | D | | #
# | | # # | +----+ | #
# \ / # # \ / #
# -------- # # ----------- #
# # # #
##################################### ##################
##################################### ##################
# # # #
# Organization A # # Organization B #
# # # #
# -------- ------------- # # ----------- #
# / CSP \ / uCDN(RR) \ # # / dCDN(RR) \ #
# | | | +----+ | # # | +----+ | #
# | |*****| | RR |==========CDNI=====>| RR | | #
# | | | +----+ | # RR # | +----+ | #
# | | \ / # # | | #
# | | ------------- # # |uCDN(C,L,D)| #
# | | # # | +----+ | #
# | | # # | | C | | #
# | |*******************************| +----+ | #
# | | # # | +----+ | #
# | | # # | | L | | #
# | | # # | +----+ | #
# | | # # | +----+ | #
# | | # # | | D | | #
# | | # # | +----+ | #
# \ / # # \ / #
# -------- # # ----------- #
# # # #
##################################### ##################
===> CDNI Request Routing Interface
**** interfaces outside the scope of CDNI
===> CDNI Request Routing Interface
**** interfaces outside the scope of CDNI
Figure 13: CDNI Deployment Model: Organization Combining CSP and Partial CDN
图13:CDNI部署模型：结合CSP和部分CDN的组织
There are two additional concepts related to, but distinct from, CDNI. The first is CDN Federation. Our view is that CDNI is the more general concept, involving two or more CDNs serving content to each other's users, while federation implies a multi-lateral interconnection arrangement, but other CDNI agreements are also possible (e.g., symmetric bilateral, asymmetric bilateral). An important conclusion is that CDNI technology should not presume (or bake in) a particular interconnection agreement, but should instead be general enough to permit alternative interconnection arrangements to evolve.
另外还有两个与CDNI相关但不同的概念。第一个是CDN联盟。我们的观点是，CDNI是一个更一般的概念，涉及两个或多个CDN向彼此的用户提供内容，而联合意味着多边互连安排，但其他CDNI协议也是可能的（例如，对称双边、不对称双边）。一个重要的结论是，CDNI技术不应假定（或加入）特定的互连协议，而应具有足够的通用性，以允许发展替代互连安排。
The second concept often used in the context of CDN Federation is CDN Exchange -- a third-party broker or exchange that is used to facilitate a CDN federation. Our view is that a CDN exchange offers valuable machinery to scale the number of CDN operators involved in a
CDN联合上下文中经常使用的第二个概念是CDN Exchange——用于促进CDN联合的第三方代理或交换。我们的观点是，CDN交换提供了有价值的机制，以扩大参与交易的CDN运营商的数量
multi-lateral (federated) agreement, but that this machinery is built on top of the core CDNI mechanisms. For example, as illustrated in Figure 14, the exchange might aggregate and redistribute information about each CDN footprint and capacity, as well as collect, filter, and redistribute traffic logs that each participant needs for interconnection settlement, but inter-CDN Request Routing, inter-CDN content distribution (including inter-CDN acquisition), and inter-CDN control, which fundamentally involve a direct interaction between an Upstream CDN and a Downstream CDN -- operate exactly as in a pair-wise peering arrangement. Turning to Figure 14, we observe that in this example:
多边（联邦）协议，但该机制建立在核心CDNI机制之上。例如，如图14所示，exchange可能会聚合和重新分发关于每个CDN足迹和容量的信息，以及收集、过滤和重新分发每个参与者需要的流量日志，以进行互连结算，但CDN间请求路由、CDN间内容分发（包括CDN间采集）和CDN间控制，它们基本上涉及上游CDN和下游CDN之间的直接交互，其操作与成对对等安排完全相同。转到图14，我们观察到在本例中：
o each CDN supports a direct CDNI Control interface to every other CDN
o 每个CDN都支持与其他CDN的直接CDNI控制接口
o each CDN supports a direct CDNI Metadata interface to every other CDN
o 每个CDN都支持与其他CDN的直接CDNI元数据接口
o each CDN supports a CDNI Logging interface with the CDN Exchange
o 每个CDN都支持与CDN Exchange的CDNI日志记录接口
o each CDN supports both a CDNI Request Routing interface with the CDN Exchange (for aggregation and redistribution of dynamic CDN footprint discovery information) and a direct RI to every other CDN (for actual request redirection).
o 每个CDN都支持CDN交换的CDNI请求路由接口（用于聚合和重新分发动态CDN封装外形发现信息）和到每个其他CDN的直接RI（用于实际请求重定向）。
---------- ---------
/ CDN A \ / CDN B \
| +----+ | | +----+ |
//========>| C |<==============CDNI============>| C |<==========\\
|| | +----+ | C | +----+ | ||
|| | +----+ | | +----+ | ||
|| //=====>| D |<==============CDNI============>| D |<=======\\ ||
|| || | +----+ | M | +----+ | || ||
|| || | | /------------\ | | || ||
|| || | +----+ | | +--+ CDN Ex| | +----+ | || ||
|| || //==>| RR |<===CDNI==>|RR|<=======CDNI====>| RR |<====\\ || ||
|| || || | +----+ | RR | +--+ | RR | +----+ | || || ||
|| || || | | | /\ | | | || || ||
|| || || | +----+ | | || +---+ | | +----+ | || || ||
|| || || | | L |<===CDNI=======>| L |<=CDNI====>| L | | || || ||
|| || || | +----+ | L | || +---+ | L | +----+ | || || ||
|| || || \ / \ || /\ / \ / || || ||
|| || || ----------- --||----||-- ----------- || || ||
|| || || || || || || ||
|| || || CDNI RR || || || ||
|| || || || CDNI L || || ||
|| || || || || || || ||
|| || || ---||----||---- || || ||
|| || || / \/ || \ || || ||
|| || || | +----+ || | || || ||
|| || \\=====CDNI==========>| RR |<=============CDNI========// || ||
|| || RR | +----+ \/ | RR || ||
|| || | +----+ | || ||
|| || | | L | | || ||
|| || | +----+ | || ||
|| || | +----+ | || ||
|| \\=======CDNI===========>| D |<=============CDNI===========// ||
|| M | +----+ | M ||
|| | +----+ | ||
\\==========CDNI===========>| C |<=============CDNI==============//
C | +----+ | C
\ CDN C /
--------------
---------- ---------
/ CDN A \ / CDN B \
| +----+ | | +----+ |
//========>| C |<==============CDNI============>| C |<==========\\
|| | +----+ | C | +----+ | ||
|| | +----+ | | +----+ | ||
|| //=====>| D |<==============CDNI============>| D |<=======\\ ||
|| || | +----+ | M | +----+ | || ||
|| || | | /------------\ | | || ||
|| || | +----+ | | +--+ CDN Ex| | +----+ | || ||
|| || //==>| RR |<===CDNI==>|RR|<=======CDNI====>| RR |<====\\ || ||
|| || || | +----+ | RR | +--+ | RR | +----+ | || || ||
|| || || | | | /\ | | | || || ||
|| || || | +----+ | | || +---+ | | +----+ | || || ||
|| || || | | L |<===CDNI=======>| L |<=CDNI====>| L | | || || ||
|| || || | +----+ | L | || +---+ | L | +----+ | || || ||
|| || || \ / \ || /\ / \ / || || ||
|| || || ----------- --||----||-- ----------- || || ||
|| || || || || || || ||
|| || || CDNI RR || || || ||
|| || || || CDNI L || || ||
|| || || || || || || ||
|| || || ---||----||---- || || ||
|| || || / \/ || \ || || ||
|| || || | +----+ || | || || ||
|| || \\=====CDNI==========>| RR |<=============CDNI========// || ||
|| || RR | +----+ \/ | RR || ||
|| || | +----+ | || ||
|| || | | L | | || ||
|| || | +----+ | || ||
|| || | +----+ | || ||
|| \\=======CDNI===========>| D |<=============CDNI===========// ||
|| M | +----+ | M ||
|| | +----+ | ||
\\==========CDNI===========>| C |<=============CDNI==============//
C | +----+ | C
\ CDN C /
--------------
<=CDNI RR=> CDNI Request Routing Interface
<=CDNI M==> CDNI Metadata Interface
<=CDNI C==> CDNI Control Interface
<=CDNI L==> CDNI Logging Interface
<=CDNI RR=> CDNI Request Routing Interface
<=CDNI M==> CDNI Metadata Interface
<=CDNI C==> CDNI Control Interface
<=CDNI L==> CDNI Logging Interface
Figure 14: CDNI Deployment Model: CDN Exchange
图14:CDNI部署模型：CDN Exchange
Note that a CDN exchange may alternatively support a different set of functionality (e.g., Logging only, or Logging and full request routing, or all the functionality of a CDN including content distribution). All these options are expected to be allowed by the IETF CDNI specifications.
请注意，CDN交换也可以支持一组不同的功能（例如，仅日志记录，或日志记录和完整请求路由，或包括内容分发的CDN的所有功能）。IETF CDNI规范预计允许所有这些选项。
There are a number of trust issues that need to be addressed by a CDNI solution. Many of them are in fact similar or identical to those in a simple CDN without interconnection. In a standard CDN environment (without CDNI), the CSP places a degree of trust in a single CDN operator to perform many functions. The CDN is trusted to deliver content with appropriate quality of experience for the end user. The CSP trusts the CDN operator not to corrupt or modify the content. The CSP often relies on the CDN operator to provide reliable accounting information regarding the volume of delivered content. The CSP may also trust the CDN operator to perform actions such as timely invalidation of content and restriction of access to content based on certain criteria such as location of the user and time of day, and to enforce per-request authorization performed by the CSP using techniques such as URI signing.
CDNI解决方案需要解决许多信任问题。它们中的许多实际上与没有互连的简单CDN中的那些类似或相同。在标准CDN环境（无CDNI）中，CSP对单个CDN运营商具有一定程度的信任，以执行许多功能。CDN可以为最终用户提供具有适当体验质量的内容。CSP相信CDN运营商不会损坏或修改内容。CSP通常依赖CDN运营商提供有关交付内容量的可靠会计信息。CSP还可以信任CDN运营商根据诸如用户位置和时间之类的特定标准执行诸如及时使内容无效和限制对内容的访问的操作，并使用诸如URI签名之类的技术强制执行CSP执行的每请求授权。
A CSP also places trust in the CDN not to distribute any information that is confidential to the CSP (e.g., how popular a given piece of content is) or confidential to the end user (e.g., which content has been watched by which user).
CSP还信任CDN，不向CSP分发任何机密信息（例如，给定内容的流行程度）或向最终用户分发机密信息（例如，哪个用户观看了哪些内容）。
A CSP does not necessarily have to place complete trust in a CDN. A CSP will in some cases take steps to protect its content from improper distribution by a CDN, e.g., by encrypting it and distributing keys in some out of band way. A CSP also depends on monitoring (possibly by third parties) and reporting to verify that the CDN has performed adequately. A CSP may use techniques such as client-based metering to verify that accounting information provided by the CDN is reliable. HTTP conditional requests may be used to provide the CSP with some checks on CDN operation. In other words, while a CSP may trust a CDN to perform some functions in the short term, the CSP is able, in most cases, to verify whether these actions have been performed correctly and to take action (such as moving the content to a different CDN) if the CDN does not live up to expectations.
CSP不一定要完全信任CDN。在某些情况下，CSP将采取措施保护其内容不受CDN的不当分发，例如，对其进行加密并以带外方式分发密钥。CSP还依赖于监控（可能由第三方）和报告，以验证CDN是否充分执行。CSP可以使用诸如基于客户端的计量等技术来验证CDN提供的会计信息是否可靠。HTTP条件请求可用于向CSP提供对CDN操作的一些检查。换句话说，虽然CSP可能信任CDN在短期内执行某些功能，但在大多数情况下，CSP能够验证这些操作是否已正确执行，并在CDN未达到预期时采取措施（例如将内容移动到不同的CDN）。
One of the trust issues raised by CDNI is transitive trust. A CDN that has a direct relationship with a CSP can now "outsource" the delivery of content to another (Downstream) CDN. That CDN may in term outsource delivery to yet another Downstream CDN, and so on.
CDNI提出的信任问题之一是传递性信任。与CSP有直接关系的CDN现在可以将内容交付“外包”给另一个（下游）CDN。该CDN可以长期将交付外包给另一个下游CDN，以此类推。
The top-level CDN in such a chain of delegation is responsible for ensuring that the requirements of the CSP are met. Failure to do so is presumably just as serious as in the traditional single CDN case. Hence, an Upstream CDN is essentially trusting a Downstream CDN to perform functions on its behalf in just the same way as a CSP trusts a single CDN. Monitoring and reporting can similarly be used to verify that the Downstream CDN has performed appropriately. However, the introduction of multiple CDNs in the path between CSP and end user complicates the picture. For example, third-party monitoring of CDN performance (or other aspects of operation, such as timely invalidation) might be able to identify the fact that a problem occurred somewhere in the chain but not point to the particular CDN at fault.
这种委托链中的顶级CDN负责确保满足CSP的要求。如果不这样做，可能与传统的单一CDN案例一样严重。因此，上游CDN本质上信任下游CDN代表其执行功能，就像CSP信任单个CDN一样。监控和报告同样可用于验证下游CDN是否已适当执行。然而，在CSP和最终用户之间的路径中引入多个CDN使情况变得复杂。例如，对CDN性能的第三方监控（或操作的其他方面，如及时失效）可能能够确定链中某个地方发生了问题，但不指向故障的特定CDN。
In summary, we assume that an Upstream CDN will invest a certain amount of trust in a Downstream CDN, but that it will verify that the Downstream CDN is performing correctly, and take corrective action (including potentially breaking off its relationship with that CDN) if behavior is not correct. We do not expect that the trust relationship between a CSP and its "top level" CDN will differ significantly from that found today in single CDN situations. However, it does appear that more sophisticated tools and techniques for monitoring CDN performance and behavior will be required to enable the identification of the CDN at fault in a particular delivery chain.
总之，我们假设上游CDN将对下游CDN投资一定数量的信任，但它将验证下游CDN是否正确运行，并在行为不正确时采取纠正措施（包括可能中断与该CDN的关系）。我们不期望CSP与其“顶级”CDN之间的信任关系与当前单一CDN情况下的信任关系有显著差异。然而，似乎需要更复杂的工具和技术来监控CDN性能和行为，以便能够识别特定交付链中的故障CDN。
We expect that the detailed designs for the specific interfaces for CDNI will need to take the transitive trust issues into account. For example, explicit confirmation that some action (such as content removal) has taken place in a Downstream CDN may help to mitigate some issues of transitive trust.
我们希望CDNI特定接口的详细设计需要考虑可传递信任问题。例如，明确确认下游CDN中发生了某些操作（如内容删除）可能有助于缓解一些传递性信任问题。
In general, a CDN has the opportunity to collect detailed information about the behavior of end users, e.g., by logging which files are being downloaded. While the concept of interconnected CDNs as described in this document doesn't necessarily allow any given CDN to gather more information on any specific user, it potentially facilitates sharing of this data by a CDN with more parties. As an example, the purpose of the CDNI Logging interface is to allow a dCDN to share some of its log records with a uCDN, both for billing purposes as well as for sharing traffic statistics with the Content Provider on whose behalf the content was delivered. The fact that the CDNI interfaces provide mechanisms for sharing such potentially sensitive user data, shows that it is necessary to include in these
通常，CDN有机会收集有关最终用户行为的详细信息，例如，通过记录正在下载的文件。虽然本文档中描述的互连CDN概念不一定允许任何给定CDN收集关于任何特定用户的更多信息，但它可能有助于CDN与更多方共享此数据。例如，CDNI日志记录接口的目的是允许dCDN与uCDN共享其部分日志记录，这既是为了计费目的，也是为了与代表内容交付的内容提供商共享流量统计数据。CDNI接口提供了共享此类潜在敏感用户数据的机制，这一事实表明有必要将其包括在这些接口中
interface appropriate privacy and confidentiality mechanisms. The definition of such mechanisms is dealt with in the respective CDN interface documents.
建立适当的隐私和保密机制。这些机制的定义在各自的CDN接口文档中进行了讨论。
While there are a variety of security issues introduced by a single CDN, we are concerned here specifically with the additional issues that arise when CDNs are interconnected. For example, when a single CDN has the ability to distribute content on behalf of a CSP, there may be concerns that such content could be distributed to parties who are not authorized to receive it, and there are mechanisms to deal with such concerns. Our focus in this section is on how CDNI introduces new security issues not found in the single CDN case. For a more detailed analysis of the security requirements of CDNI, see Section 9 of [RFC7337].
虽然单个CDN会带来各种安全问题，但我们在这里特别关注CDN互连时出现的其他问题。例如，当单个CDN能够代表CSP分发内容时，可能会担心此类内容可能会分发给未经授权接收该内容的各方，并且存在处理此类问题的机制。本节的重点是CDNI如何引入单个CDN案例中未发现的新安全问题。有关CDNI安全要求的更详细分析，请参见[RFC7337]第9节。
Many of the security issues that arise in CDNI are related to the transitivity of trust (or lack thereof) described in Section 6. As noted above, the design of the various interfaces for CDNI must take account of the additional risks posed by the fact that a CDN with whom a CSP has no direct relationship is now potentially distributing content for that CSP. The mechanisms used to mitigate these risks may be similar to those used in the single CDN case, but their suitability in this more complex environment must be validated.
CDNI中出现的许多安全问题都与第6节中描述的信任传递性（或缺乏信任）有关。如上所述，CDNI各种接口的设计必须考虑到与CSP没有直接关系的CDN现在可能正在为该CSP分发内容这一事实所带来的额外风险。用于缓解这些风险的机制可能与单个CDN案例中使用的机制类似，但必须验证其在更复杂环境中的适用性。
CDNs today offer a variety of means to control access to content, such as time-of-day restrictions, geo-blocking, and URI signing. These mechanisms must continue to function in CDNI environments, and this consideration is likely to affect the design of certain CDNI interfaces (e.g., metadata, request routing). For more information on URI signing in CDNI, see [URI-SIGNING].
如今，CDN提供了多种控制内容访问的手段，如时间限制、地理阻止和URI签名。这些机制必须在CDNI环境中继续发挥作用，这种考虑可能会影响某些CDNI接口（例如元数据、请求路由）的设计。有关CDNI中URI签名的更多信息，请参阅[URI-signing]。
Just as with a single CDN, each peer CDN must ensure that it is not used as an "open proxy" to deliver content on behalf of a malicious CSP. Whereas a single CDN typically addresses this problem by having CSPs explicitly register content (or origin servers) that are to be served, simply propagating this information to peer Downstream CDNs may be problematic because it reveals more information than the Upstream CDN is willing to specify. (To this end, the content acquisition step in the earlier examples force the dCDN to retrieve content from the uCDN rather than go directly to the origin server.)
与单个CDN一样，每个对等CDN必须确保它不被用作代表恶意CSP交付内容的“开放代理”。虽然单个CDN通常通过让CSP显式注册要服务的内容（或源服务器）来解决此问题，但简单地将此信息传播到对等下游CDN可能会有问题，因为它显示的信息比上游CDN愿意指定的更多。（为此，前面示例中的内容获取步骤强制dCDN从uCDN检索内容，而不是直接转到源服务器。）
There are several approaches to this problem. One is for the uCDN to encode a signed token generated from a shared secret in each URL routed to a dCDN, and for the dCDN to validate the request based on this token. Another one is to have each Upstream CDN advertise the set of CDN-Domains they serve, where the Downstream CDN checks each
有几种方法可以解决这个问题。一种是uCDN对从路由到dCDN的每个URL中的共享秘密生成的签名令牌进行编码，dCDN根据该令牌验证请求。另一种方法是让每个上游CDN公布它们所服务的CDN域集，其中下游CDN检查每个域
request against this set before caching and delivering the associated object. Although straightforward, this approach requires operators to reveal additional information, which may or may not be an issue.
在缓存和传递关联对象之前对此集合进行请求。尽管这种方法很简单，但需要操作员披露额外的信息，这可能是个问题，也可能不是。
It is noted in [RFC7337] that all CDNI interfaces must be able to operate securely over insecure IP networks. Since it is expected that the CDNI interfaces will be implemented using existing application protocols such as HTTP or Extensible Messaging and Presence Protocol (XMPP), we also expect that the security mechanisms available to those protocols may be used by the CDNI interfaces. Details of how these interfaces are secured will be specified in the relevant interface documents.
[RFC7337]中指出，所有CDNI接口必须能够在不安全的IP网络上安全运行。由于预计CDNI接口将使用现有的应用程序协议（如HTTP或可扩展消息和状态协议（XMPP））实现，因此我们还预计CDNI接口可能会使用这些协议可用的安全机制。有关如何保护这些接口的详细信息将在相关接口文件中规定。
Digital Rights Management (DRM), also sometimes called digital restrictions management, is often employed for content distributed via CDNs. In general, DRM relies on the CDN to distribute encrypted content, with decryption keys distributed to users by some other means (e.g., directly from the CSP to the end user). For this reason, DRM is considered out of scope [RFC6707] and does not introduce additional security issues for CDNI.
数字版权管理（DRM），有时也称为数字限制管理，通常用于通过CDN分发的内容。通常，DRM依赖CDN分发加密内容，并通过其他方式（例如，直接从CSP向最终用户）将解密密钥分发给用户。因此，DRM被视为超出范围[RFC6707]，不会为CDNI带来额外的安全问题。
The following individuals contributed to this document:
以下个人对本文件作出了贡献：
o Matt Caulfield
o 马特考尔菲尔德
o Francois Le Faucheur
o 弗朗索瓦·勒·福彻
o Aaron Falk
o 亚伦·福克
o David Ferguson
o 大卫·弗格森
o John Hartman
o 约翰哈特曼
o Ben Niven-Jenkins
o 本·尼文·詹金斯
o Kent Leung
o 梁建邦
The authors would like to thank Huw Jones and Jinmei Tatuya for their helpful input to this document. In addition, the authors would like to thank Stephen Farrell, Ted Lemon, and Alissa Cooper for their reviews, which have helped to improve this document.
作者要感谢Huw Jones和Jinmei Tatuya对本文件的帮助。此外，作者还要感谢Stephen Farrell、Ted Lemon和Alissa Cooper的评论，这有助于改进本文档。
[CONTROL-TRIGGERS] Murray, R. and B. Niven-Jenkins, "CDNI Control Interface / Triggers", Work in Progress, July 2014.
[CONTROL-TRIGGERS]Murray，R.和B.Niven Jenkins，“CDNI控制接口/触发器”，正在进行的工作，2014年7月。
[FOOTPRINT-CAPABILITY] Seedorf, J., Peterson, J., Previdi, S., Brandenburg, R., and K. Ma, "CDNI Request Routing: Footprint and Capabilities Semantics", Work in Progress, July 2014.
[FOOTPRINT-CAPABILITY]Seedorf，J.，Peterson，J.，Previdi，S.，Brandenburg，R.，和K.Ma，“CDNI请求路由：FOOTPRINT和Capabilities语义”，正在进行的工作，2014年7月。
[LOGGING] Faucheur, F., Ed., Bertrand, G., Ed., Oprescu, I., Ed., and R. Peterkofsky, "CDNI Logging Interface", Work in Progress, July 2014.
[日志记录]Faucheur，F.，Ed.，Bertrand，G.，Ed.，Oprescu，I.，Ed.，和R.Peterkofsky，“CDNI日志记录接口”，正在进行的工作，2014年7月。
[METADATA] Niven-Jenkins, B., Murray, R., Caulfield, M., Leung, K., and K. Ma, "CDN Interconnection Metadata", Work in Progress, July 2014.
[元数据]Niven Jenkins，B.，Murray，R.，Caulfield，M.，Leung，K.，和K.Ma，“CDN互连元数据”，正在进行的工作，2014年7月。
[REDIRECTION] Niven-Jenkins, B., Ed. and R. Brandenburg, Ed., "Request Routing Redirection Interface for CDN Interconnection", Work in Progress, April 2014.
[重定向]Niven Jenkins，B.，Ed.和R.Brandenburg，Ed.，“CDN互连的请求路由重定向接口”，正在进行的工作，2014年4月。
[RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model for Content Internetworking (CDI)", RFC 3466, February 2003.
[RFC3466]Day，M.，Cain，B.，Tomlinson，G.，和P.Rzewski，“内容互联网（CDI）模型”，RFC 3466，2003年2月。
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", RFC 6707, September 2012.
[RFC6707]Niven Jenkins，B.，Le Faucheur，F.，和N.Bitar，“内容分发网络互连（CDNI）问题声明”，RFC 67072012年9月。
[RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, K., and G. Watson, "Use Cases for Content Delivery Network Interconnection", RFC 6770, November 2012.
[RFC6770]Bertrand，G.，Stephan，E.，Burbridge，T.，Eardley，P.，Ma，K.，和G.Watson，“内容交付网络互连的用例”，RFC 67702012年11月。
[RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F., and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware Content Distribution Network Interconnection (CDNI)", RFC 6983, July 2013.
[RFC6983]van Brandenburg，R.，van Deventer，O.，Le Faucheur，F.，和K.Leung，“HTTP自适应流感知内容分发网络互连（CDNI）模型”，RFC 69832013年7月。
[RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution Network Interconnection (CDNI) Requirements", RFC 7337, August 2014.
[RFC7337]Leung，K.，Ed.和Y.Lee，Ed.“内容分发网络互连（CDNI）要求”，RFC 7337，2014年8月。
[URI-SIGNING] Leung, K., Faucheur, F., Downey, B., Brandenburg, R., and S. Leibrand, "URI Signing for CDN Interconnection (CDNI)", Work in Progress, March 2014.
[URI-SIGNING]Leung，K.，Faucheur，F.，Downey，B.，Brandenburg，R.，和S.Leibrand，“CDN互连（CDNI）的URI签名”，正在进行的工作，2014年3月。
Authors' Addresses
作者地址
Larry Peterson Akamai Technologies, Inc. 8 Cambridge Center Cambridge, MA 02142 USA
Larry Peterson Akamai Technologies，Inc.美国马萨诸塞州剑桥市剑桥中心8号邮编：02142
EMail: lapeters@akamai.com
EMail: lapeters@akamai.com
Bruce Davie VMware, Inc. 3401 Hillview Ave. Palo Alto, CA 94304 USA
Bruce Davie VMware，Inc.美国加利福尼亚州帕洛阿尔托山景大道3401号，邮编94304
EMail: bdavie@vmware.com
EMail: bdavie@vmware.com
Ray van Brandenburg (editor) TNO Brassersplein 2 Delft 2612CT the Netherlands
Ray van Brandenburg（编辑）TNO Brasserspein 2 Delft 2612荷兰
Phone: +31-88-866-7000
EMail: ray.vanbrandenburg@tno.nl
Phone: +31-88-866-7000
EMail: ray.vanbrandenburg@tno.nl