RFC6707：Content Distribution Network Interconnection (CDNI) Problem Statement，September 2012
梗概
内容分发网络 (Content Delivery Networks，CDN) 为可缓存的内容提供了许多好处：降低了交付成本，提高了最终用户的体验质量，并提高了交付的稳健性。由于这些原因，它们经常用于大规模内容分发。因此，现有的 CDN 提供商正在扩大其基础设施，许多网络服务提供商 (Network Service Providers，NSP) 正在部署自己的 CDN。通常希望可以将指定的内容项传送给最终用户，而不管该最终用户的位置或连接网络如何。这是互连独立 CDN 的动机，因此它们可以作为开放的内容分发基础设施进行互操作，以便从内容服务提供商 (Content Service Providers，CSP) 到最终用户的端到端内容分发。然而，目前不存在促进这种 CDN 互连的标准或开放规范。
本文档的目标是为 IETF CDNI（CDN Interconnection，CDN互连）工作组概述 CDN 互连的问题领域。
本备忘录的状态
本文档不是 Internet Standards Track 规范；它是为了信息目的而发布的。
本文档是 Internet 工程任务组 (Internet Engineering Task Force，IETF) 的产品。它代表了 IETF 社区的共识。它已接受公众审查，并已被互联网工程指导小组 (Internet Engineering Steering Group，IESG) 批准出版。并非所有 IESG 批准的文件都适用于任何级别的互联网标准；请参阅 RFC 5741 的第 2 节。
有关本文档的当前状态、任何勘误以及如何提供反馈的信息，请访问 http://www.rfc-editor.org/info/rfc6707。
版权声明
版权所有 (c) 2012 IETF Trust 和确定为文档作者的人员。版权所有。
本文档受 BCP 78 和 IETF Trust 的与 IETF 文档相关的法律规定 (http://trustee.ietf.org/license-info) 的约束，在本文档发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本，并且不提供如简化 BSD 许可中所述的保证。
1、 介绍
通过 Internet 传送的视频和多媒体内容的数量正在迅速增加，并且预计在未来将继续增加。面对这种增长，内容分发网络 (CDN) 为可缓存内容提供了许多好处：降低了交付成本、提高了最终用户 (End Users，EU) 的体验质量以及提高了交付的稳健性。由于这些原因，CDN 经常用于大规模内容分发。因此，现有的 CDN 提供商正在扩大其基础设施，许多网络服务提供商 (NSP) 正在部署自己的 CDN。
通常希望可以将指定的内容项传送到 EU，而不管该 EU 的位置或它们所连接的网络。然而，负责交付指定内容的指定 CDN 可能没有足够接近EU当前位置或连接网络的覆盖范围，或者可能没有必要的资源来实现用户体验和成本效益CDN 基础设施将允许。这是互连独立 CDN 的动机，以便可以利用其集体 CDN 足迹和资源将内容从内容服务提供商 (CSP) 端到端交付到 EU。例如，CSP 可以与“权威”CDN 提供商就内容分发签订合同，而权威 CDN 提供商可以与一个或多个下游 CDN 提供商签订合同，代表权威机构分发和交付部分或全部内容。CDN 提供商。
典型的端到端内容分发场景将涉及以下业务部署：
* EU与其 CSP 之间的业务部署，授权EU访问 CSP 控制的内容项目。
* CSP 与“权威”CDN 提供商之间的业务部署，其中 CSP 要求 CDN 提供商代表 CSP 执行内容分发。
* 权威 CDN 提供商与另一个（或其他）CDN 之间的业务部署，其中权威 CDN 可以将某些内容分发请求的实际服务委托给其他 CDN。一种特殊情况是，该其他 CDN 提供商恰好也是向EU提供网络访问的网络服务提供商，在这种情况下，EU与 NSP 之间也存在单独且独立的业务关系，用于相应的网络访问。
CSP 和 CDN 提供商之间以及一个 CDN 提供商和另一个 CDN 提供商之间的任何业务关系的形成和详细信息超出了本文档的范围。然而，本文档关注的是，从技术角度来看，目前不存在标准或开放规范来促进此类 CDN 互连。
下面描述了通过 CDN 互联执行端到端内容分发的一种可能流程：
* 来自EU用户代理的初始内容请求首先由权威（上游）CDN 接收，该 CDN 是与 CSP 有业务部署的 CDN。
* 权威（上游）CDN 可以自己为请求提供服务，也可以选择使用 CDN 互联将请求重定向到更适合这样做的下游 CDN（例如，“更接近”的下游 CDN）到EU。
* EU的用户代理将“跟随”权威 CDN 返回的重定向，并从下游 CDN 请求内容。如果需要，Downstream CDN将从权威（上游）CDN获取请求的内容，如果需要，Authoritative CDN将从内容服务提供商处获取请求的内容。
本文档的目标是概述 CDN 互联的问题领域。第 2 节讨论 CDN 互连的用例。第 3 节介绍了 IETF 正在考虑的 CDNI 模型和问题领域。第 4 节分别描述了每个 CDNI 接口，并重点介绍了可以考虑重用或利用以实现 CDNI 接口的示例候选协议。附录 B.2 描述了 CDNI 问题空间与其他相关 IETF 工作组和 IRTF 研究组之间的关系。
1.1、 术语
本文档使用以下术语：
Authoritative CDN：权威 CDN，与 CSP 有直接关系的 CDN，用于通过权威 CDN 或权威 CDN 的下游 CDN 分发和交付该 CSP 的内容。
CDN Interconnection(CDNI)：CDN互连，一对 CDN 之间的关系，使一个 CDN 能够代表另一个 CDN 提供内容分发服务。CDN互连可以全部或部分通过一组接口实现，一对CDN通过这些接口相互通信，以实现由一个CDN（下游CDN）中的代理代表另一个CDN向用户代理交付内容（上游 CDN）。
CDN Provider：CDN 提供商，运营 CDN 并提供内容分发服务的服务提供商，通常由内容服务提供商或其他 CDN 提供商使用。请注意，一个指定的实体可能扮演多个角色。例如，一家公司可能同时作为内容服务提供商、网络服务提供商和 CDN 提供商运营。
CDNI Metadata：CDNI元数据，具有跨 CDN 范围的内容分发元数据的子集。例如，CDNI 元数据可以包括地理封锁信息（即，定义要提供或阻止内容的地理区域的信息）、可用性窗口（即定义要使内容可用或被阻止的时间窗口的信息）和要强制执行的访问控制机制（例如，URI 签名验证）。CDNI 元数据还可能包括有关所需分发策略（例如，预先定位与动态获取）以及有关 CDN 可以在哪里/如何获取内容的信息。
Content：内容，任何形式的数字数据。对分发和交付具有额外约束的一种重要内容形式是连续媒体（即，源和接收器之间存在时间关系）。
Content Distribution Metadata：内容分发元数据，与内容分发相关的内容元数据子集。这是 CDN 所需的元数据，以便启用和控制 CDN 的内容分发和交付。在 CDN 互连环境中，某些内容分发元数据可能具有 CDN范围内（因此不需要在 CDN 之间进行通信），而某些内容分发元数据可能具有 CDN范围间（因此需要CDN 之间进行通信）。
Content Distribution Network(CDN)/Content Delivery Network(CDN)：内容分发网络，网络基础设施中的网络元素在第 4 层到第 7 层进行协作，以便更有效地将内容分发给用户代理。通常，CDN 由请求路由系统、分发系统（包括一组代理）、日志记录系统和 CDN 控制系统组成。
Content Metadata：内容元数据，这是关于内容的元数据。内容元数据包括：
1. 与内容分发相关的元数据（因此与参与该内容分发的 CDN 相关）。我们将这种类型的元数据称为“内容分发元数据”。另请参阅内容分发元数据的定义。
2. 与实际内容或内容表示相关的元数据，与该内容的分发没有直接关系。例如，此类元数据可能包括与内容的类型、演员表、评级等有关的信息以及与内容表示的分辨率、纵横比等有关的信息。
Content Service：内容服务，由内容服务提供商提供的服务。内容服务包含完整的服务，可能不仅仅是提供对内容项的访问；例如，内容服务还包括任何中间件、密钥分发、节目指南等，它们可能不需要与内容分发和交付中涉及的 CDN 或 CDN 进行任何直接交互。
Content Service Provider(CSP)：内容服务提供商，向最终用户（他们通过用户代理访问）提供内容服务。CSP 可以拥有作为内容服务的一部分提供的内容，或者可以从另一方许可内容权利。
Control system：控制系统，CDN 内的功能，负责引导和控制 CDN 的其他组件以及处理与外部系统的交互（例如，处理交付服务创建/更新/删除请求，或特定服务供应请求）。
Delivery：交付，CDN 代理中负责向用户代理交付一段内容的功能。例如，交付可能基于 HTTP 渐进式下载或 HTTP 自适应流。
Distribution system：分发系统，CDN 内的功能，负责分发内容分发元数据以及 CDN 内的内容本身（例如，下至代理）。
Downstream CDN：下游 CDN，对于指定的最终用户请求，另一个 CDN（上游 CDN）将请求重定向到的 CDN（在一对直接互连的 CDN 内）。请注意，在连续重定向（例如，CDN1-->CDN2-->CDN3）的情况下，指定的 CDN（例如，CDN2）可以充当重定向的下游 CDN（例如，CDN1-->CDN2）并作为上游 CDN，用于相同请求的后续重定向（例如，CDN2-->CDN3）。
Dynamic CDNI Metadata acquisition：动态 CDNI 元数据获取，在 CDN 互连的环境中，动态 CDNI 元数据获取意味着下游 CDN 在某个时间点从上游 CDN 获取内容的 CDNI 元数据，该内容的请求由上游委托给下游 CDN CDN（并且该特定 CDNI 元数据在下游 CDN 中尚不可用）。另请参阅下游 CDN 和上游 CDN 的定义。
Dynamic content acquisition：动态内容获取，动态内容获取是 CDN 从内容源获取内容以响应最终用户从 CDN 请求内容的地方。在 CDN 互连的环境中，动态获取意味着下游 CDN 在某个时间点从上游 CDN（以及特定的内容在下游 CDN 中尚不可用）。
End User(EU)：最终用户，系统的“真实”用户，通常是人类，但也可能是模拟人类的硬件和/或软件的某种组合（例如，用于自动质量监控等）。
Logging system：日志系统，CDN 中负责收集分发和交付活动的测量和记录的功能。日志系统记录的信息可用于各种目的，包括收费（例如，CSP）、分析和监控。
Metadata：元数据，元数据一般是关于数据的数据。
Network Service Provider(NSP)：网络服务提供商，为最终用户提供基于网络的连接/服务。
Over-the-top (OTT)：一种服务，例如使用 CDN 的内容分发，由与该服务的用户所连接的 NSP 不同的运营商运营。
Pre-positioned CDNI Metadata acquisition：预置 CDNI 元数据获取，在 CDN 互连的环境中，CDNI 元数据预置是下游 CDN 在任何最终用户从下游 CDN 请求内容之前或独立于其获取内容的 CDNI 元数据。
Pre-positioned content acquisition：预置内容获取，内容预置是 CDN 在任何最终用户从 CDN 请求内容之前或独立于内容源获取内容的地方。在 CDN 互连的环境中，上游 CDN 指示下游 CDN 提前或独立于任何终端用户请求从内容源（包括上游 CDN）获取内容。
Quality of Experience(QoE)：体验质量，如 [RFC6390] 的第 2.4 节中所定义。
Request Routing system：请求路由系统，CDN 内的功能，负责接收来自用户代理的内容请求，获取和维护关于一组候选代理或候选 CDN 的必要信息，以及用于选择用户并将用户重定向到适当的代理或 CDN。要启用 CDN 互连，请求路由系统还必须能够处理由另一个 CDN 传递给它的用户代理内容请求。
Surrogate：代理，一种设备/功能（通常称为缓存），它与 CDN 的其他元素交互以控制和分发 CDN 内的内容，并与用户代理交互以交付内容。通常，代理将缓存请求的内容，以便他们可以直接传送相同的内容以响应来自多个用户代理（及其最终用户）的请求，从而避免内容需要多次通过网络核心（即，从内容起源于代理）。
Upstream CDN：上游CDN，对于指定的最终用户请求，将请求重定向到另一个 CDN 的 CDN（在一对直接互连的 CDN 内）。
User Agent(UA)：用户代理，最终用户通过其与内容服务交互的软件（或硬件和软件的组合）。用户代理将与内容服务通信以选择内容，并与一个或多个 CDN 通信以交付内容。此类通信不限于 HTTP，还可以通过各种协议进行。用户代理（非穷举）的例子有浏览器、机顶盒(Set Top Boxes，STB)、专用内容应用程序（例如媒体播放器）等。
1.2、 CDN背景
假设读者熟悉 CDN 的架构、特性和操作。对于不太熟悉 CDN 操作的读者，以下资源可能有用：
* RFC 3040 [RFC3040] 描述了许多用于构建 CDN 的组件技术。
* 分类法 [TAXONOMY] 比较了多个 CDN 的架构。
* RFC 3466 [RFC3466] 和 RFC 3570 [RFC3570] 是 IETF 内容分发互联网 (Content Distribution Internetworking，CDI) 工作组的输出，该工作组于 2003 年关闭。
注意：本文档中使用的某些术语与上述参考文档中使用的术语相似。阅读本文件时，术语应理解为具有第 1.1 节中提供的定义。
2、 CDN 互联用例
越来越多的 NSP 正在部署 CDN，以经济高效地应对日益增长的点播视频服务和其他内容分发应用程序的使用。
CDN 允许缓存更靠近网络边缘的内容，以便 CDN 代理（即缓存）可以将指定的内容项目交付给多个用户代理（及其最终用户），而无需多次通过网络核心传输（即，从内容来源到代理）。这有助于降低 NSP 的带宽成本并提高最终用户的体验质量。CDN 还支持跨多个代理复制流行内容，这使得内容可以同时提供给大量用户代理。这也有助于处理诸如突发访问和拒绝服务攻击等情况。
NSP 部署的 CDN 不仅限于内容分发以支持网络服务提供商自己的“秘密花园”服务，例如向机顶盒提供电视服务的 IP 交付，还用于向其他设备交付内容，包括个人电脑、平板电脑、手机等。
一些服务提供商在多个地区运营并联合多个附属 NSP。这些 NSP 通常运行独立的 CDN。随着他们服务的发展（例如，为跨附属 NSP 向漫游用户提供内容服务的无缝支持），需要将这些 CDN 互连；这代表了 CDNI 的第一个用例。但是，没有开放的规范，也没有通用的最佳实践来定义如何实现这种 CDN 互连。
CSP 希望能够将他们的（部分）内容提供给通常分布在多个地区的大量最终用户，同时保持高质量的体验，而无需与以下人员保持直接业务关系许多不同的 CDN 提供商（或必须将他们自己的 CDN 扩展到大量位置）。一些 NSP 正在考虑将其各自的 CDN（以及可能的顶级 CDN）互连，以便该集体基础设施能够以具有成本效益的方式满足 CSP 的要求。这代表了 CDNI 的第二个用例。特别是，这将使 CSP 能够尽可能从网内交付（即，在网络服务提供商自己的网络/CDN 覆盖范围内）中受益，否则就可以从网外交付中受益，而无需 CSP 与所有供应商保持直接业务关系。参与交付的 CDN。同样，CDN 提供商（NSP 或顶级 CDN 运营商）面临缺乏开放规范和最佳实践的问题。
NSP 通常在特定服务或环境的环境中部署 CDN 作为专门的成本降低项目。一些 NSP 为单独的服务运行单独的 CDN。例如，可能有用于托管 IPTV 服务交付的 CDN、用于网络电视交付的 CDN 和用于向移动终端交付视频的 CDN。随着 NSP 集成其服务组合，需要将这些 CDN 互连，这是 CDNI 的第三个用例。同样，NSP 面临着 CDN 互连缺乏开放接口的问题。
出于运营原因（例如，灾难、突发访问）或商业原因，over-the-top CDN 可能会选择使用另一个 CDN（例如，具有网络代理的 NSP CDN）来为子集提供服务的用户请求（例如，来自附加到该 NSP 的用户的请求），这导致 CDNI 的第四个用例，因为 CDN 提供商（顶级 CDN 提供商或 NSP）面临缺乏开放规范和最佳实践。
CDN 互连的用例在 [CDNI-USE-CASES] 中进一步讨论。
3、 IETF 的 CDN 互连模型和问题领域
本节讨论 IETF 在 CDN 互连方面工作的问题领域。
互连 CDN 涉及形成每个 CDN 的多个不同功能和组件之间的交互。只有其中一些需要 IETF 的额外规范。
一些 NSP 已经开始进行实验，以探索他们的 CDN 用例是否已经可以通过现有的 CDN 实现来解决。[CDNI-EXPERIMENTS] 中记录了一组这样的实验。这些实验的结论是，虽然使用现有 CDN 技术可以实现一些基本的有限 CDN 互连功能，但当前缺乏具有必要功能级别的任何标准化 CDNI 接口（例如本文档中讨论的那些），这阻碍了 CDN 互连的部署.
下面列出了互连一对 CDN 所需的四个接口，它们构成了 CDN 互连的问题空间，以及目前尚不存在标准的每个接口所需的功能。作为 CDNI 接口开发的一部分，还需要就如何识别和命名将在互连 CDN 之间交换的数据对象的通用机制达成一致。
术语“接口”的使用旨在涵盖交换 CDNI 数据表示（例如 CDNI 元数据对象）的协议以及数据表示本身的规范（即，每个对象包含哪些属性/字段，其结构等）。
** CDNI Control 接口：该接口允许互连 CDN 中的“CDNI Control”系统进行通信。该接口可能支持以下内容：
* 允许引导其他 CDNI 接口（例如，接口地址/URL 发现和安全关联的建立）。
* 允许配置其他 CDNI 接口（例如，上游 CDN 指定要通过 CDNI 日志记录接口报告的信息）。
* 允许下游 CDN 传达有关其交付能力和策略的静态（或相当静态）信息。
* 允许引导 CDN 之间的接口以获取内容（即使该接口本身不在 CDNI 工作的范围内）。
* 允许上游 CDN 发起或请求在下游 CDN 中执行的特定操作。例如，允许上游 CDN 启动内容或 CDNI 元数据获取（预定位）或请求无效或清除下游 CDN 中的内容文件和/或 CDNI 元数据。
** CDNI 请求路由接口：该接口允许互连 CDN 中的请求路由系统进行通信，以确保最终用户请求可以从上游 CDN（重新）定向到下游 CDN 中的代理，特别是在选择职责可能跨 CDN 拆分（例如，上游 CDN 可能负责选择下游 CDN，而下游 CDN 可能负责选择该下游 CDN 内的实际代理）。具体来说，CDN请求路由接口的功能可以划分如下：
* CDNI 请求路由重定向接口，允许上游 CDN 在请求路由时查询下游 CDN，然后再将请求重定向到下游 CDN。
* CDNI Footprint & Capabilities 通告接口，允许下游 CDN 向上游 CDN 提供（静态或动态）信息（例如，资源、足迹、负载），以方便上游 CDN 请求路由系统在以下情况下选择下游 CDN处理来自用户代理的后续内容请求。
** CDNI Metadata接口：该接口允许互连CDN中的分发系统进行通信，以确保CDNI Metadata可以跨CDN交换。有关 CDNI 元数据的定义和示例，请参见第 1.1 节。
** CDNI Logging 接口：该接口允许互连 CDN 中的 Logging 系统通信相关活动日志，以便允许使用日志的应用程序在多 CDN 环境中运行。例如，上游 CDN 可以从下游 CDN 收集交付日志，以便对 CSP 执行统一收费或用于跨 CDN 的结算。类似地，上游 CDN 可以从下游 CDN 收集交付日志，以便向 CSP 提供统一的报告和监控。
请注意，这四个接口下的实际功能分组在此阶段被认为是暂定的，并且可能会在进一步研究后进行更改（例如，某些功能子集可能会从一个接口移动到另一个接口）。
上面的列表涵盖了一个重要的潜在问题空间，部分原因是为了互连两个 CDN，有几个“接触点”需要标准化。但是，预计 CDNI 接口不需要从头开始定义，而是可以在很大程度上重用或利用现有协议；这将在第 4 节中进一步讨论。
形成 CDNI 问题区域的接口如图 1 所示。
图 1：CDNI 问题领域的模型
<==> CDNI范围内的接口 **** CDNI范围之外的接口 .... CDNI范围之外的接口
如图 1 所示，互连 CDN 之间的内容获取超出了 CDNI 的范围；这值得一些额外的解释。这种决定的结果是，本文档中描述的 CDNI 问题空间仅专注于定义 CDNI 的控制平面，而 CDNI 数据平面（即实际内容对象的获取和分发）超出了范围。做出这种决定的理由是，今天的 CDN 通常已经使用标准化协议（例如 HTTP、FTP、rsync 等）来从其 CSP 客户获取内容，并且预期相同的协议可用于互连 CDN 之间的获取。因此，内容获取的问题被认为已经解决了，从 CDNI 工作组制定的规范中获取内容所需的一切就是在 CDNI 元数据中描述用于检索内容的参数——例如，要连接的 IP 地址/主机名、使用什么协议来检索内容等。
4、 界定 CDNI 问题
本节概述了如何通过重用或利用现有协议来实现 CDNI 接口来限制解决 CDNI 问题空间的工作范围。本次讨论的目的不是抢占任何工作组关于选择实现 CDNI 接口的最合适的协议、技术和解决方案的决定，而是旨在说明 CDNI 接口不需要在真空中创建和重用或利用现有协议是可能的。
CDNI问题区中第3节描述的四个CDNI接口（CDNI Control接口、CDNI请求路由接口、CDNI元数据接口和CDNI Logging接口）都是运行在应用层（OSI网络模型中的第7层）的控制平面接口）。首先，由于与 Internet 中的许多其他现有应用程序相比，预计这些接口不会表现出独特的会话、传输或网络要求，因此预计 CDNI 接口将在现有会话、传输、和网络协议。
其次，虽然可以专门为 CDNI 设计一个新的应用协议，但我们下面的分析表明这是不必要的，建议重用或利用现有的应用协议（HTTP [RFC2616]、Atom 发布协议 [RFC5023]、可扩展消息传递和在线协议 (Extensible Messaging and Presence Protocol，XMPP) [RFC6120]，例如）来实现 CDNI 接口。
4.1、 CDNI控制接口
CDNI 控制接口允许互连 CDN 中的控制系统进行通信。目前，CDNI 控制接口所需支持的确切的 CDN 间控制功能的定义不如其他三个 CDNI 接口。
预计 Control 接口和其他 CDNI 接口一样，可以重用或利用现有协议。
4.2、 CDNI 请求路由接口
CDNI 请求路由接口启用上游 CDN 中的请求路由功能，以查询下游 CDN 中的请求路由功能，以确定下游 CDN 是否能够（并愿意）接受委托的内容请求。它还允许下游 CDN 控制上游请求路由功能应在重定向消息中返回给用户代理的内容。
因此，CDNI 请求路由接口是一个相当简单的请求/响应接口，可以通过任意数量的请求/响应协议实现。例如，它可以使用常见的 WebServices 方法之一（可扩展标记语言-远程过程调用 (Extensible Markup Language-Remote Procedure Calling，XML-RPC)、对已知 URI 的 HTTP 查询等）实现为 WebService。这消除了 CDNI 工作组为 CDNI 请求路由接口的请求/响应元素定义新协议的需要。
此外，如第 3 节所述，CDNI 请求路由接口也有望使下游 CDN 能够向上游 CDN 提供（静态或动态）信息（例如，资源、足迹、负载），以便通过以下方式选择下游 CDN在处理来自用户代理的后续内容请求时，上游 CDN 请求路由系统。预计 CDNI 请求路由的此类功能可以由 CDNI 工作组指定，并显着利用支持可达性信息动态分发的现有 IETF 协议（例如，通过利用现有路由协议）或支持应用程序级查询拓扑信息（例如，使用利用应用层流量优化 (Application-Layer Traffic Optimization，ALTO) [RFC5693]）。
4.3、 CDNI元数据接口
CDNI 元数据接口使下游 CDN 中的分发系统能够从上游 CDN 请求 CDNI 元数据，以便下游 CDN 可以正确处理和响应通过 CDNI 请求路由接口接收的重定向请求和直接从用户代理接收的内容请求。
CDNI 元数据接口因此类似于 CDNI 请求路由接口，因为它是一个请求/响应接口，具有潜在的附加功能，即 CDNI 元数据搜索可能比简单的请求路由重定向请求具有更复杂的语义。因此，与 CDNI 请求路由接口一样，CDNI 元数据接口可以使用常见的 WebServices 方法之一（XML-RPC、对已知 URI 的 HTTP 查询等）或可能使用其他现有协议（如 XMPP）实现为 WebService [RFC6120]。这消除了 CDNI 工作组为 CDNI 元数据接口的请求/响应元素定义新协议的需要。
4.4、 CDNI 日志接口
CDNI Logging 接口允许在互连的 CDN 之间交换内容分发和交付活动的详细信息——例如，与内容分发相关的日志记录的交换，类似于 Web 服务器访问日志中记录的日志记录。
已经存在几种可能用于在互连 CDN 之间交换 CDNI 日志的协议，包括简单网络管理协议 (Simple Network Management Protocol，SNMP)、系统日志、FTP（和安全变体）、HTTP POST 等。
5、 安全考虑
CDN 分发内容有一系列安全考虑，例如如何根据 CSP 策略强制控制最终用户对内容的访问，或者如何信任 CDN 生成的日志信息以用于为 CSP 付费。如今，CDN 提供商和 CSP 已经在独立 CDN 的背景下处理了这些安全问题。然而，CDN 的互连通过将信任模型扩展到信任链（即，CSP“信任”一个“信任”另一个 CDN 的 CDN）引入了一组新的安全考虑。在多 CDN 环境中用于缓解这些风险的机制可能类似于在单 CDN 情况下使用的机制，但必须验证它们在这种更复杂环境中的适用性。
除了适用于单一 CDN 的情况之外，CDN 的互连还可能引入额外的隐私考虑。在多 CDN 环境中，不同的 CDN 可能位于不同的法律制度中，需要执行不同的隐私要求。此类隐私要求可能会影响可跨 CDNI 接口交换的信息的粒度。例如，在与上游 CDN 交换包含最终用户交付详细信息的日志记录之前，下游 CDN 中的日志记录系统可能需要应用某种程度的匿名化、混淆，甚至完全删除某些字段。
维护内容本身、其相关元数据（包括交付策略）以及分发和交付内容的 CDN 的安全性是 CDN 提供商和 CSP 的关键要求，并且 CDN 互连接口必须提供足够的机制来维护内容的安全性。互连 CDN 的整个系统以及通过任何一组互连 CDN 分发和交付的信息（内容、元数据、日志等）。
5.1、 CDNI 控制接口的安全性
通过此接口在互连 CDN 之间交换的信息具有敏感性。一对 CDN 使用此接口来允许引导所有其他 CDNI 接口，可能包括建立保护这些接口的机制。因此，该接口的损坏可能会导致所有其他接口的损坏。使用这个接口，上游 CDN 可以预先定位或删除下游 CDN 中的内容或元数据，下游 CDN 可以向上游 CDN 提供管理信息等。所有这些操作都需要对等 CDN 进行适当的身份验证，并且可以确保它们之间流动的信息的机密性和完整性。
5.2、 CDNI 请求路由接口的安全性
在此接口中必须使用适当级别的身份验证和机密性，因为它允许上游 CDN 查询下游 CDN 以重定向请求，相反，允许下游 CDN 影响上游 CDN 的请求路由功能。
在此接口上缺乏适当的安全性的情况下，超负荷的上游 CDN 可能会用虚假请求淹没下游 CDN，或者让下游 CDN 发送超负荷的上游 CDN 私有信息。此外，超负荷的下游 CDN 可能会影响上游 CDN，因此上游 CDN 将请求重定向到超负荷的下游 CDN 或另一个下游 CDN，以便例如吸引额外的交付收入。
5.3、 CDNI 元数据接口的安全性
该接口允许下游 CDN 向上游 CDN 请求 CDNI 元数据，因此上游 CDN 在发送数据之前必须确保前者经过适当的身份验证。相反，下游 CDN 必须在请求元数据之前对上游 CDN 进行身份验证，以使其自身免受超负荷的上游 CDN 的毒害。必须保护对等点之间交换的信息的机密性和完整性。
5.4、 CDNI 日志接口的安全性
日志数据包含潜在的敏感信息（最终用户访问了哪些媒体资源、最终用户的 IP 地址、潜在名称和订阅者帐户信息等）。由于日志记录在 CDN 之间移动，因此必须保护此信息的机密性。从它可以作为跨 CDN 收费的基础的角度来看，此信息也可能是敏感的。因此，需要适当级别的保护以防止此信息的损坏、重复和丢失。
6、 致谢
作者要感谢 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 的评论和对文本的贡献。
7、 参考资料
[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-Charter] "IETF ALTO WG Charter",. [CDNI-EXPERIMENTS] Bertrand, G., Ed., Le Faucheur, F., and L. Peterson, "Content Distribution Network Interconnection (CDNI) Experiments", Work in Progress, February 2012. [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. [DECADE-Charter] "IETF DECADE WG Charter",. [P2PRG-CDNI] Davie, B. and F. Le Faucheur, "Interconnecting CDNs aka 'Peering Peer-to-Peer'", March 2010,. [PPSP-Charter] "IETF PPSP WG 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. [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", RFC 3040, January 2001. [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model for Content Internetworking (CDI)", RFC 3466, February 2003. [RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content Internetworking (CDI) Scenarios", RFC 3570, July 2003. [RFC5023] Gregorio, J., Ed., and B. de hOra, Ed., "The Atom Publishing Protocol", RFC 5023, October 2007. [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, October 2009. [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011. [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, October 2011. [TAXONOMY] Pathan, A. and R. Buyya, "A Taxonomy and Survey of Content Delivery Networks", 2007,.
附录 A、 实现 CDNI 接口的设计考虑
本节在单独描述每个 CDNI 接口之前扩展了 CDNI 接口如何重用和利用现有协议，并重点介绍可以考虑重用或利用以实现 CDNI 接口的示例候选协议。但是，此处讨论的选项纯粹是示例，并未就稍后要使用的协议达成任何共识。
A.1、 CDNI控制接口
CDNI 控制接口允许互连 CDN 中的控制系统进行通信。目前，CDNI 控制接口所需支持的确切的 CDN 间控制功能的定义不如其他三个 CDNI 接口。
但是，如第 3 节所述，可能需要 CDNI 控制接口来支持类似于以下的功能：
允许上游 CDN 和下游 CDN 建立、更新或终止其 CDNI 互连。
允许引导其他 CDNI 接口（例如，协议地址发现和安全关联的建立）。
允许配置其他 CDNI 接口（例如，上游 CDN 指定要通过 CDNI 日志记录接口报告的信息）。
允许下游 CDN 传达有关其交付能力、资源和策略的静态信息。
允许引导 CDN 之间的接口以获取内容（即使该接口本身不在 CDNI 工作的范围内）。
预计 Control 接口和其他 CDNI 接口一样，可以重用或利用现有协议。一旦对 Control 接口的要求得到细化，就会考虑这些。
A.2、 CDNI 请求路由接口
CDNI 请求路由接口启用上游 CDN 中的请求路由功能，以查询下游 CDN 中的请求路由功能，以确定下游 CDN 是否能够（并愿意）接受委托的内容请求，并允许下游 CDN 进行控制上游请求路由功能应该在重定向消息中返回给用户代理的内容。
因此，CDNI 请求路由接口需要提供一种机制，让上游 CDN 向下游 CDN 发出“重定向请求”。请求路由接口需要能够支持通过 DNS 以及特定内容应用协议（例如 HTTP、实时流协议 (RTSP)、实时消息传递协议 (RTMP) 等）。
因此，重定向请求应包含以下信息：
上游 CDN 通过其接收初始用户代理请求的协议（例如 DNS、HTTP）。
下游 CDN 执行有效请求路由所需的用户代理请求的其他详细信息。对于 DNS，这通常是代表用户代理发出请求的 DNS 解析器的 IP 地址。对于通过特定于内容的应用程序协议接收的请求，重定向请求可能包含更多与原始用户代理请求相关的信息，但至少应包括用户代理的 IP 地址、等效的 HTTP 主机标头和等效的[RFC2616] 中定义的 HTTP abs_path。
需要注意的是，CDNI架构需要考虑下游CDN可能会收到来自用户代理的请求，而无需先收到来自上游CDN的针对相应用户代理请求的重定向请求，例如：
用户代理（或 DNS 解析器）可以缓存来自请求路由器的 DNS 或应用程序响应。
通过请求路由接口对重定向请求的响应可能是可缓存的。
一些 CDN 可能依赖于简单的粗略策略，例如，CDN B 同意始终为 CDN A 的委托重定向请求提供服务，在这种情况下，必要的重定向详细信息在带外（CDNI 接口）交换，例如，配置。
收到重定向请求后，下游 CDN 将使用请求中提供的信息来确定它是否能够（并愿意）接受委托的内容请求，并需要将其决定结果返回给上游 CDN。
因此，来自下游 CDN 的重定向响应应包含以下信息：
表示接受或拒绝的状态代码（可能有伴随的原因）。
允许上游 CDN 重定向的信息。在基于 DNS 的请求路由的情况下，这应该包括上游 CDN 应返回给请求 DNS 解析器的等效 DNS 记录（例如，CNAME）。在基于应用程序的请求路由的情况下，这应该包括构建特定于应用程序的重定向响应以返回到请求用户代理所需的信息。对于来自用户代理的 HTTP 请求，这可能包括上游 CDN 可以在 HTTP 3xx 响应中返回的 URI。
因此，CDNI 请求路由接口是一个相当简单的请求/响应接口，可以通过任意数量的请求/响应协议实现。例如，它可以使用常见的 WebServices 方法之一（XML-RPC、对已知 URI 的 HTTP 查询等）实现为 WebService。这消除了 CDNI 工作组为 CDNI 请求路由接口的请求/响应元素定义新协议的需要。因此，CDNI 工作组将只负责指定：
推荐的请求/响应协议与特定于 CDNI 请求路由接口的任何附加语义和程序一起使用（例如，处理格式错误的请求/响应）。
重定向请求和响应的语法（即表示/编码）。
重定向请求和响应的语义（即含义和预期内容）。
此外，如第 3 节所述，CDNI 请求路由接口也有望使下游 CDN 能够向上游 CDN 提供（静态或动态）信息（例如，资源、足迹、负载），以便通过以下方式选择下游 CDN在处理来自用户代理的后续内容请求时，上游 CDN 请求路由系统。预计 CDNI 请求路由的此类功能可以由 CDNI 工作组指定，并显着利用支持可达性信息动态分发的现有 IETF 协议（例如，通过利用现有路由协议）或支持应用程序级查询拓扑信息（例如，通过利用 ALTO）。
A.3、 CDNI元数据接口
CDNI元数据接口使下游CDN中的分发系统能够从上游CDN获取CDNI元数据，以便下游CDN能够正确处理和响应：
通过 CDNI 请求路由接口接收的重定向请求。
直接从用户代理收到的内容请求。
CDNI 元数据接口需要为上游 CDN 提供一种机制以：
** 将 CDNI 元数据分发/更新/删除到下游 CDN。
和/或允许下游 CDN：
** 直接请求 CDNI 元数据对象。
** 对 CDNI 元数据进行递归请求——例如，使下游 CDN 能够沿着具有对象间关系的对象树向下走。
CDNI 元数据接口因此类似于 CDNI 请求路由接口，因为它是一个请求/响应接口，具有潜在的附加功能，即 CDNI 元数据搜索可能比简单的请求路由重定向请求具有更复杂的语义。因此，与 CDNI 请求路由接口一样，CDNI 元数据接口可以使用常见的 WebServices 方法之一（XML-RPC、对已知 URI 的 HTTP 查询等）或可能使用其他现有协议（如 XMPP）实现为 WebService [RFC6120]。这消除了 CDNI 工作组为 CDNI 元数据接口的请求/响应元素定义新协议的需要。
因此，CDNI 工作组将只负责指定：
推荐的请求/响应协议与特定于 CDNI 元数据接口的任何附加语义一起使用（例如，处理格式错误的请求/响应）。
将通过接口交换的 CDNI 元数据对象的语法（即表示/编码）。
元数据对象的各个属性的语义（即含义和预期内容）。
如何表示不同 CDNI 元数据对象之间的关系。
A.4、 CDNI 日志接口
CDNI Logging 接口允许在互连的 CDN 之间交换内容分发和交付活动的详细信息，例如与内容分发相关的日志记录（类似于 Web 服务器访问日志中记录的日志记录）。
在当今的 CDN 中，日志记录用于多种目的。具体来说，CDN 使用日志来生成呼叫数据记录 (CDR)，以传递给计费和支付系统以及实时（和近实时）分析系统。此类应用程序对 CDNI 日志记录接口提出了要求，以支持在互连 CDN 之间保证和及时地传递日志消息。可能还需要能够证明接收到的日志消息的完整性。
已经存在几种可能用于在互连 CDN 之间交换 CDNI 日志的协议，包括 SNMP 陷阱、系统日志、FTP、HTTP POST 等，尽管某些候选协议可能不太适合满足所有CDNI 的要求。例如，SNMP 陷阱会带来可扩展性问题，并且 SNMP 不支持陷阱的保证交付，因此可能会导致日志记录丢失，并且无法生成该内容分发的后续 CDR 和计费记录，以及该内容分发不可见到任何分析平台。
尽管没有必要为跨 CDNI Logging 接口交换日志定义新协议，但 CDNI 工作组仍需要指定：
推荐使用的协议。
一组默认的日志字段及其语法和语义。今天，没有跨不同内容分发协议的标准通用日志字段集，在某些情况下，甚至没有针对同一交付协议的不同实现的标准日志字段名称和值集。
触发日志记录生成的一组默认条件。
附录 B、 附加材料
本部分记录了作为定义 CDNI 问题陈述的一部分而产生的相关信息。
B.1、 非IETF的目标
下面列出了作者建议不属于 CDNI 工作组范围的内容分发方面：
内容服务提供商和权威 CDN 之间的接口（即由 CSP 签约的上游 CDN，由该 CDN 或其下游 CDN 交付）。
交付 CDN Surrogate 和 User Agent 之间的交付接口，例如流协议。
用户代理和指定 CDN 的请求路由系统之间的请求接口。现有的 IETF 协议（例如 HTTP、RTSP、DNS）通常被用户代理用来从 CDN 请求内容，并被 CDN 请求路由系统用来重定向用户代理请求。CDNI 工作组不需要为此定义新的协议。但是请注意，CDNI 控制平面接口可能会间接影响通过请求接口（例如 URI）交换的某些信息。
CDN之间的内容获取接口（即一段内容从一个CDN到另一个CDN的实际交付的数据平面接口）。这预计将使用现有协议，例如 HTTP 或其他论坛中定义的协议，用于源服务器和 CDN 之间的内容获取（例如，电信行业解决方案联盟 IPTV 互操作性论坛内容点播服务的基于 HTTP 的 C2 参考点（ ATIS IIF CoD))。因此，鉴于促进互操作性，本文档中描述的 CDN 互连问题空间可能仅关注协议/协商方面，其中内容获取协议将在两个互连的 CDN 之间使用。
最终用户/用户代理身份验证。最终用户/用户代理身份验证和授权是内容服务提供商的责任。
内容准备，包括编码和转码。CDNI 架构旨在允许跨互联 CDN 分发被视为不透明对象的内容。对象的解释和处理以及代理对最终用户的这些对象的优化交付不在 CDNI 的范围内。
数字版权管理 (Digital Rights Management，DRM)。DRM 是内容保护系统和用户代理之间的端到端问题。
使用 CDNI 日志的应用程序（例如，收费、分析、报告等）。
内部 CDN 接口和协议（即一个 CDN 内的接口和协议）。
单个 CDN 的可扩展性。虽然 CDNI 接口/方法的可扩展性在范围内，但单个 CDN 的扩展方式不在范围内。
请求路由系统选择 CDN 或代理的实际算法（但是，当需要跨 CDN 进行通信时，这些算法的输入所需的某些特定参数可能在范围内）。
代理算法。例如，缓存算法和内容获取方法不在 CDNI 工作的范围内。与 CDNI 内容管理策略相关的内容管理（例如，内容删除）在范围内，但缓存使用的内部算法来确定何时不再缓存内容项（在没有任何特定元数据的情况下） ) 超出范围。
元素管理界面。
与 CDN 互连相关的商业、商业和法律方面。
B.2、 与相关 IETF 工作组和 IRTF 研究组的关系
B.2.1、 ALTO工作组
正如 ALTO 工作组章程 [ALTO-Charter] 中所述：
工作组将设计并指定应用层流量优化 (ALTO) 服务，该服务将为应用程序提供信息以执行优于随机的初始对等选择。ALTO 服务可能会采取不同的方法来平衡最大带宽、最小跨域流量、最低用户成本等因素。工作组将考虑 BitTorrent、无跟踪器 P2P 和其他应用程序的需求，例如内容分发网络 (CDN) 和镜像选择。
特别是，ALTO 服务可以被 CDN 请求路由系统用来改进它对 CDN 代理的选择，以服务于特定的用户代理请求（或服务于来自另一个代理的请求）。[ALTO-CDN-USE-CASES] 描述了 CDN 能够从 ALTO 服务器获取网络拓扑和成本信息的许多用例，并讨论了如何将 CDN 请求路由用作 ALTO 的集成点到 CDN。在基于 CDN 互连的多 CDN 环境中，ALTO 服务有可能以相同的方式使用。例如，上游 CDN 可以在其决定中利用 ALTO 服务来选择应将用户请求委托给的下游 CDN。
但是，ALTO 当前的工作是对本文档中描述的工作的补充而不是重叠，因为 ALTO 和 CDN 之间的集成是特定 CDN 的内部决定，因此超出了 CDNI 工作组的范围。需要进一步研究的一个领域是 ALTO 服务是否应提供附加信息以促进 CDNI CDN 选择。
B.2.2、 DECADE工作组
DECADE 工作组 [DECADE-Charter] 正在解决减少最后一英里上行链路以及由点对点 (peer-to-peer，P2P) 流和文件共享应用程序引起的骨干和传输链路流量的问题。它通过使应用程序端点能够从网络内存储服务提供内容并允许其他应用程序端点从那里检索内容来解决这个问题。
以这种方式通过网络内存储服务交换数据，而不是通过直接通信，在以下情况下提供了显着的收益：
从网内存储服务到应用端点的网络容量/带宽显着超过从应用端点到应用端点的容量/带宽（例如，由于最终用户上行链路瓶颈）；和
内容将由应用程序端点的多个实例访问（例如，P2P 应用程序的典型情况）。
而与任何其他数据分发应用程序的情况一样，DECADE 架构和机制可能用于通过网络内存储服务交换 CDNI 控制平面信息（而不是直接在终止 CDNI 接口的实体之间）邻居 CDN，我们观察到：
从 DECADE 的角度来看，CDNI 将作为“内容分发应用程序”运行（即，将在 DECADE 之上运行）。
将负责与网络内存储服务本身控制相关的信令信息的 DECADE 控制平面与负责特定于应用程序的 CDNI 交互（例如 CDNI 的交换）的 CDNI 控制平面集成在一起似乎没有明显的好处元数据、CDNI 请求重定向和 CDNI 日志信息的传输）。
使用 DECADE 网络存储服务通常会带来有限的好处，因为 CDNI 接口预计会被每个 CDN 中的极少数 CDNI 客户端（如果不是一个）终止，并且 CDNI 客户端是预计在彼此直接通信时受益于高带宽/容量（至少与通过网络内存储服务器进行通信一样高）。
DECADE 网络存储架构和机制理论上可用于在互连的 CDN 之间获取内容对象本身。在内容对象仅从上游 CDN 到下游 CDN 获取一次（然后根据需要在下游 CDN 内部分发）的典型情况下，预计这不会有明显的好处。但它可能在某些特定情况下有好处。由于 CDN 之间的获取协议超出了 CDNI 的工作范围，这个问题留待进一步研究。
DECADE 网络内存储架构和机制也可能在指定的 CDN 中用于在该 CDN 的代理之间分发内容对象本身。由于 CDNI 的工作本身并不关心 CDN 内的操作，因此这个问题留待进一步研究。
因此，DECADE 的工作可能与本文档中描述的 CDNI 工作互补，但不重叠。
B.2.3、 PPSP工作组
正如 PPSP 工作组章程 [PPSP-Charter] 中所述：
点对点流媒体协议 (Peer-to-Peer Streaming Protocol，PPSP) 工作组为点对点 (P2P) 流媒体系统开发了两种信令和控制协议，用于传输具有近乎实时交付要求的实时和时移媒体内容...
... PPSP 工作组设计了跟踪器和对等体之间的信令和控制协议（PPSP“跟踪器协议”）和对等体之间通信的信令和控制协议（PPSP“对等体协议”）。这两种协议使对等方能够在特定内容项目所需的时间限制内接收流数据。
因此，PPSP 关注流内容本身的分发以及分发内容所需的必要信令和控制。因此，它有可能用于跨互联 CDN 获取流式内容。但是由于获取协议超出了 CDNI 建议的工作范围，我们将其留待进一步研究。此外，由于其流媒体性质，PPSP 不被视为适用于 CDNI 控制平面和 CDNI 数据表示的分发和控制。
因此，PPSP 的工作可能与本文档中描述的 CDNI 工作互补，但不重叠。
B.2.4、 IRTF P2P研究组
在 IETF 77 的 P2P 研究组中介绍了有关 CDN 互连动机和技术问题的一些信息。该介绍可以在 [P2PRG-CDNI] 中找到。
