Internet Engineering Task Force (IETF) B. Niven-Jenkins
Request for Comments: 6707 Velocix (Alcatel-Lucent)
Category: Informational F. Le Faucheur
ISSN: 2070-1721 Cisco
N. Bitar
Verizon
September 2012
Internet Engineering Task Force (IETF) B. Niven-Jenkins
Request for Comments: 6707 Velocix (Alcatel-Lucent)
Category: Informational F. Le Faucheur
ISSN: 2070-1721 Cisco
N. Bitar
Verizon
September 2012
Content Distribution Network Interconnection (CDNI) Problem Statement
内容分发网络互连（CDNI）问题声明
Abstract
摘要
Content Delivery Networks (CDNs) provide numerous benefits for cacheable content: reduced delivery cost, improved quality of experience for End Users, and increased robustness of delivery. For these reasons, they are frequently used for large-scale content delivery. As a result, existing CDN Providers are scaling up their infrastructure, and many Network Service Providers (NSPs) are deploying their own CDNs. It is generally desirable that a given content item can be delivered to an End User regardless of that End User's location or attachment network. This is the motivation for interconnecting standalone CDNs so they can interoperate as an open content delivery infrastructure for the end-to-end delivery of content from Content Service Providers (CSPs) to End Users. However, no standards or open specifications currently exist to facilitate such CDN Interconnection.
内容交付网络（CDN）为可缓存内容提供了许多好处：降低了交付成本，提高了最终用户的体验质量，增强了交付的健壮性。由于这些原因，它们经常用于大规模内容交付。因此，现有CDN提供商正在扩展其基础设施，许多网络服务提供商（NSP）正在部署自己的CDN。通常希望给定的内容项可以交付给最终用户，而不管该最终用户的位置或附件网络如何。这就是互连独立CDN的动机，这样它们就可以作为开放式内容交付基础设施进行互操作，以便从内容服务提供商（CSP）向最终用户端到端交付内容。然而，目前还没有任何标准或开放规范来促进这种CDN互连。
The goal of this document is to outline the problem area of CDN Interconnection for the IETF CDNI (CDN Interconnection) working group.
本文件的目的是为IETF CDNI（CDN互连）工作组概述CDN互连的问题领域。
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/rfc6707.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6707.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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 ....................................................3
1.1. Terminology ................................................4
1.2. CDN Background .............................................9
2. CDN Interconnection Use Cases ...................................9
3. CDN Interconnection Model and Problem Area for IETF ............11
4. Scoping the CDNI Problem .......................................15
4.1. CDNI Control Interface ....................................16
4.2. CDNI Request Routing Interface ............................16
4.3. CDNI Metadata Interface ...................................17
4.4. CDNI Logging Interface ....................................17
5. Security Considerations ........................................17
5.1. Security of the CDNI Control Interface ....................18
5.2. Security of the CDNI Request Routing Interface ............18
5.3. Security of the CDNI Metadata Interface ...................19
5.4. Security of the CDNI Logging Interface ....................19
6. Acknowledgements ...............................................19
7. Informative References .........................................20
Appendix A. Design Considerations for Realizing the CDNI
Interfaces ............................................22
A.1. CDNI Control Interface .....................................22
A.2. CDNI Request Routing Interface .............................23
A.3. CDNI Metadata Interface ....................................25
A.4. CDNI Logging Interface .....................................26
Appendix B. Additional Material ...................................27
B.1. Non-Goals for IETF .........................................27
B.2. Relationship to Relevant IETF Working Groups and IRTF
Research Groups ............................................29
B.2.1. ALTO WG ................................................29
B.2.2. DECADE WG ..............................................29
B.2.3. PPSP WG ................................................31
B.2.4. IRTF P2P Research Group ................................31
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. CDN Background .............................................9
2. CDN Interconnection Use Cases ...................................9
3. CDN Interconnection Model and Problem Area for IETF ............11
4. Scoping the CDNI Problem .......................................15
4.1. CDNI Control Interface ....................................16
4.2. CDNI Request Routing Interface ............................16
4.3. CDNI Metadata Interface ...................................17
4.4. CDNI Logging Interface ....................................17
5. Security Considerations ........................................17
5.1. Security of the CDNI Control Interface ....................18
5.2. Security of the CDNI Request Routing Interface ............18
5.3. Security of the CDNI Metadata Interface ...................19
5.4. Security of the CDNI Logging Interface ....................19
6. Acknowledgements ...............................................19
7. Informative References .........................................20
Appendix A. Design Considerations for Realizing the CDNI
Interfaces ............................................22
A.1. CDNI Control Interface .....................................22
A.2. CDNI Request Routing Interface .............................23
A.3. CDNI Metadata Interface ....................................25
A.4. CDNI Logging Interface .....................................26
Appendix B. Additional Material ...................................27
B.1. Non-Goals for IETF .........................................27
B.2. Relationship to Relevant IETF Working Groups and IRTF
Research Groups ............................................29
B.2.1. ALTO WG ................................................29
B.2.2. DECADE WG ..............................................29
B.2.3. PPSP WG ................................................31
B.2.4. IRTF P2P Research Group ................................31
The volume of video and multimedia content delivered over the Internet is rapidly increasing and expected to continue doing so in the future. In the face of this growth, Content Delivery Networks (CDNs) provide numerous benefits for cacheable content: reduced delivery cost, improved quality of experience for End Users (EUs), and increased robustness of delivery. For these reasons, CDNs are frequently used for large-scale content delivery. As a result, existing CDN Providers are scaling up their infrastructure, and many Network Service Providers (NSPs) are deploying their own CDNs.
通过互联网传送的视频和多媒体内容的数量正在迅速增加，预计今后还会继续增加。面对这种增长，内容交付网络（CDN）为可缓存内容提供了许多好处：降低了交付成本，提高了最终用户体验质量（EUs），并增强了交付的健壮性。由于这些原因，CDN经常用于大规模内容交付。因此，现有CDN提供商正在扩展其基础设施，许多网络服务提供商（NSP）正在部署自己的CDN。
It is generally desirable that a given content item can be delivered to an EU regardless of that EU's location or the network they are attached to. However, a given CDN in charge of delivering a given content may not have a footprint that expands close enough to the EU's current location or attachment network, or may not have the necessary resources, to realize the user experience and cost benefit that a more distributed CDN infrastructure would allow. This is the motivation for interconnecting standalone CDNs so that their collective CDN footprint and resources can be leveraged for the end-to-end delivery of content from Content Service Providers (CSPs) to EUs. As an example, a CSP could contract with an "authoritative" CDN Provider for the delivery of content, and that Authoritative CDN Provider could contract with one or more downstream CDN Providers to distribute and deliver some or all of the content on behalf of the Authoritative CDN Provider.
通常希望给定的内容项可以交付到欧盟，而不管该欧盟的位置或所连接的网络如何。但是，负责交付给定内容的给定CDN可能没有足够的足迹扩展到欧盟当前位置或连接网络，或者可能没有必要的资源来实现更分布式CDN基础设施所允许的用户体验和成本效益。这就是互连独立CDN的动机，这样它们的集体CDN足迹和资源就可以用于从内容服务提供商（CSP）到EUs的端到端内容交付。例如，CSP可以与“权威”CDN提供商签约以交付内容，并且该权威CDN提供商可以与一个或多个下游CDN提供商签约以代表权威CDN提供商分发和交付部分或全部内容。
A typical end-to-end content delivery scenario would then involve the following business arrangements:
典型的端到端内容交付场景将涉及以下业务安排：
o A business arrangement between the EU and his CSP, authorizing access by the EU to content items controlled by the CSP.
o 欧盟与其客户服务提供商之间的业务安排，授权欧盟访问由客户服务提供商控制的内容项。
o A business arrangement between the CSP and an "authoritative" CDN Provider where the CSP mandates that the CDN Provider perform the content delivery on behalf of the CSP.
o CSP和“权威”CDN提供商之间的业务安排，其中CSP要求CDN提供商代表CSP执行内容交付。
o A business arrangement between the Authoritative CDN Provider and another (or other) CDN(s) where the Authoritative CDN may delegate the actual serving of some of the content delivery requests to the other CDN(s). A particular case is where this other CDN Provider happens to also be the Network Service Provider providing network access to the EU, in which case there is also a separate and independent business relationship between the EU and the NSP for the corresponding network access.
o 权威CDN提供商和另一（或其他）CDN之间的业务安排，其中权威CDN可以将某些内容交付请求的实际服务委托给其他CDN。一种特殊情况是，另一个CDN提供商恰好也是向欧盟提供网络接入的网络服务提供商，在这种情况下，欧盟和NSP之间也存在单独的、独立的业务关系，用于相应的网络接入。
The formation and details of any business relationships between a CSP and a CDN Provider as well as between one CDN Provider and another CDN Provider are out of scope of this document. However, this document concerns itself with the fact that no standards or open specifications currently exist to facilitate such CDN Interconnection from a technical perspective.
CSP和CDN提供商之间以及一个CDN提供商和另一个CDN提供商之间的任何业务关系的形成和细节不在本文档的范围内。然而，本文件关注的是，从技术角度来看，目前没有任何标准或开放规范可促进此类CDN互连。
One possible flow for performing an end-to-end content delivery across a CDN Interconnection is described below:
用于跨CDN互连执行端到端内容交付的一个可能流程描述如下：
o The initial content request from an EU's User Agent is first received by the authoritative (upstream) CDN, which is the CDN with a business arrangement with the CSP.
o 来自欧盟用户代理的初始内容请求首先由权威（上游）CDN接收，该CDN是与CSP有业务安排的CDN。
o The authoritative (upstream) CDN may serve the request itself, or it may elect to use CDN Interconnection to redirect the request to a Downstream CDN that is in a better position to do so (e.g., a Downstream CDN that is "closer" to the EU).
o 权威（上游）CDN可以服务于请求本身，或者它可以选择使用CDN互连将请求重定向到更适合这样做的下游CDN（例如，“更接近”欧盟的下游CDN）。
o The EU's User Agent will "follow" the redirect returned by the Authoritative CDN and request the content from the Downstream CDN. If required, the Downstream CDN will acquire the requested content from the authoritative (upstream) CDN, and if necessary the Authoritative CDN will acquire the requested content from the Content Service Provider.
o 欧盟的用户代理将“跟踪”权威CDN返回的重定向，并从下游CDN请求内容。如果需要，下游CDN将从权威（上游）CDN获取请求的内容，如果需要，权威CDN将从内容服务提供商获取请求的内容。
The goal of this document is to outline the problem area of CDN Interconnection. Section 2 discusses the use cases for CDN Interconnection. Section 3 presents the CDNI model and problem area being considered by the IETF. Section 4 describes each CDNI interface individually and highlights example candidate protocols that could be considered for reuse or leveraging to implement the CDNI interfaces. Appendix B.2 describes the relationships between the CDNI problem space and other relevant IETF working groups and IRTF research groups.
本文档的目标是概述CDN互连的问题领域。第2节讨论CDN互连的用例。第3节介绍了CDNI模型和IETF正在考虑的问题领域。第4节分别描述了每个CDNI接口，并重点介绍了可考虑重用或利用以实现CDNI接口的候选协议示例。附录B.2描述了CDNI问题空间与其他相关IETF工作组和IRTF研究组之间的关系。
This document uses the following terms:
本文件使用以下术语：
Authoritative CDN: A CDN that has a direct relationship with a CSP for the distribution and delivery of that CSP's content by the Authoritative CDN or by Downstream CDNs of the Authoritative CDN.
权威CDN：与CSP有直接关系的CDN，用于通过权威CDN或权威CDN的下游CDN分发和交付该CSP的内容。
CDN Interconnection (CDNI): A relationship between a pair of CDNs that enables one CDN to provide content delivery services on behalf of another CDN. A CDN Interconnection may be wholly or partially realized through a set of interfaces over which a pair of CDNs
CDN互连（CDNI）：一对CDN之间的关系，使一个CDN能够代表另一个CDN提供内容交付服务。CDN互连可通过一组接口全部或部分实现，一对CDN通过一组接口连接
communicate with each other in order to achieve the delivery of content to User Agents by Surrogates in one CDN (the Downstream CDN) on behalf of another CDN (the Upstream CDN).
相互通信，以便通过一个CDN（下游CDN）中的代理代表另一个CDN（上游CDN）向用户代理交付内容。
CDN Provider: The service provider who operates a CDN and offers a service of content delivery, typically used by a Content Service Provider or another CDN Provider. Note that a given entity may operate in more than one role. For example, a company may simultaneously operate as a Content Service Provider, a Network Service Provider, and a CDN Provider.
CDN提供商：运营CDN并提供内容交付服务的服务提供商，通常由内容服务提供商或其他CDN提供商使用。请注意，给定的实体可以在多个角色中运行。例如，公司可以同时作为内容服务提供商、网络服务提供商和CDN提供商运营。
CDNI Metadata: The subset of Content Distribution Metadata that has an inter-CDN scope. For example, CDNI Metadata may include geo-blocking information (i.e., information defining geographical areas where the content is to be made available or blocked), availability windows (i.e., information defining time windows during which the content is to be made available or blocked) and access control mechanisms to be enforced (e.g., URI signature validation). CDNI Metadata may also include information about desired distribution policy (e.g., pre-positioned vs dynamic acquisition) and about where/ how a CDN can acquire the content.
CDNI元数据：具有跨CDN范围的内容分发元数据的子集。例如，CDNI元数据可以包括地理阻止信息（即，定义内容可用或阻止的地理区域的信息）、可用性窗口（即，定义内容可用或阻止的时间窗口的信息）和要实施的访问控制机制（例如，URI签名验证）。CDNI元数据还可能包括有关所需分发策略（例如，预定位与动态获取）以及CDN可以在何处/如何获取内容的信息。
Content: Any form of digital data. One important form of Content with additional constraints on distribution and delivery is continuous media (i.e., where there is a timing relationship between source and sink).
内容：任何形式的数字数据。对分发和交付有额外限制的内容的一种重要形式是连续媒体（即，源和汇之间存在定时关系）。
Content Distribution Metadata: The subset of Content Metadata that is relevant to the distribution of the content. This is the metadata required by a CDN in order to enable and control content distribution and delivery by the CDN. In a CDN Interconnection environment, some of the Content Distribution Metadata may have an intra-CDN scope (and therefore need not be communicated between CDNs), while some of the Content Distribution Metadata may have an inter-CDN scope (and therefore needs to be communicated between CDNs).
内容分发元数据：与内容分发相关的内容元数据子集。这是CDN所需的元数据，用于启用和控制CDN的内容分发和交付。在CDN互连环境中，一些内容分发元数据可能具有CDN内作用域（因此不需要在CDN之间通信），而一些内容分发元数据可能具有CDN间作用域（因此需要在CDN之间通信）。
Content Distribution Network (CDN) / Content Delivery Network (CDN): Network infrastructure in which the network elements cooperate at Layers 4 through 7 for more effective delivery of Content to User Agents. Typically, a CDN consists of a Request Routing system, a Distribution system (that includes a set of Surrogates), a Logging system, and a CDN Control system.
内容分发网络（CDN）/内容交付网络（CDN）：网络基础设施，其中网络元素在第4层到第7层进行协作，以便更有效地将内容交付给用户代理。通常，CDN由请求路由系统、分发系统（包括一组代理）、日志系统和CDN控制系统组成。
Content Metadata: This is metadata about Content. Content Metadata comprises:
内容元数据：这是关于内容的元数据。内容元数据包括：
1. Metadata that is relevant to the distribution of the content (and therefore relevant to a CDN involved in the delivery of that content). We refer to this type of metadata as "Content Distribution Metadata". See also the definition of Content Distribution Metadata.
1. 与内容分发相关的元数据（因此与交付该内容所涉及的CDN相关）。我们将这种元数据称为“内容分发元数据”。另请参见内容分发元数据的定义。
2. Metadata that is associated with the actual Content or content representation, and not directly relevant to the distribution of that Content. For example, such metadata may include information pertaining to the Content's genre, cast, rating, etc. as well as information pertaining to the Content representation's resolution, aspect ratio, etc.
2. 与实际内容或内容表示关联，且与该内容的分发不直接相关的元数据。例如，这种元数据可以包括与内容的类型、演员阵容、评级等有关的信息，以及与内容表示的分辨率、纵横比等有关的信息。
Content Service: The service offered by a Content Service Provider. The Content Service encompasses the complete service, which may be wider than just providing access to items of Content; e.g., the Content Service also includes any middleware, key distribution, program guide, etc. that may not require any direct interaction with the CDN, or CDNs, involved in the distribution and delivery of the content.
内容服务：由内容服务提供商提供的服务。内容服务包括完整的服务，其范围可能比仅提供对内容项的访问更广；e、 例如，内容服务还包括任何中间件、密钥分发、节目指南等，这些内容分发和交付过程中可能不需要与CDN或CDN进行任何直接交互。
Content Service Provider (CSP): Provides a Content Service to End Users (which they access via a User Agent). A CSP may own the Content made available as part of the Content Service, or may license content rights from another party.
内容服务提供商（CSP）：向最终用户（他们通过用户代理访问）提供内容服务。CSP可以拥有作为内容服务一部分提供的内容，或者可以从另一方许可内容权利。
Control system: The function within a CDN responsible for bootstrapping and controlling the other components of the CDN as well as for handling interactions with external systems (e.g., handling delivery service creation/update/removal requests, or specific service provisioning requests).
控制系统：CDN中的功能，负责引导和控制CDN的其他组件，以及处理与外部系统的交互（例如，处理交付服务创建/更新/删除请求，或特定服务提供请求）。
Delivery: The function within CDN Surrogates responsible for delivering a piece of content to the User Agent. For example, delivery may be based on HTTP progressive download or HTTP adaptive streaming.
交付：CDN代理中负责向用户代理交付内容的功能。例如，交付可以基于HTTP渐进下载或HTTP自适应流。
Distribution system: The function within a CDN responsible for distributing Content Distribution Metadata as well as the Content itself inside the CDN (e.g., down to the Surrogates).
分发系统：CDN内负责分发内容分发元数据以及CDN内内容本身（例如，向下到代理）的功能。
Downstream CDN: For a given End User request, the CDN (within a pair of directly interconnected CDNs) to which the request is redirected by the other CDN (the Upstream CDN). Note that in the case of successive redirections (e.g., CDN1-->CDN2-->CDN3), a given CDN
下游CDN：对于给定的最终用户请求，请求被另一个CDN（上游CDN）重定向到的CDN（在一对直接互连的CDN中）。请注意，在连续重定向的情况下（例如，CDN1-->CDN2-->CDN3），给定的CDN
(e.g., CDN2) may act as the Downstream CDN for a redirection (e.g., CDN1-->CDN2) and as the Upstream CDN for the subsequent redirection of the same request (e.g., CDN2-->CDN3).
（例如，CDN2）可以用作重定向的下游CDN（例如，CDN1-->CDN2），也可以用作同一请求的后续重定向的上游CDN（例如，CDN2-->CDN3）。
Dynamic CDNI Metadata acquisition: In the context of CDN Interconnection, dynamic CDNI Metadata acquisition means that a Downstream CDN acquires CDNI Metadata for content from the Upstream CDN at some point in time after a request for that content is delegated to the Downstream CDN by an Upstream CDN (and that specific CDNI Metadata is not yet available in the Downstream CDN). See also the definitions for Downstream CDN and Upstream CDN.
动态CDNI元数据获取：在CDN互连的上下文中，动态CDNI元数据获取意味着下游CDN在上游CDN将内容请求委托给下游CDN后的某个时间点从上游CDN获取内容的CDNI元数据（下游CDN中尚未提供特定的CDNI元数据）。另请参见下游CDN和上游CDN的定义。
Dynamic content acquisition: Dynamic content acquisition is where a CDN acquires content from the content source in response to an End User requesting that content from the CDN. In the context of CDN Interconnection, dynamic acquisition means that a Downstream CDN acquires the content from content sources (including Upstream CDNs) at some point in time after a request for that content is delegated to the Downstream CDN by an Upstream CDN (and that specific content is not yet available in the Downstream CDN).
动态内容获取：动态内容获取是指CDN响应最终用户从CDN请求内容而从内容源获取内容。在CDN互连的上下文中，动态获取意味着在上游CDN将对内容的请求委托给下游CDN之后的某个时间点，下游CDN从内容源（包括上游CDN）获取内容（并且该特定内容在下游CDN中尚不可用）。
End User (EU): The 'real' user of the system, typically a human but maybe some combination of hardware and/or software emulating a human (e.g., for automated quality monitoring etc.).
最终用户（EU）：系统的“真实”用户，通常是人，但可能是模拟人的硬件和/或软件的组合（例如，用于自动质量监控等）。
Logging system: The function within a CDN responsible for collecting the measurement and recording of distribution and delivery activities. The information recorded by the Logging system may be used for various purposes, including charging (e.g., of the CSP), analytics, and monitoring.
记录系统：CDN中负责收集分发和交付活动的测量和记录的功能。记录系统记录的信息可用于各种目的，包括收费（例如CSP）、分析和监控。
Metadata: Metadata in general is data about data.
元数据：元数据通常是关于数据的数据。
Network Service Provider (NSP): Provides network-based connectivity/ services to End Users.
网络服务提供商（NSP）：向最终用户提供基于网络的连接/服务。
Over-the-top (OTT): A service, e.g., content delivery using a CDN, operated by a different operator than the NSP to which the users of that service are attached.
Over-the-top（OTT）：一种服务，例如，使用CDN的内容交付，由不同于NSP的运营商运营，该服务的用户连接到NSP。
Pre-positioned CDNI Metadata acquisition: In the context of CDN Interconnection, CDNI Metadata pre-positioning is where the Downstream CDN acquires CDNI Metadata for content prior to, or independently of, any End User requesting that content from the Downstream CDN.
预定位CDNI元数据获取：在CDN互连的上下文中，CDNI元数据预定位是指下游CDN在任何最终用户向下游CDN请求内容之前或独立于任何最终用户从下游CDN获取内容的CDNI元数据。
Pre-positioned content acquisition: Content pre-positioning is where a CDN acquires content from the content source prior to, or independently of, any End User requesting that content from the CDN. In the context of CDN Interconnection, the Upstream CDN instructs the Downstream CDN to acquire the content from content sources (including Upstream CDNs) in advance of, or independently of, any End User requesting it.
预定位内容获取：内容预定位是指CDN在任何最终用户向CDN请求内容之前或独立于任何最终用户从内容源获取内容。在CDN互连的上下文中，上游CDN指示下游CDN在任何终端用户请求之前或独立于任何终端用户请求之前从内容源（包括上游CDN）获取内容。
Quality of Experience (QoE): As defined in Section 2.4 of [RFC6390].
经验质量（QoE）：如[RFC6390]第2.4节所定义。
Request Routing system: The function within a CDN responsible for receiving a Content Request from a User Agent, obtaining and maintaining necessary information about a set of candidate Surrogates or candidate CDNs, and for selecting and redirecting the user to the appropriate Surrogate or CDN. To enable CDN Interconnection, the Request Routing system must also be capable of handling User Agent Content Requests passed to it by another CDN.
请求路由系统：CDN中的功能，负责接收来自用户代理的内容请求，获取和维护关于一组候选代理或候选CDN的必要信息，并选择用户并将其重定向到适当的代理或CDN。为了实现CDN互连，请求路由系统还必须能够处理由另一个CDN传递给它的用户代理内容请求。
Surrogate: A device/function (often called a cache) that interacts with other elements of the CDN for the control and distribution of Content within the CDN and interacts with User Agents for the delivery of the Content. Typically, Surrogates will cache requested content so that they can directly deliver the same content in response to requests from multiple User Agents (and their End Users), avoiding the need for the content to transit multiple times through the network core (i.e., from the content origin to the Surrogate).
代理：一种设备/功能（通常称为缓存），与CDN的其他元素交互以控制和分发CDN内的内容，并与用户代理交互以交付内容。通常，代理将缓存请求的内容，以便它们可以直接交付相同的内容以响应来自多个用户代理（及其最终用户）的请求，从而避免内容需要多次通过网络核心传输（即，从内容源到代理）。
Upstream CDN: For a given End User request, the CDN (within a pair of directly interconnected CDNs) that redirects the request to the other CDN.
上游CDN：对于给定的最终用户请求，将请求重定向到另一个CDN的CDN（在一对直接互连的CDN中）。
User Agent (UA): Software (or a combination of hardware and software) through which the End User interacts with a Content Service. The User Agent will communicate with a Content Service for the selection of content and one or more CDNs for the delivery of the Content. Such communication is not restricted to HTTP and may be via a variety of protocols. Examples of User Agents (non-exhaustive) are browsers, Set Top Boxes (STBs), dedicated content applications (e.g., media players), etc.
用户代理（UA）：最终用户与内容服务交互的软件（或硬件和软件的组合）。用户代理将与内容服务通信以选择内容，并与一个或多个CDN通信以交付内容。这种通信不限于HTTP，可以通过各种协议进行。用户代理（非穷举）的示例包括浏览器、机顶盒（STB）、专用内容应用程序（例如媒体播放器）等。
Readers are assumed to be familiar with the architecture, features, and operation of CDNs. For readers less familiar with the operation of CDNs, the following resources may be useful:
假定读者熟悉CDN的体系结构、功能和操作。对于不太熟悉CDN操作的读者，以下资源可能很有用：
o RFC 3040 [RFC3040] describes many of the component technologies that are used in the construction of a CDN.
o RFC 3040[RFC3040]描述了CDN构建中使用的许多组件技术。
o Taxonomy [TAXONOMY] compares the architecture of a number of CDNs.
o 分类法[分类法]比较了许多CDN的体系结构。
o RFC 3466 [RFC3466] and RFC 3570 [RFC3570] are the output of the IETF Content Distribution Internetworking (CDI) working group, which was closed in 2003.
o RFC 3466[RFC3466]和RFC 3570[RFC3570]是IETF内容分发互联网（CDI）工作组的输出，该工作组于2003年关闭。
Note: Some of the terms used in this document are similar to terms used in the above referenced documents. When reading this document, terms should be interpreted as having the definitions provided in Section 1.1.
注：本文件中使用的一些术语与上述参考文件中使用的术语类似。阅读本文件时，应将术语解释为具有第1.1节中提供的定义。
An increasing number of NSPs are deploying CDNs in order to deal cost-effectively with the growing usage of on-demand video services and other content delivery applications.
越来越多的NSP正在部署CDN，以便经济高效地应对日益增长的按需视频服务和其他内容交付应用程序的使用。
CDNs allow caching of content closer to the edge of a network so that a given item of content can be delivered by a CDN Surrogate (i.e., a cache) to multiple User Agents (and their End Users) without transiting multiple times through the network core (i.e., from the content origin to the Surrogate). This contributes to bandwidth cost reductions for the NSP and to improved quality of experience for the End Users. CDNs also enable replication of popular content across many Surrogates, which enables content to be served to large numbers of User Agents concurrently. This also helps in dealing with situations such as flash crowds and denial-of-service attacks.
CDN允许缓存靠近网络边缘的内容，以便CDN代理（即缓存）可以将给定的内容项交付给多个用户代理（及其最终用户），而无需通过网络核心多次传输（即从内容源到代理）。这有助于降低NSP的带宽成本，并提高最终用户的体验质量。CDN还支持跨多个代理复制流行内容，从而使内容能够同时提供给大量用户代理。这也有助于处理闪电群和拒绝服务攻击等情况。
The CDNs deployed by NSPs are not just restricted to the delivery of content to support the Network Service Provider's own 'walled garden' services, such as IP delivery of television services to Set Top Boxes, but are also used for delivery of content to other devices, including PCs, tablets, mobile phones, etc.
NSPs部署的CDN不仅限于交付内容，以支持网络服务提供商自己的“围墙花园”服务，如向机顶盒提供电视服务的IP交付，还用于向其他设备（包括PC、平板电脑、移动电话等）交付内容。
Some service providers operate over multiple geographies and federate multiple affiliate NSPs. These NSPs typically operate independent CDNs. As they evolve their services (e.g., for seamless support of content services to nomadic users across affiliate NSPs), there is a
一些服务提供商跨多个地理区域运营，并联合多个分支NSP。这些NSP通常运行独立的CDN。随着他们服务的发展（例如，在分支机构NSP中为游牧用户提供内容服务的无缝支持），有一个
need for interconnection of these CDNs; this represents a first use case for CDNI. However, there are no open specifications, nor common best practices, defining how to achieve such CDN Interconnection.
这些CDN需要互连；这是CDNI的第一个用例。然而，没有开放的规范，也没有通用的最佳实践来定义如何实现这种CDN互连。
CSPs have a desire to be able to get (some of) their content to very large numbers of End Users, who are often distributed across a number of geographies, while maintaining a high quality of experience, all without having to maintain direct business relationships with many different CDN Providers (or having to extend their own CDN to a large number of locations). Some NSPs are considering interconnecting their respective CDNs (as well as possibly over-the-top CDNs) so that this collective infrastructure can address the requirements of CSPs in a cost-effective manner. This represents a second use case for CDNI. In particular, this would enable the CSPs to benefit from on-net delivery (i.e., within the Network Service Provider's own network/CDN footprint) whenever possible and off-net delivery otherwise, without requiring the CSPs to maintain direct business relationships with all the CDNs involved in the delivery. Again, CDN Providers (NSPs or over-the-top CDN operators) are faced with a lack of open specifications and best practices.
CSP希望能够将（部分）内容提供给大量最终用户，这些用户通常分布在多个地区，同时保持高质量的体验，而无需与许多不同的CDN提供商保持直接的业务关系（或者必须将自己的CDN扩展到大量位置）。一些NSP正在考虑将各自的CDN（以及可能的顶级CDN）互连因此，这种集体基础设施能够以经济高效的方式满足CSP的要求。这代表了CDNI的第二个使用案例。特别是，这将使CSP能够从网上交付中受益（即，在网络服务提供商自己的网络/CDN覆盖范围内）在可能的情况下，不要求客户服务提供商与交付中涉及的所有CDN保持直接业务关系。同样，CDN提供商（NSP或顶级CDN运营商）面临着缺乏开放规范和最佳实践的问题。
NSPs have often deployed CDNs as specialized cost-reduction projects within the context of a particular service or environment. Some NSPs operate separate CDNs for separate services. For example, there may be a CDN for managed IPTV service delivery, a CDN for web-TV delivery, and a CDN for video delivery to mobile terminals. As NSPs integrate their service portfolio, there is a need for interconnecting these CDNs, representing a third use case for CDNI. Again, NSPs face the problem of lack of open interfaces for CDN Interconnection.
NSP通常将CDN部署为特定服务或环境中的专门成本降低项目。一些NSP为单独的服务运行单独的CDN。例如，可能存在用于托管IPTV服务交付的CDN、用于web电视交付的CDN和用于向移动终端视频交付的CDN。随着NSP集成其服务组合，需要将这些CDN互连，这是CDNI的第三个使用案例。NSP同样面临CDN互连缺乏开放接口的问题。
For operational reasons (e.g., disaster, flash crowd) or commercial reasons, an over-the-top CDN may elect to make use of another CDN (e.g., an NSP CDN with on-net Surrogates for a given footprint) for serving a subset of the user requests (e.g., requests from users attached to that NSP), which results in a fourth use case for CDNI because CDN Providers (over-the-top CDN Providers or NSPs) are faced with a lack of open specifications and best practices.
出于运营原因（例如，灾难、flash群组）或商业原因，超顶级CDN可以选择使用另一个CDN（例如，具有给定封装外形的在线代理的NSP CDN）来服务用户请求的子集（例如，来自附加到该NSP的用户的请求），这导致了CDNI的第四个用例，因为CDN提供商（顶级CDN提供商或NSP）面临着缺乏开放规范和最佳实践的问题。
Use cases for CDN Interconnection are further discussed in [CDNI-USE-CASES].
[CDNI-用例]中进一步讨论了CDN互连的用例。
This section discusses the problem area for the IETF work on CDN Interconnection.
本节讨论IETF在CDN互连方面的问题领域。
Interconnecting CDNs involves interactions among multiple different functions and components that form each CDN. Only some of those require additional specification by the IETF.
互连CDN涉及构成每个CDN的多个不同功能和组件之间的相互作用。只有其中一些需要IETF的附加规范。
Some NSPs have started to perform experiments to explore whether their CDN use cases can already be addressed with existing CDN implementations. One set of such experiments is documented in [CDNI-EXPERIMENTS]. The conclusions of those experiments are that while some basic limited CDN Interconnection functionality can be achieved with existing CDN technology, the current lack of any standardized CDNI interfaces with the necessary level of functionality such as those discussed in this document is preventing the deployment of CDN Interconnection.
一些NSP已经开始进行实验，以探索他们的CDN用例是否已经可以通过现有的CDN实现来解决。[CDNI-实验]中记录了一组此类实验。这些实验的结论是，虽然现有CDN技术可以实现一些基本的有限CDN互连功能，但目前缺乏任何具有必要功能级别的标准化CDNI接口（如本文中讨论的），这妨碍了CDN互连的部署。
Listed below are the four interfaces required to interconnect a pair of CDNs and that constitute the problem space of CDN Interconnection along with the required functionality of each interface for which standards do not currently exist. As part of the development of the CDNI interfaces, it will also be necessary to agree on common mechanisms for how to identify and name the data objects that are to be interchanged between interconnected CDNs.
下面列出了互连一对CDN所需的四个接口，它们构成了CDN互连的问题空间，以及每个接口所需的功能，目前还没有标准。作为CDNI接口开发的一部分，还需要就如何识别和命名互连CDN之间交换的数据对象的通用机制达成一致。
The use of the term "interface" is meant to encompass the protocol over which CDNI data representations (e.g., CDNI Metadata objects) are exchanged as well as the specification of the data representations themselves (i.e., what properties/fields each object contains, its structure, etc.).
术语“接口”的使用意指包含交换CDNI数据表示（例如，CDNI元数据对象）的协议以及数据表示本身的规范（即，每个对象包含哪些属性/字段、其结构等）。
o CDNI Control interface: This interface allows the "CDNI Control" system in interconnected CDNs to communicate. This interface may support the following:
o CDNI控制接口：该接口允许互连CDN中的“CDNI控制”系统进行通信。此接口可支持以下功能：
* Allow bootstrapping of the other CDNI interfaces (e.g., interface address/URL discovery and establishment of security associations).
* 允许引导其他CDNI接口（例如，接口地址/URL发现和建立安全关联）。
* Allow configuration of the other CDNI interfaces (e.g., Upstream CDN specifies information to be reported through the CDNI Logging interface).
* 允许配置其他CDNI接口（例如，上游CDN指定通过CDNI日志记录接口报告的信息）。
* Allow the Downstream CDN to communicate static (or fairly static) information about its delivery capabilities and policies.
* 允许下游CDN传递有关其交付能力和策略的静态（或相当静态）信息。
* Allow bootstrapping of the interface between CDNs for content acquisition (even if that interface itself is outside the scope of the CDNI work).
* 允许引导CDN之间的接口以获取内容（即使该接口本身不在CDNI工作范围内）。
* Allow an Upstream CDN to initiate or request specific actions to be undertaken in the Downstream CDN. For example, to allow an Upstream CDN to initiate content or CDNI Metadata acquisition (pre-positioning) or to request the invalidation or purging of content files and/or CDNI Metadata in a Downstream CDN.
* 允许上游CDN启动或请求在下游CDN中执行特定操作。例如，允许上游CDN启动内容或CDNI元数据获取（预定位），或请求对下游CDN中的内容文件和/或CDNI元数据进行失效或清除。
o CDNI Request Routing interface: This interface allows the Request Routing systems in interconnected CDNs to communicate to ensure that an End User request can be (re)directed from an Upstream CDN to a Surrogate in the Downstream CDN, in particular where selection responsibilities may be split across CDNs (for example, the Upstream CDN may be responsible for selecting the Downstream CDN, while the Downstream CDN may be responsible for selecting the actual Surrogate within that Downstream CDN). In particular, the functions of the CDN Request Routing interface may be divided as follows:
o CDNI请求路由接口：该接口允许互连CDN中的请求路由系统进行通信，以确保最终用户请求可以（重新）从上游CDN定向到下游CDN中的代理，特别是在选择责任可能在CDN之间分配的情况下（例如，上游CDN可能负责选择下游CDN，而下游CDN可能负责选择该下游CDN内的实际代理）。具体而言，CDN请求路由接口的功能可以划分为以下几部分：
* A CDNI Request Routing Redirection interface, which allows the Upstream CDN to query the Downstream CDN at request routing time before redirecting the request to the Downstream CDN.
* CDNI请求路由重定向接口，允许上游CDN在请求路由时查询下游CDN，然后再将请求重定向到下游CDN。
* A CDNI Footprint & Capabilities advertisement interface, which allows the Downstream CDN to provide to the Upstream CDN (static or dynamic) information (e.g., resources, footprint, load) to facilitate selection of the Downstream CDN by the Upstream CDN Request Routing system when processing subsequent Content Requests from User Agents.
* CDNI Footprint&Capabilities广告接口，允许下游CDN向上游CDN提供（静态或动态）信息（例如，资源、足迹、负载），以便于上游CDN请求路由系统在处理来自用户代理的后续内容请求时选择下游CDN。
o CDNI Metadata interface: This interface allows the Distribution system in interconnected CDNs to communicate to ensure that CDNI Metadata can be exchanged across CDNs. See Section 1.1 for the definition and examples of CDNI Metadata.
o CDNI元数据接口：此接口允许互连CDN中的分发系统进行通信，以确保CDNI元数据可以在CDN之间交换。有关CDNI元数据的定义和示例，请参见第1.1节。
o CDNI Logging interface: This interface allows the Logging system in interconnected CDNs to communicate the relevant activity logs in order to allow log-consuming applications to operate in a multi-CDN environment. For example, an Upstream CDN may collect delivery logs from a Downstream CDN in order to perform consolidated charging of the CSP or for settlement purposes across CDNs. Similarly, an Upstream CDN may collect delivery logs from a Downstream CDN in order to provide consolidated reporting and monitoring to the CSP.
o CDNI日志接口：此接口允许互连CDN中的日志系统与相关活动日志通信，以便允许日志消耗应用程序在多CDN环境中运行。例如，上游CDN可以从下游CDN收集交付日志，以便执行CSP的合并计费或用于跨CDN的结算目的。类似地，上游CDN可以从下游CDN收集交付日志，以便向CSP提供合并报告和监控。
Note that the actual grouping of functionalities under these four interfaces is considered tentative at this stage and may be changed after further study (e.g., some subset of functionality may be moved from one interface into another).
请注意，这四个接口下的实际功能分组在本阶段被视为暂定，并可能在进一步研究后更改（例如，功能的某些子集可能从一个接口移动到另一个接口）。
The above list covers a significant potential problem space, in part because in order to interconnect two CDNs there are several 'touch points' that require standardization. However, it is expected that the CDNI interfaces need not be defined from scratch and instead can reuse or leverage existing protocols to a very significant extent; this is discussed further in Section 4.
上述列表涵盖了一个重要的潜在问题空间，部分原因是为了互连两个CDN，有几个“接触点”需要标准化。然而，预计CDNI接口不需要从头定义，而是可以在很大程度上重用或利用现有协议；这将在第4节中进一步讨论。
The interfaces that form the CDNI problem area are illustrated in Figure 1.
构成CDNI问题区域的接口如图1所示。
--------
/ \
| CSP |
\ /
--------
*
*
* /\
* / \
---------------------- |CDNI| ----------------------
/ Upstream CDN \ | | / Downstream CDN \
| +-------------+ | Control Interface| +-------------+ |
|******* Control |<======|====|========>| Control *******|
|* +------*----*-+ | | | | +-*----*------+ *|
|* * * | | | | * * *|
|* +------*------+ | Logging Interface| +------*------+ *|
|* ***** Logging |<======|====|========>| Logging ***** *|
|* * +-*-----------+ | | | | +-----------*-+ * *|
|* * * * | Request Routing | * * * *|
.....*...+-*---------*-+ | Interface | +-*---------*-+...*.*...
. |* * *** Req-Routing |<======|====|========>| Req-Routing *** * *| .
. |* * * +-------------+.| | | | +-------------+ * * *| .
. |* * * . CDNI Metadata | * * *| .
. |* * * +-------------+ |. Interface | +-------------+ * * *| .
. |* * * | Distribution|<==.===|====|========>| Distribution| * * *| .
. |* * * | | | . \ / | | | * * *| .
. |* * * |+---------+ | | . \/ | | +---------+| * * *| .
. |* * ***| +---------+| | ....Request......+---------+ |*** * *| .
. |* *****+-|Surrogate|************************|Surrogate|-+***** *| .
. |******* +---------+| | Acquisition | |+----------+ *******| .
. | +-------------+ | | +-------*-----+ | .
. \ / \ * / .
. ---------------------- ---------*------------ .
. * .
. * Delivery .
. * .
. +--*---+ .
...............Request.............................| User |..Request..
| Agent|
+------+
--------
/ \
| CSP |
\ /
--------
*
*
* /\
* / \
---------------------- |CDNI| ----------------------
/ Upstream CDN \ | | / Downstream CDN \
| +-------------+ | Control Interface| +-------------+ |
|******* Control |<======|====|========>| Control *******|
|* +------*----*-+ | | | | +-*----*------+ *|
|* * * | | | | * * *|
|* +------*------+ | Logging Interface| +------*------+ *|
|* ***** Logging |<======|====|========>| Logging ***** *|
|* * +-*-----------+ | | | | +-----------*-+ * *|
|* * * * | Request Routing | * * * *|
.....*...+-*---------*-+ | Interface | +-*---------*-+...*.*...
. |* * *** Req-Routing |<======|====|========>| Req-Routing *** * *| .
. |* * * +-------------+.| | | | +-------------+ * * *| .
. |* * * . CDNI Metadata | * * *| .
. |* * * +-------------+ |. Interface | +-------------+ * * *| .
. |* * * | Distribution|<==.===|====|========>| Distribution| * * *| .
. |* * * | | | . \ / | | | * * *| .
. |* * * |+---------+ | | . \/ | | +---------+| * * *| .
. |* * ***| +---------+| | ....Request......+---------+ |*** * *| .
. |* *****+-|Surrogate|************************|Surrogate|-+***** *| .
. |******* +---------+| | Acquisition | |+----------+ *******| .
. | +-------------+ | | +-------*-----+ | .
. \ / \ * / .
. ---------------------- ---------*------------ .
. * .
. * Delivery .
. * .
. +--*---+ .
...............Request.............................| User |..Request..
| Agent|
+------+
<==> interfaces inside the scope of CDNI
**** interfaces outside the scope of CDNI
.... interfaces outside the scope of CDNI
<==> interfaces inside the scope of CDNI
**** interfaces outside the scope of CDNI
.... interfaces outside the scope of CDNI
Figure 1: A Model for the CDNI Problem Area
图1：CDNI问题区域的模型
As illustrated in Figure 1, the acquisition of content between interconnected CDNs is out of scope for CDNI; this deserves some additional explanation. The consequence of such a decision is that the CDNI problem space described in this document is focused on only defining the control plane for CDNI, and the CDNI data plane (i.e., the acquisition and distribution of the actual content objects) is out of scope. The rationale for such a decision is that CDNs today typically already use standardized protocols such as HTTP, FTP, rsync, etc. to acquire content from their CSP customers, and it is expected that the same protocols could be used for acquisition between interconnected CDNs. Therefore, the problem of content acquisition is considered already solved, and all that is required with respect to content acquisition from specifications developed by the CDNI working group is to describe within the CDNI Metadata the parameters to use to retrieve the content -- for example, the IP address/hostname to connect to, what protocol to use to retrieve the content, etc.
如图1所示，互联CDN之间的内容获取超出了CDNI的范围；这需要一些额外的解释。这一决定的结果是，本文档中描述的CDNI问题空间仅集中于定义CDNI的控制平面，而CDNI数据平面（即实际内容对象的获取和分发）超出了范围。做出这一决定的理由是，如今的CDN通常已经使用标准化协议（如HTTP、FTP、rsync等）从其CSP客户处获取内容，并且预期相同的协议可以用于互连CDN之间的获取。因此，内容获取的问题被认为已经解决，从CDNI工作组制定的规范中获取内容所需的只是在CDNI元数据中描述用于检索内容的参数——例如，要连接的IP地址/主机名，使用什么协议来检索内容等。
This section outlines how the scope of work addressing the CDNI problem space can be constrained through reuse or leveraging of existing protocols to implement the CDNI interfaces. This discussion is not intended to preempt any working group decision as to the most appropriate protocols, technologies, and solutions to select to realize the CDNI interfaces but is intended as an illustration of the fact that the CDNI interfaces need not be created in a vacuum and that reuse or leverage of existing protocols is likely possible.
本节概述了如何通过重用或利用现有协议来实现CDNI接口来限制解决CDNI问题空间的工作范围。本次讨论的目的并不是为了抢占工作组关于选择最合适的协议、技术和解决方案来实现CDNI接口的任何决定，而是为了说明CDNI接口不需要在真空中创建，并且现有协议的重用或利用是可能的。
The four CDNI interfaces (CDNI Control interface, CDNI Request Routing interface, CDNI Metadata interface, and CDNI Logging interface) described in Section 3 within the CDNI problem area are all control plane interfaces operating at the application layer (Layer 7 in the OSI network model). Firstly, since it is not expected that these interfaces would exhibit unique session, transport, or network requirements as compared to the many other existing applications in the Internet, it is expected that the CDNI interfaces will be defined on top of existing session, transport, and network protocols.
CDNI问题区域第3节中描述的四个CDNI接口（CDNI控制接口、CDNI请求路由接口、CDNI元数据接口和CDNI日志接口）都是在应用层（OSI网络模型中的第7层）运行的控制平面接口。首先，由于与互联网中的许多其他现有应用程序相比，这些接口不会表现出独特的会话、传输或网络要求，因此，预计CDNI接口将在现有会话、传输和网络协议的基础上定义。
Secondly, although a new application protocol could be designed specifically for CDNI, our analysis below shows that this is unnecessary, and it is recommended that existing application protocols be reused or leveraged (HTTP [RFC2616], the Atom Publishing Protocol [RFC5023], the Extensible Messaging and Presence Protocol (XMPP) [RFC6120], for example) to realize the CDNI interfaces.
其次，尽管可以专门为CDNI设计一个新的应用程序协议，但我们下面的分析表明，这是不必要的，建议重用或利用现有的应用程序协议（HTTP[RFC2616]、Atom发布协议[RFC5023]、可扩展消息和状态协议（XMPP）[RFC6120]，例如）实现CDNI接口。
The CDNI Control interface allows the Control system in interconnected CDNs to communicate. The exact inter-CDN control functionality required to be supported by the CDNI Control interface is less well defined than the other three CDNI interfaces at this time.
CDNI控制接口允许互连CDN中的控制系统进行通信。目前，CDNI控制接口需要支持的确切的CDN间控制功能的定义不如其他三个CDNI接口好。
It is expected that for the Control interface, as for the other CDNI interfaces, existing protocols can be reused or leveraged.
对于控制接口，与其他CDNI接口一样，可以重用或利用现有协议。
The CDNI Request Routing interface enables a Request Routing function in an Upstream CDN to query a Request Routing function in a Downstream CDN to determine if the Downstream CDN is able (and willing) to accept the delegated Content Request. It also allows the Downstream CDN to control what should be returned to the User Agent in the redirection message by the upstream Request Routing function.
CDNI请求路由接口使上游CDN中的请求路由功能能够查询下游CDN中的请求路由功能，以确定下游CDN是否能够（并且愿意）接受委托内容请求。它还允许下游CDN控制上游请求路由功能在重定向消息中应返回给用户代理的内容。
The CDNI Request Routing interface is therefore a fairly straightforward request/response interface and could be implemented over any number of request/response protocols. For example, it may be implemented as a WebService using one of the common WebServices methodologies (Extensible Markup Language-Remote Procedure Calling (XML-RPC), HTTP query to a known URI, etc.). This removes the need for the CDNI working group to define a new protocol for the request/ response element of the CDNI Request Routing interface.
因此，CDNI请求路由接口是一个相当简单的请求/响应接口，可以通过任意数量的请求/响应协议实现。例如，它可以使用一种常见的Web服务方法（可扩展标记语言远程过程调用（XML-RPC）、对已知URI的HTTP查询等）实现为Web服务。这样就不需要CDNI工作组为CDNI请求路由接口的请求/响应元素定义新协议。
Additionally, as discussed in Section 3, the CDNI Request Routing interface is also expected to enable a Downstream CDN to provide to the Upstream CDN (static or dynamic) information (e.g., resources, footprint, load) to facilitate selection of the Downstream CDN by the Upstream CDN Request Routing system when processing subsequent Content Requests from User Agents. It is expected that such functionality of the CDNI request routing could be specified by the CDNI working group with significant leveraging of existing IETF protocols supporting the dynamic distribution of reachability information (for example, by leveraging existing routing protocols) or supporting application-level queries for topological information (for example, by leveraging Application-Layer Traffic Optimization (ALTO) [RFC5693]).
此外，如第3节所述，CDNI请求路由接口还应能够使下游CDN向上游CDN提供（静态或动态）信息（例如，资源、占地面积、负载）在处理来自用户代理的后续内容请求时，便于上游CDN请求路由系统选择下游CDN。预计CDNI请求路由的此类功能可由CDNI工作组指定，并充分利用支持可达性信息动态分布的现有IETF协议（例如，通过利用现有路由协议）或者支持拓扑信息的应用程序级查询（例如，通过利用应用程序层流量优化（ALTO）[RFC5693]）。
The CDNI Metadata interface enables the Distribution system in a Downstream CDN to request CDNI Metadata from an Upstream CDN so that the Downstream CDN can properly process and respond to redirection requests received over the CDNI Request Routing interface and Content Requests received directly from User Agents.
CDNI元数据接口使下游CDN中的分发系统能够从上游CDN请求CDNI元数据，以便下游CDN能够正确处理和响应通过CDNI请求路由接口接收的重定向请求以及直接从用户代理接收的内容请求。
The CDNI Metadata interface is therefore similar to the CDNI Request Routing interface because it is a request/response interface with the potential addition that CDNI Metadata search may have more complex semantics than a straightforward Request Routing redirection request. Therefore, like the CDNI Request Routing interface, the CDNI Metadata interface may be implemented as a WebService using one of the common WebServices methodologies (XML-RPC, HTTP query to a known URI, etc.) or possibly using other existing protocols such as XMPP [RFC6120]. This removes the need for the CDNI working group to define a new protocol for the request/response element of the CDNI Metadata interface.
因此，CDNI元数据接口与CDNI请求路由接口类似，因为它是一个请求/响应接口，可能会增加CDNI元数据搜索可能比直接的请求路由重定向请求具有更复杂的语义。因此，与CDNI请求路由接口一样，CDNI元数据接口可以使用一种常见的Web服务方法（XML-RPC、对已知URI的HTTP查询等）或可能使用其他现有协议（如XMPP[RFC6120]）实现为Web服务。这样就不需要CDNI工作组为CDNI元数据接口的请求/响应元素定义新协议。
The CDNI Logging interface enables details of content distribution and delivery activities to be exchanged between interconnected CDNs -- for example, the exchange of log records related to the delivery of content, similar to the log records recorded in a web server's access log.
CDNI日志接口允许在互连的CDN之间交换内容分发和交付活动的详细信息——例如，与内容交付相关的日志记录的交换，类似于web服务器访问日志中记录的日志记录。
Several protocols already exist that could potentially be used to exchange CDNI logs between interconnected CDNs, including the Simple Network Management Protocol (SNMP), syslog, FTP (and secure variants), HTTP POST, etc.
已经存在几种可能用于在互连CDN之间交换CDNI日志的协议，包括简单网络管理协议（SNMP）、系统日志、FTP（和安全变体）、HTTP POST等。
Distribution of content by a CDN comes with a range of security considerations, such as how to enforce control of access to the content by End Users in line with the CSP policy, or how to trust the logging information generated by the CDN for the purposes of charging the CSP. These security aspects are already dealt with by CDN Providers and CSPs today in the context of standalone CDNs. However, interconnection of CDNs introduces a new set of security considerations by extending the trust model to a chain of trust (i.e., the CSP "trusts" a CDN that "trusts" another CDN). The mechanisms used to mitigate these risks in multi-CDN environments may be similar to those used in the single-CDN case, but their suitability in this more complex environment must be validated.
CDN分发内容时需要考虑一系列安全问题，例如如何根据CSP策略强制控制最终用户对内容的访问，或者如何信任CDN生成的日志信息以向CSP收费。CDN提供商和CSP今天已经在独立CDN的上下文中处理了这些安全方面。然而，CDN的互连通过将信任模型扩展到信任链（即，CSP“信任”一个“信任”另一个CDN的CDN），引入了一组新的安全考虑因素。在多CDN环境中用于缓解这些风险的机制可能与在单个CDN环境中使用的机制类似，但必须验证其在更复杂环境中的适用性。
The interconnection of CDNs may also introduce additional privacy considerations on top of those that apply to the single-CDN case. In a multi-CDN environment, the different CDNs may reside in different legal regimes that require differing privacy requirements to be enforced. Such privacy requirements may impact the granularity of information that can be exchanged across the CDNI interfaces. For example, the Logging system in a Downstream CDN may need to apply some degree of anonymization, obfuscation, or even the complete removal of some fields before exchanging log records containing details of End User deliveries with an Upstream CDN.
除了适用于单个CDN案例的隐私考虑因素外，CDN的互连还可能引入其他隐私考虑因素。在多CDN环境中，不同的CDN可能位于不同的法律制度中，这些法律制度要求执行不同的隐私要求。此类隐私要求可能会影响可通过CDNI接口交换的信息的粒度。例如，下游CDN中的日志记录系统可能需要在与上游CDN交换包含最终用户交付细节的日志记录之前应用某种程度的匿名化、模糊化，甚至完全删除某些字段。
Maintaining the security of the content itself, its associated metadata (including delivery policies), and the CDNs distributing and delivering it, are critical requirements for both CDN Providers and CSPs, and the CDN Interconnection interfaces must provide sufficient mechanisms to maintain the security of the overall system of interconnected CDNs as well as the information (content, metadata, logs, etc.) distributed and delivered through any set of interconnected CDNs.
维护内容本身、相关元数据（包括交付策略）以及分发和交付内容的CDN的安全性是CDN提供商和CSP的关键要求，CDN互连接口必须提供足够的机制来维护整个互连CDN系统的安全性，以及通过任何一组互连CDN分发和交付的信息（内容、元数据、日志等）。
Information exchanged between interconnected CDNs over this interface is of a sensitive nature. A pair of CDNs use this interface to allow bootstrapping of all the other CDNI interfaces, possibly including establishment of the mechanisms for securing these interfaces. Therefore, corruption of that interface may result in corruption of all other interfaces. Using this interface, an Upstream CDN may pre-position or delete content or metadata in a Downstream CDN, a Downstream CDN may provide administrative information to an Upstream CDN, etc. All of these operations require that the peer CDNs are appropriately authenticated and that the confidentiality and integrity of information flowing between them can be ensured.
通过该接口在互连CDN之间交换的信息具有敏感性。一对CDN使用此接口允许引导所有其他CDNI接口，可能包括建立保护这些接口的机制。因此，该接口的损坏可能导致所有其他接口的损坏。使用该接口，上游CDN可以预先定位或删除下游CDN中的内容或元数据，下游CDN可以向上游CDN提供管理信息，所有这些操作都要求对等CDN经过适当的身份验证，并且可以确保它们之间流动的信息的机密性和完整性。
Appropriate levels of authentication and confidentiality must be used in this interface because it allows an Upstream CDN to query the Downstream CDN in order to redirect requests, and conversely, allows the Downstream CDN to influence the Upstream CDN's Request Routing function.
此接口中必须使用适当级别的身份验证和机密性，因为它允许上游CDN查询下游CDN以重定向请求，反之，允许下游CDN影响上游CDN的请求路由功能。
In the absence of appropriate security on this interface, a rogue Upstream CDN could inundate Downstream CDNs with bogus requests or have the Downstream CDN send the rogue Upstream CDN private information. Also, a rogue Downstream CDN could influence the
在该接口上缺乏适当的安全性的情况下，流氓上游CDN可能会用虚假请求淹没下游CDN，或者让下游CDN发送流氓上游CDN私有信息。此外，流氓下游CDN可能会影响
Upstream CDN so the Upstream CDN redirects requests to the rogue Downstream CDN or another Downstream CDN in order to, for example, attract additional delivery revenue.
上游CDN，因此上游CDN将请求重定向到恶意下游CDN或另一个下游CDN，以吸引额外的交付收入。
This interface allows a Downstream CDN to request CDNI Metadata from an Upstream CDN, and therefore the Upstream CDN must ensure that the former is appropriately authenticated before sending the data. Conversely, a Downstream CDN must authenticate an Upstream CDN before requesting metadata to insulate itself from poisoning by rogue Upstream CDNs. The confidentiality and integrity of the information exchanged between the peers must be protected.
此接口允许下游CDN从上游CDN请求CDNI元数据，因此上游CDN必须确保在发送数据之前对前者进行了适当的身份验证。相反，下游CDN必须在请求元数据之前对上游CDN进行身份验证，以使其自身免受流氓上游CDN的毒害。必须保护对等方之间交换的信息的机密性和完整性。
Logging data consists of potentially sensitive information (which End User accessed which media resource, IP addresses of End Users, potential names and subscriber account information, etc.). Confidentiality of this information must be protected as log records are moved between CDNs. This information may also be sensitive from the viewpoint that it can be the basis for charging across CDNs. Therefore, appropriate levels of protection are needed against corruption, duplication, and loss of this information.
日志数据包括潜在的敏感信息（最终用户访问的媒体资源、最终用户的IP地址、潜在名称和订户帐户信息等）。在CDN之间移动日志记录时，必须保护此信息的机密性。该信息也可能是敏感的，因为它可以作为跨CDN计费的基础。因此，需要适当级别的保护，以防止这些信息的腐败、重复和丢失。
The authors would like to thank Andre Beck, Gilles Bertrand, Mark Carlson, Bruce Davie, David Ferguson, Yiu Lee, Kent Leung, Will Li, Kevin Ma, Julien Maisonneuve, Guy Meador, Larry Peterson, Emile Stephan, Oskar van Deventer, Mahesh Viveganandhan, and Richard Woundy for their review comments and contributions to the text.
作者要感谢Andre Beck、Gilles Bertrand、Mark Carlson、Bruce Davie、David Ferguson、Yiu Lee、Kent Leung、Will Li、Kevin Ma、Julien Maisonneuve、Guy Meador、Larry Peterson、Emile Stephan、Oskar van Deventer、Mahesh Viveganandhan和Richard Woundy对本文的评论和贡献。
[ALTO-CDN-USE-CASES] Niven-Jenkins, B., Ed., Watson, G., Bitar, N., Medved, J., and S. Previdi, "Use Cases for ALTO within CDNs", Work in Progress, June 2012.
[ALTO-CDN-用例]Niven Jenkins，B.，Ed.，Watson，G.，Bitar，N.，Medved，J.，和S.Previdi，“CDN中ALTO的用例”，正在进行的工作，2012年6月。
[ALTO-Charter] "IETF ALTO WG Charter", <http://datatracker.ietf.org/wg/alto/charter/>.
[ALTO章程]“IETF ALTO WG章程”<http://datatracker.ietf.org/wg/alto/charter/>.
[CDNI-EXPERIMENTS] Bertrand, G., Ed., Le Faucheur, F., and L. Peterson, "Content Distribution Network Interconnection (CDNI) Experiments", Work in Progress, February 2012.
[CDNI-实验]Bertrand，G.，Ed.，Le Faucheur，F.，和L.Peterson，“内容分发网络互连（CDNI）实验”，正在进行的工作，2012年2月。
[CDNI-USE-CASES] Bertrand, G., Ed., Emile, S., Burbridge, T., Eardley, P., Ma, K., and G. Watson, "Use Cases for Content Delivery Network Interconnection", Work in Progress, August 2012.
[CDNI-用例]Bertrand，G.，Ed.，Emile，S.，Burbridge，T.，Eardley，P.，Ma，K.，和G.Watson，“内容交付网络互连的用例”，正在进行的工作，2012年8月。
[DECADE-Charter] "IETF DECADE WG Charter", <http://datatracker.ietf.org/wg/decade/charter/>.
[十年宪章]“IETF十年工作组宪章”<http://datatracker.ietf.org/wg/decade/charter/>.
[P2PRG-CDNI] Davie, B. and F. Le Faucheur, "Interconnecting CDNs aka 'Peering Peer-to-Peer'", March 2010, <http://www.ietf.org/proceedings/77/slides/P2PRG-2.pdf>.
[P2PRG-CDNI]Davie，B.和F.Le Faucheur，“互连CDN，又称“对等网络”，2010年3月<http://www.ietf.org/proceedings/77/slides/P2PRG-2.pdf>.
[PPSP-Charter] "IETF PPSP WG Charter", <http://datatracker.ietf.org/wg/ppsp/charter/>.
[PPSP章程]“IETF PPSP工作组章程”<http://datatracker.ietf.org/wg/ppsp/charter/>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", RFC 3040, January 2001.
[RFC3040]Cooper，I.，Melve，I.，和G.Tomlinson，“互联网Web复制和缓存分类法”，RFC 3040，2001年1月。
[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月。
[RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content Internetworking (CDI) Scenarios", RFC 3570, July 2003.
[RFC3570]Rzewski，P.，Day，M.，和D.Gilletti，“内容互联网（CDI）场景”，RFC 35702003年7月。
[RFC5023] Gregorio, J., Ed., and B. de hOra, Ed., "The Atom Publishing Protocol", RFC 5023, October 2007.
[RFC5023]Gregorio，J.，Ed.，和B.de hOra，Ed.，“原子发布协议”，RFC 5023，2007年10月。
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, October 2009.
[RFC5693]Seedorf，J.和E.Burger，“应用层流量优化（ALTO）问题陈述”，RFC 5693，2009年10月。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6120]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：核心”，RFC61202011年3月。
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, October 2011.
[RFC6390]Clark，A.和B.Claise，“考虑新性能指标开发的指南”，BCP 170，RFC 63902011年10月。
[TAXONOMY] Pathan, A. and R. Buyya, "A Taxonomy and Survey of Content Delivery Networks", 2007, <http://www.cloudbus.org/reports/CDN-Taxonomy.pdf>.
[TAXONOMY]Pathan，A.和R.Buyya，“内容交付网络的分类和调查”，2007年<http://www.cloudbus.org/reports/CDN-Taxonomy.pdf>.
This section expands on how CDNI interfaces can reuse and leverage existing protocols before describing each CDNI interface individually and highlighting example candidate protocols that could be considered for reuse or leveraging to implement the CDNI interfaces. However, the options discussed here are purely examples and do not present any consensus on protocols to be used later on.
在单独描述每个CDNI接口之前，本节将详细介绍CDNI接口如何重用和利用现有协议，并重点介绍可考虑重用或利用以实现CDNI接口的候选协议示例。然而，此处讨论的选项仅为示例，并未就稍后使用的协议达成任何共识。
The CDNI Control interface allows the Control system in interconnected CDNs to communicate. The exact inter-CDN control functionality required to be supported by the CDNI Control interface is less well defined than the other three CDNI interfaces at this time.
CDNI控制接口允许互连CDN中的控制系统进行通信。目前，CDNI控制接口需要支持的确切的CDN间控制功能的定义不如其他三个CDNI接口好。
However, as discussed in Section 3, the CDNI Control interface may be required to support functionality similar to the following:
但是，如第3节所述，可能需要CDNI控制接口来支持类似以下功能：
o Allow an Upstream CDN and Downstream CDN to establish, update, or terminate their CDNI interconnection.
o 允许上游CDN和下游CDN建立、更新或终止其CDNI互连。
o Allow bootstrapping of the other CDNI interfaces (e.g., protocol address discovery and establishment of security associations).
o 允许引导其他CDNI接口（例如，协议地址发现和建立安全关联）。
o Allow configuration of the other CDNI interfaces (e.g., Upstream CDN specifies information to be reported through the CDNI Logging interface).
o 允许配置其他CDNI接口（例如，上游CDN指定通过CDNI日志记录接口报告的信息）。
o Allow the Downstream CDN to communicate static information about its delivery capabilities, resources, and policies.
o 允许下游CDN传递有关其交付能力、资源和策略的静态信息。
o Allow bootstrapping of the interface between CDNs for content acquisition (even if that interface itself is outside the scope of the CDNI work).
o 允许引导CDN之间的接口以获取内容（即使该接口本身不在CDNI工作范围内）。
It is expected that for the Control interface, as for the other CDNI interfaces, existing protocols can be reused or leveraged. Those will be considered once the requirements for the Control interface have been refined.
对于控制接口，与其他CDNI接口一样，可以重用或利用现有协议。一旦控制接口的要求得到完善，将考虑这些要求。
The CDNI Request Routing interface enables a Request Routing function in an Upstream CDN to query a Request Routing function in a Downstream CDN to determine if the Downstream CDN is able (and willing) to accept the delegated Content Request and to allow the Downstream CDN to control what the upstream Request Routing function should return to the User Agent in the redirection message.
CDNI请求路由接口使上游CDN中的请求路由功能能够查询下游CDN中的请求路由功能，以确定下游CDN是否能够（并且愿意）接受委托的内容请求，并允许下游CDN控制上游请求路由功能应在重定向消息中返回给用户代理的内容。
Therefore, the CDNI Request Routing interface needs to offer a mechanism for an Upstream CDN to issue a "Redirection Request" to a Downstream CDN. The Request Routing interface needs to be able to support scenarios where the initial User Agent request to the Upstream CDN is received over DNS as well as over a content-specific application protocol (e.g., HTTP, the Real Time Streaming Protocol (RTSP), the Real Time Messaging Protocol (RTMP), etc.).
因此，CDNI请求路由接口需要为上游CDN提供向下游CDN发出“重定向请求”的机制。请求路由接口需要能够支持通过DNS以及通过特定于内容的应用协议（例如HTTP、实时流协议（RTSP）、实时消息协议（RTMP）等）接收到向上游CDN的初始用户代理请求的场景。
Therefore, a Redirection Request is expected to contain information such as:
因此，重定向请求应包含以下信息：
o The protocol (e.g., DNS, HTTP) over which the Upstream CDN received the initial User Agent request.
o 上行CDN通过其接收初始用户代理请求的协议（如DNS、HTTP）。
o Additional details of the User Agent request that are required to perform effective Request Routing by the Downstream CDN. For DNS, this would typically be the IP address of the DNS resolver making the request on behalf of the User Agent. For requests received over content-specific application protocols, the Redirection Request could contain significantly more information related to the original User Agent request but at a minimum is expected to include the User Agent's IP address, the equivalent of the HTTP Host header, and the equivalent of the HTTP abs_path as defined in [RFC2616].
o 下游CDN执行有效请求路由所需的用户代理请求的其他详细信息。对于DNS，这通常是代表用户代理发出请求的DNS解析程序的IP地址。对于通过特定于内容的应用程序协议接收的请求，重定向请求可能包含与原始用户代理请求相关的更多信息，但至少应包括用户代理的IP地址、HTTP主机头的等效值以及中定义的HTTP abs_路径的等效值[RFC2616]。
It should be noted that the CDNI architecture needs to consider that a Downstream CDN may receive requests from User Agents without first receiving a Redirection Request from an Upstream CDN for the corresponding User Agent request because, for example:
应该注意的是，CDNI体系结构需要考虑下游CDN可以从用户代理接收请求，而不首先接收来自上游CDN的针对相应用户代理请求的重定向请求，因为例如：
o User Agents (or DNS resolvers) may cache DNS or application responses from Request Routers.
o 用户代理（或DNS解析程序）可以缓存来自请求路由器的DNS或应用程序响应。
o Responses to Redirection Requests over the Request Routing interface may be cacheable.
o 通过请求路由接口对重定向请求的响应可能是可缓存的。
o Some CDNs may rely on simple coarse policies, e.g., CDN B agrees to always serve CDN A's delegated redirection requests, in which case the necessary redirection details are exchanged out of band (of the CDNI interfaces), e.g., configured.
o 一些CDN可能依赖于简单的粗略策略，例如，CDN B同意始终为CDN A的委托重定向请求提供服务，在这种情况下，必要的重定向细节在带外交换（CDNI接口），例如配置。
On receiving a Redirection Request, the Downstream CDN will use the information provided in the request to determine if it is able (and willing) to accept the delegated Content Request and needs to return the result of its decision to the Upstream CDN.
在接收到重定向请求时，下游CDN将使用请求中提供的信息来确定其是否能够（并且愿意）接受委托内容请求，并且需要将其决定的结果返回给上游CDN。
Thus, a Redirection Response from the Downstream CDN is expected to contain information such as:
因此，来自下游CDN的重定向响应预期包含如下信息：
o Status code indicating acceptance or rejection (possibly with accompanying reasons).
o 表示接受或拒绝的状态代码（可能附带原因）。
o Information to allow redirection by the Upstream CDN. In the case of DNS-based request routing, this is expected to include the equivalent of a DNS record(s) (e.g., a CNAME) that the Upstream CDN should return to the requesting DNS resolver. In the case of application-based request routing, this is expected to include the information necessary to construct the application-specific redirection response(s) to return to the requesting User Agent. For HTTP requests from User Agents, this could include a URI that the Upstream CDN could return in an HTTP 3xx response.
o 允许上游CDN重定向的信息。在基于DNS的请求路由的情况下，这预计将包括上游CDN应返回到请求DNS解析程序的DNS记录（例如CNAME）的等价物。在基于应用程序的请求路由的情况下，这应该包括构造特定于应用程序的重定向响应以返回到请求用户代理所需的信息。对于来自用户代理的HTTP请求，这可能包括上游CDN可以在HTTP 3xx响应中返回的URI。
The CDNI Request Routing interface is therefore a fairly straightforward request/response interface and could be implemented over any number of request/response protocols. For example, it may be implemented as a WebService using one of the common WebServices methodologies (XML-RPC, HTTP query to a known URI, etc.). This removes the need for the CDNI working group to define a new protocol for the request/response element of the CDNI Request Routing interface. Thus, the CDNI working group would be left only with the task of specifying:
因此，CDNI请求路由接口是一个相当简单的请求/响应接口，可以通过任意数量的请求/响应协议实现。例如，可以使用一种常见的Web服务方法（XML-RPC、对已知URI的HTTP查询等）将其实现为Web服务。这样就不需要CDNI工作组为CDNI请求路由接口的请求/响应元素定义新协议。因此，CDNI工作组只剩下具体规定以下内容的任务：
o The recommended request/response protocol to use along with any additional semantics and procedures that are specific to the CDNI Request Routing interface (e.g., handling of malformed requests/ responses).
o 建议使用的请求/响应协议以及特定于CDNI请求路由接口的任何附加语义和过程（例如，处理格式错误的请求/响应）。
o The syntax (i.e., representation/encoding) of the redirection requests and responses.
o 重定向请求和响应的语法（即表示/编码）。
o The semantics (i.e., meaning and expected contents) of the redirection requests and responses.
o 重定向请求和响应的语义（即含义和预期内容）。
Additionally, as discussed in Section 3, the CDNI Request Routing interface is also expected to enable a Downstream CDN to provide to the Upstream CDN (static or dynamic) information (e.g., resources, footprint, load) to facilitate selection of the Downstream CDN by the Upstream CDN Request Routing system when processing subsequent Content Requests from User Agents. It is expected that such functionality of the CDNI request routing could be specified by the CDNI working group with significant leveraging of existing IETF protocols supporting the dynamic distribution of reachability information (for example, by leveraging existing routing protocols) or supporting application-level queries for topological information (for example, by leveraging ALTO).
此外，如第3节所述，CDNI请求路由接口还应能够使下游CDN向上游CDN提供（静态或动态）信息（例如，资源、占地面积、负载）在处理来自用户代理的后续内容请求时，便于上游CDN请求路由系统选择下游CDN。预计CDNI请求路由的此类功能可由CDNI工作组指定，并充分利用支持可达性信息动态分布的现有IETF协议（例如，通过利用现有路由协议）或者支持拓扑信息的应用程序级查询（例如，利用ALTO）。
The CDNI Metadata interface enables the Distribution system in a Downstream CDN to obtain CDNI Metadata from an Upstream CDN so that the Downstream CDN can properly process and respond to:
CDNI元数据接口使下游CDN中的分发系统能够从上游CDN获取CDNI元数据，以便下游CDN能够正确处理和响应：
o Redirection Requests received over the CDNI Request Routing interface.
o 通过CDNI请求路由接口接收的重定向请求。
o Content Requests received directly from User Agents.
o 直接从用户代理接收的内容请求。
The CDNI Metadata interface needs to offer a mechanism for an Upstream CDN to:
CDNI元数据接口需要为上游CDN提供一种机制，以便：
o Distribute/update/remove CDNI Metadata to a Downstream CDN.
o 向下游CDN分发/更新/删除CDNI元数据。
and/or to allow a Downstream CDN to:
和/或允许下游CDN：
o Make direct requests for CDNI Metadata objects.
o 直接请求CDNI元数据对象。
o Make recursive requests for CDNI Metadata -- for example, to enable a Downstream CDN to walk down a tree of objects with inter-object relationships.
o 对CDNI元数据进行递归请求——例如，使下游CDN能够遍历具有对象间关系的对象树。
The CDNI Metadata interface is therefore similar to the CDNI Request Routing interface because it is a request/response interface with the potential addition that CDNI Metadata search may have more complex semantics than a straightforward Request Routing redirection request. Therefore, like the CDNI Request Routing interface, the CDNI Metadata interface may be implemented as a WebService using one of the common WebServices methodologies (XML-RPC, HTTP query to a known URI, etc.) or possibly using other existing protocols such as XMPP [RFC6120]. This removes the need for the CDNI working group to define a new protocol for the request/response element of the CDNI Metadata interface.
因此，CDNI元数据接口与CDNI请求路由接口类似，因为它是一个请求/响应接口，可能会增加CDNI元数据搜索可能比直接的请求路由重定向请求具有更复杂的语义。因此，与CDNI请求路由接口一样，CDNI元数据接口可以使用一种常见的Web服务方法（XML-RPC、对已知URI的HTTP查询等）或可能使用其他现有协议（如XMPP[RFC6120]）实现为Web服务。这样就不需要CDNI工作组为CDNI元数据接口的请求/响应元素定义新协议。
Thus, the CDNI working group would be left only with the task of specifying:
因此，CDNI工作组只剩下具体规定以下内容的任务：
o The recommended request/response protocol to use along with any additional semantics that are specific to the CDNI Metadata interface (e.g., handling of malformed requests/responses).
o 建议使用的请求/响应协议以及特定于CDNI元数据接口的任何附加语义（例如，处理格式错误的请求/响应）。
o The syntax (i.e., representation/encoding) of the CDNI Metadata objects that will be exchanged over the interface.
o 将通过接口交换的CDNI元数据对象的语法（即表示/编码）。
o The semantics (i.e., meaning and expected contents) of the individual properties of a Metadata object.
o 元数据对象的各个属性的语义（即含义和预期内容）。
o How the relationships between different CDNI Metadata objects are represented.
o 如何表示不同CDNI元数据对象之间的关系。
The CDNI Logging interface enables details of content distribution and delivery activities to be exchanged between interconnected CDNs, such as log records related to the delivery of content (similar to the log records recorded in a web server's access log).
CDNI日志接口允许在互连CDN之间交换内容分发和交付活动的详细信息，例如与内容交付相关的日志记录（类似于web服务器访问日志中记录的日志记录）。
Within CDNs today, log records are used for a variety of purposes. Specifically, CDNs use logs to generate Call Data Records (CDRs) for passing to billing and payment systems and to real-time (and near real-time) analytics systems. Such applications place requirements on the CDNI Logging interface to support guaranteed and timely delivery of log messages between interconnected CDNs. It may also be necessary to be able to prove the integrity of received log messages.
在今天的CDN中，日志记录用于各种目的。具体而言，CDN使用日志生成呼叫数据记录（CDR），以传递给计费和支付系统以及实时（和近实时）分析系统。此类应用程序对CDNI日志接口提出了要求，以支持互连CDN之间有保证且及时的日志消息传递。还可能需要能够证明接收到的日志消息的完整性。
Several protocols already exist that could potentially be used to exchange CDNI logs between interconnected CDNs, including SNMP traps, syslog, FTP, HTTP POST, etc., although it is likely that some of the candidate protocols may not be well suited to meet all the requirements of CDNI. For example, SNMP traps pose scalability concerns, and SNMP does not support guaranteed delivery of traps and therefore could result in log records being lost and the consequent CDRs and billing records for that content delivery not being produced, as well as that content delivery being invisible to any analytics platforms.
已经存在几种可能用于在互连CDN之间交换CDNI日志的协议，包括SNMP陷阱、syslog、FTP、HTTP POST等，尽管某些候选协议可能不太适合满足CDNI的所有要求。例如，SNMP陷阱会带来可伸缩性问题，并且SNMP不支持陷阱的保证交付，因此可能会导致日志记录丢失，并且不会生成该内容交付的后续CDR和计费记录，并且任何分析平台都看不到该内容交付。
Although it is not necessary to define a new protocol for exchanging logs across the CDNI Logging interface, the CDNI working group would still need to specify:
虽然没有必要定义一个新的协议来跨CDNI日志接口交换日志，但CDNI工作组仍需要指定：
o The recommended protocol to use.
o 建议使用的协议。
o A default set of log fields and of their syntax and semantics. Today there is no standard set of common log fields across different content delivery protocols, and in some cases there is not even a standard set of log field names and values for different implementations of the same delivery protocol.
o 日志字段及其语法和语义的默认集合。如今，在不同的内容交付协议中没有标准的通用日志字段集，在某些情况下，对于同一交付协议的不同实现，甚至没有标准的日志字段名称和值集。
o A default set of conditions that trigger log records to be generated.
o 触发要生成的日志记录的默认条件集。
This section records related information that was produced as part of defining the CDNI problem statement.
本节记录了作为定义CDNI问题陈述的一部分而产生的相关信息。
Listed below are aspects of content delivery that the authors propose be kept outside of the scope of the CDNI working group:
以下列出了作者建议不在CDNI工作组范围内的内容交付方面：
o The interface between the Content Service Provider and the Authoritative CDN (i.e., the Upstream CDN contracted by the CSP for delivery by this CDN or by its Downstream CDNs).
o 内容服务提供商与权威CDN之间的接口（即，由CSP签订的由该CDN或其下游CDN交付的上游CDN）。
o The delivery interface between the delivering CDN Surrogate and the User Agent, such as streaming protocols.
o 交付CDN代理和用户代理之间的交付接口，如流协议。
o The request interface between the User Agent and the Request Routing system of a given CDN. Existing IETF protocols (e.g., HTTP, RTSP, DNS) are commonly used by User Agents to request content from a CDN and by CDN Request Routing systems to redirect the User Agent requests. The CDNI working group need not define new protocols for this purpose. Note, however, that the CDNI control plane interface may indirectly affect some of the information exchanged through the request interface (e.g., URI).
o 用户代理和给定CDN的请求路由系统之间的请求接口。现有IETF协议（例如HTTP、RTSP、DNS）通常由用户代理从CDN请求内容，并由CDN请求路由系统重定向用户代理请求。CDNI工作组无需为此目的定义新的协议。然而，请注意，CDNI控制平面接口可能会间接影响通过请求接口（例如URI）交换的一些信息。
o The content acquisition interface between CDNs (i.e., the data plane interface for actual delivery of a piece of content from one CDN to the other). This is expected to use existing protocols such as HTTP or protocols defined in other forums for content acquisition between an origin server and a CDN (e.g., HTTP-based C2 reference point of the Alliance for Telecommunications Industry Solutions IPTV Interoperability Forum Content on Demand service
o CDN之间的内容获取接口（即，用于从一个CDN向另一个CDN实际交付内容的数据平面接口）。这将使用现有协议，如HTTP或其他论坛中定义的协议，用于源服务器和CDN之间的内容获取（例如，电信行业解决方案联盟IPTV互操作性论坛内容点播服务的基于HTTP的C2参考点）
(ATIS IIF CoD)). The CDN Interconnection problem space described in this document may therefore only concern itself with the agreement/negotiation aspects of which content acquisition protocol is to be used between two interconnected CDNs in view of facilitating interoperability.
（ATIS IIF CoD）。因此，本文档中描述的CDN互连问题空间可能只涉及两个互连CDN之间使用内容获取协议的协议/协商方面，以促进互操作性。
o End User/User Agent Authentication. End User/User Agent authentication and authorization are the responsibility of the Content Service Provider.
o 最终用户/用户代理身份验证。最终用户/用户代理身份验证和授权由内容服务提供商负责。
o Content preparation, including encoding and transcoding. The CDNI architecture aims at allowing distribution across interconnected CDNs of content treated as opaque objects. Interpretation and processing of the objects, as well as optimized delivery of these objects by the Surrogate to the End User, are outside the scope of CDNI.
o 内容准备，包括编码和转码。CDNI体系结构旨在允许跨互联CDN分发被视为不透明对象的内容。对象的解释和处理，以及代理向最终用户优化交付这些对象，不在CDNI的范围之内。
o Digital Rights Management (DRM). DRM is an end-to-end issue between a content protection system and the User Agent.
o 数字版权管理（DRM）。DRM是内容保护系统和用户代理之间的端到端问题。
o Applications consuming CDNI logs (e.g., charging, analytics, reporting, ...).
o 使用CDNI日志的应用程序（例如，收费、分析、报告等）。
o Internal CDN interfaces and protocols (i.e., interfaces and protocols within one CDN).
o 内部CDN接口和协议（即一个CDN内的接口和协议）。
o Scalability of individual CDNs. While scalability of the CDNI interfaces/approach is in scope, how an individual CDN scales is out of scope.
o 单个CDN的可扩展性。虽然CDNI接口/方法的可伸缩性在范围内，但单个CDN的扩展方式超出了范围。
o Actual algorithms for selection of CDNs or Surrogates by Request Routing systems (however, some specific parameters required as input to these algorithms may be in scope when they need to be communicated across CDNs).
o 请求路由系统选择CDN或代理的实际算法（但是，当需要跨CDN进行通信时，作为这些算法输入的一些特定参数可能在范围内）。
o Surrogate algorithms. For example, caching algorithms and content acquisition methods are outside the scope of the CDNI work. Content management (e.g., Content Deletion) as it relates to CDNI content management policies is in scope, but the internal algorithms used by a cache to determine when to no longer cache an item of Content (in the absence of any specific metadata to the contrary) is out of scope.
o 代理算法。例如，缓存算法和内容获取方法超出了CDNI的工作范围。与CDNI内容管理策略相关的内容管理（例如，内容删除）在范围内，但缓存用于确定何时不再缓存内容项（在没有任何相反的特定元数据的情况下）的内部算法不在范围内。
o Element management interfaces.
o 元素管理接口。
o Commercial, business, and legal aspects related to the interconnections of CDNs.
o 与CDN互连相关的商业、商业和法律方面。
B.2. Relationship to Relevant IETF Working Groups and IRTF Research Groups
B.2. 与相关IETF工作组和IRTF研究组的关系
As stated in the ALTO working group charter [ALTO-Charter]:
如ALTO工作组章程[ALTO章程]所述：
The Working Group will design and specify an Application-Layer Traffic Optimization (ALTO) service that will provide applications with information to perform better-than-random initial peer selection. ALTO services may take different approaches at balancing factors such as maximum bandwidth, minimum cross-domain traffic, lowest cost to the user, etc. The working group will consider the needs of BitTorrent, tracker-less P2P, and other applications, such as content delivery networks (CDN) and mirror selection.
该工作组将设计并指定一个应用层流量优化（ALTO）服务，该服务将为应用程序提供信息，以比随机初始对等选择更好地执行。阿尔托服务可能采取不同的方法来平衡诸如最大带宽、最小跨域流量、用户最低成本等因素。工作组将考虑BitTorrent、Traceer-Enter P2P和其他应用（如内容分发网络（CDN）和镜像选择”的需求。
In particular, the ALTO service can be used by a CDN Request Routing system to improve its selection of a CDN Surrogate to serve a particular User Agent request (or to serve a request from another Surrogate). [ALTO-CDN-USE-CASES] describes a number of use cases for a CDN to be able to obtain network topology and cost information from an ALTO server(s) and discusses how CDN Request Routing could be used as an integration point of ALTO into CDNs. It is possible that the ALTO service could be used in the same manner in a multi-CDN environment based on CDN Interconnection. For example, an Upstream CDN may take advantage of the ALTO service in its decision for selecting a Downstream CDN to which a user request should be delegated.
具体而言，CDN请求路由系统可以使用ALTO服务来改进其对CDN代理的选择，以服务于特定用户代理请求（或服务于来自另一代理的请求）。[ALTO-CDN-USE-CASES]描述了CDN能够从ALTO服务器获取网络拓扑和成本信息的许多用例，并讨论了如何将CDN请求路由用作ALTO到CDN的集成点。在基于CDN互连的多CDN环境中，ALTO服务可能以相同的方式使用。例如，上游CDN可在其选择用户请求应被委托到的下游CDN的决策中利用ALTO服务。
However, the current work of ALTO is complementary to and does not overlap with the work described in this document because the integration between ALTO and a CDN is an internal decision for a specific CDN and is therefore out of scope for the CDNI working group. One area for further study is whether additional information should be provided by an ALTO service to facilitate CDNI CDN selection.
然而，ALTO目前的工作是对本文件所述工作的补充，并不与本文件所述工作重叠，因为ALTO与CDN之间的整合是特定CDN的内部决定，因此不在CDNI工作组的范围之内。需要进一步研究的一个领域是，ALTO服务是否应提供额外信息，以促进CDNI CDN的选择。
The DECADE working group [DECADE-Charter] is addressing the problem of reducing traffic on the last-mile uplink, as well as backbone and transit links caused by peer-to-peer (P2P) streaming and file-sharing applications. It addresses the problem by enabling an application endpoint to make content available from an in-network storage service and by enabling other application endpoints to retrieve the content from there.
十年工作组[十年宪章]正在解决减少最后一英里上行链路上的流量以及对等（P2P）流媒体和文件共享应用程序造成的主干和传输链路的问题。它通过使应用程序端点能够从网络存储服务中获取内容，并使其他应用程序端点能够从网络存储服务中检索内容来解决此问题。
Exchanging data through the in-network storage service in this manner, instead of through direct communication, provides significant gain where:
通过网络存储服务以这种方式（而不是通过直接通信）交换数据，可在以下情况下获得显著的收益：
o The network capacity/bandwidth from the in-network storage service to the application endpoint significantly exceeds the capacity/ bandwidth from application endpoint to application endpoint (e.g., because of an end-user uplink bottleneck); and
o 从网络内存储服务到应用程序端点的网络容量/带宽大大超过了从应用程序端点到应用程序端点的容量/带宽（例如，由于最终用户上行链路瓶颈）；和
o The content is to be accessed by multiple instances of application endpoints (e.g., as is typically the case for P2P applications).
o 内容将由应用程序端点的多个实例访问（例如，P2P应用程序的典型情况）。
While, as is the case for any other data distribution application, the DECADE architecture and mechanisms could potentially be used for exchange of CDNI control plane information via an in-network storage service (as opposed to directly between the entities terminating the CDNI interfaces in the neighbor CDNs), we observe that:
尽管与任何其他数据分发应用程序一样，十年体系结构和机制可能用于通过网络内存储服务交换CDNI控制平面信息（而不是直接在终止相邻CDN中CDNI接口的实体之间），但我们观察到：
o CDNI would operate as a "Content Distribution Application" from the DECADE viewpoint (i.e., would operate on top of DECADE).
o 从十年的角度来看，CDNI将作为“内容分发应用程序”运行（即，将在十年之上运行）。
o There do not seem to be obvious benefits in integrating the DECADE control plane responsible for signaling information relating to control of the in-network storage service itself, and the CDNI control plane responsible for application-specific CDNI interactions (such as exchange of CDNI Metadata, CDNI request redirection, and transfer of CDNI logging information).
o 集成负责与网络内存储服务本身的控制相关的信令信息的十年控制平面和负责特定于应用程序的CDNI交互的CDNI控制平面似乎没有明显的好处（如交换CDNI元数据、CDNI请求重定向和传输CDNI日志信息）。
o There would typically be limited benefits in making use of a DECADE in-network storage service because the CDNI interfaces are expected to be terminated by a very small number of CDNI clients (if not one) in each CDN, and the CDNI clients are expected to benefit from high bandwidth/capacity when communicating directly to each other (at least as high as if they were communicating via an in-network storage server).
o 在网络存储服务中使用十年的好处通常是有限的，因为每个CDN中的CDNI接口预期会被非常少的CDNI客户端（如果不是一个）终止，并且CDNI客户端预期会在直接相互通信时受益于高带宽/容量（至少与他们通过网络存储服务器进行通信一样高）。
The DECADE in-network storage architecture and mechanisms may theoretically be used for the acquisition of the content objects themselves between interconnected CDNs. It is not expected that this would have obvious benefits in typical situations where a content object is acquired only once from an Upstream CDN to a Downstream CDN (and then distributed as needed inside the Downstream CDN). But it might have benefits in some particular situations. Since the acquisition protocol between CDNs is outside the scope of the CDNI work, this question is left for further study.
网络存储体系结构和机制的十年发展理论上可用于在互连CDN之间获取内容对象本身。在从上游CDN到下游CDN（然后根据需要在下游CDN内部分发）仅获取一次内容对象的典型情况下，这不会有明显的好处。但在某些特定情况下，它可能会有好处。由于CDN之间的采集协议不属于CDNI的工作范围，因此这个问题有待进一步研究。
The DECADE in-network storage architecture and mechanisms may potentially also be used within a given CDN for the distribution of the content objects themselves among Surrogates of that CDN. Since the CDNI work does not concern itself with operation within a CDN, this question is left for further study.
网络存储体系结构和机制中的十年也可能在给定CDN中用于在该CDN的代理中分发内容对象本身。由于CDNI工作本身并不涉及CDN内的操作，因此这个问题有待进一步研究。
Therefore, the work of DECADE may be complementary to, but does not overlap with, the CDNI work described in this document.
因此，“十年”的工作可能是对本文件所述CDNI工作的补充，但不会重叠。
As stated in the PPSP working group charter [PPSP-Charter]:
如PPSP工作组章程[PPSP章程]所述：
The Peer-to-Peer Streaming Protocol (PPSP) working group develops two signaling and control protocols for a peer-to-peer (P2P) streaming system for transmitting live and time-shifted media content with near real-time delivery requirements...
点对点流媒体协议（PPSP）工作组为点对点（P2P）流媒体系统开发了两种信令和控制协议，用于传输实时和时移媒体内容，具有近实时传输要求。。。
... The PPSP working group designs a protocol for signaling and control between trackers and peers (the PPSP "tracker protocol") and a signaling and control protocol for communication among the peers (the PPSP "peer protocol"). The two protocols enable peers to receive streaming data within the time constraints required by specific content items.
... PPSP工作组设计了追踪者和对等方之间的信令和控制协议（“PPSP追踪协议”）和对等方之间的通信信令和控制协议（“PPSP对等协议”）。这两个协议使对等方能够在特定内容项所需的时间限制内接收流数据。
Therefore, PPSP is concerned with the distribution of the streamed content itself along with the necessary signaling and control required to distribute the content. As such, it could potentially be used for the acquisition of streamed content across interconnected CDNs. But since the acquisition protocol is outside the scope of the work proposed for CDNI, we leave this for further study. Also, because of its streaming nature, PPSP is not seen as applicable to the distribution and control of the CDNI control plane and CDNI data representations.
因此，PPSP关注流式内容本身的分发以及分发内容所需的必要信令和控制。因此，它有可能用于跨互连CDN获取流式内容。但由于采集协议不在CDNI的工作范围内，我们将其留作进一步研究。此外，由于其流性质，PPSP不适用于CDNI控制平面和CDNI数据表示的分布和控制。
Therefore, the work of PPSP may be complementary to, but does not overlap with, the work described in this document for CDNI.
因此，PPSP的工作可能是对CDNI本文件所述工作的补充，但不会重叠。
Some information on CDN Interconnection motivations and technical issues were presented in the P2P research group at IETF 77. The presentation can be found in [P2PRG-CDNI].
IETF 77上的P2P研究小组介绍了一些关于CDN互连动机和技术问题的信息。该演示文稿可在[P2PRG-CDNI]中找到。
Authors' Addresses
作者地址
Ben Niven-Jenkins Velocix (Alcatel-Lucent) 326 Cambridge Science Park Milton Road, Cambridge CB4 0WG UK
Ben Niven Jenkins Velocix（阿尔卡特朗讯）326剑桥科技园弥尔顿路，剑桥CB4 0WG英国
EMail: ben@velocix.com
EMail: ben@velocix.com
Francois Le Faucheur Cisco Systems Greenside, 400 Avenue de Roumanille Sophia Antipolis 06410 France
弗朗索瓦·勒·福彻思科系统公司绿边，法国索菲亚·安提波利斯大道400号，邮编：06410
Phone: +33 4 97 23 26 19
EMail: flefauch@cisco.com
Phone: +33 4 97 23 26 19
EMail: flefauch@cisco.com
Nabil Bitar Verizon 60 Sylvan Road Waltham, MA 02145 USA
美国马萨诸塞州沃尔瑟姆西尔文路60号纳比尔比塔威瑞森02145
EMail: nabil.n.bitar@verizon.com
EMail: nabil.n.bitar@verizon.com