CDNI - RFC7336翻译

CDNI框架

摘要
本文档提出了CDNI的一个框架。框架的目的是提供对CDNI问题空间的总体描述，和描述CDN互连所需的各种组件之间的
关系。CDNI需要指定接口和机制解决诸如请求路由，分发交换元数据，和CDN之间交换日志信息。本文档的目的是概述
每个接口需要完成的工作，描述这些接口和机制如何适配在一起，并且把详细规范放到其他文档。本文档结合RFC6707，
废弃RFC 3466。

本备忘录的状态

版权声明

1.介绍
本文档提供了互连CDN之间各种必须的组件，扩展了RFC6770和RFC6707中的问题陈述和用例。它用通用术语和大纲描述了必要接口
和机制如何适配在一起形成一个完整的CDN互连系统。详细规定放在其他文档。本文档广泛使用消息流示例来说明互连CDN的操作，
但是这些例子应该被认为是说明性的而不是规定性的。

RFC 3466使用不同的术语和模型来表示"Content(distribution) Internetworking (CDI)"。对接口的描述也缺少规定性。为了避免
混淆，本文档废弃RFC 3466(//阅读本文档时，需要认为RFC3466已经被废弃)。

1.1术语
本文档使用RFC6707中定义的核心术语，它还介绍了下列术语：

CDN-Domain:一个起始URL(不包括端口和Scheme，// 完整URL中"://"之前的部分称为 URL Scheme)的主机名(FQDN)，表示一个给定
CDN服务的内容集合。例如，在URL http://cdn.csp.example/...URL的其他部分...(//就是一个URL)，CDN-Domain是cdn.csp.example。
CDN-Domain的主要作用是确定和各种CDNI规则和应用策略相关的一个区域(子集)。例如，一条CDNI元数据记录可以被定义为一些CDN-Domain
相对应的资源集合。

Distinguished CDN-Domain：由CDN分配的CDN-Domain，用于和对等CDN通信的目的，但是在客户端请求中是找不到的(//这种CDN
-Domain在客户端请求中是不存在的，目的是对等CDN之间的通信)。这种CDN-Domain可以用于互联CDN获取，或者作为重定向的目标
，并使得一个CDN可以区分来自对等CDN的请求和终端用户的请求。

Delivering CDN:最终给终端用户提供一条内容的CDN。一系列下游CDN的最后一个(//最终给客户端提供内容的CDN)。

Iterative CDNI Request Redirection(迭代CDNI请求重定向)：当一个上游CDN选择将请求重定向到下游CDN，上游CDN可以将此次重定向行为完全基于本地决
定(没有试图考虑下游CDN如何依次向UA进行重定向)。在这种情况下，上游CDN把请求重定向到下游CDN的请求路由系统中，后续依
次的这种行为将会决定如何重定向那个请求：这种方法称之为"迭代"CDNI请求重定向。(//即每个CDN在重定向时，可以自主决定如
何进行重定向，这样对UA来说就会有一系列的重定向，就叫做迭代请求重定向，类似于DNS一样)

Recursive CDNI Request Redirection(递归请求重定向):当一个上游CDN选择把一个请求重定向到一个下游CDN，上游CDN可以通过
CDNI请求路由重定向接口查询下游CDN(或者使用之前类似请求缓存的信息)，来发现下游CDN是否想接受这个请求被重定向到它。这
允许上游CDN在重定向到UA时考虑下游CDN的响应。这种方法称为"递归"CDNI请求重定向。注意下游CDN可能将请求直接重定向到它
里面的代理服务器，或者下游CDN里面的其他组件(或者另一个CDN)，来适当的处理这个重定向请求。

(//迭代请求重定向:上游CDN直接给UA返回重定向，这样UA就需要一次次发起请求，直到最终的CDN。
//递归重定向请求:上游CDN查询下游CDN，找到合适的CDN之后给UA返回重定向，这样UA就直接得到了最终CDN。
//这个和DNS系统是一模一样的。)

同步CDNI操作：发生在服务用户请求的过程中时CDN之间的操作。即在UA开始尝试获取内容和请求被服务器之间发生的操作。

异步CDNI操作：发生在独立于任何给定的客户请求之外的CDN之间的操作。例如通告网点信息或者对稍后需要交付内容的预定位。

触发器接口：CDNI控制接口的子集，包括预定位、重新验证、清除元数据和内容的操作。这些操作通常由CSP对上游CDN响应的一些操作(触发器)。

我们有时候用uCDN和dCDN分别表示上游CDN和下游CDN(见RFC 6707)。

关于本文档的不同观点，使用了CDN网点的概念。对于是什么构成了CDN网点的讨论，读者可以参考[FOOTPRINT-CAPABILITY]。

1.2 参考模型

本文档使用图1的参考模型，扩展了之前定义在RFC 6707中的参考模型。(不同之处是扩展的模型把请求路由接口拆分为两个不同的
部分：请求路由重定向接口和网点&能力通告接口，如下所描述)

虽然参考模型中的某些接口对CDNI工作组来说已经"超出范围"(某种意义来说，没有必要为这些接口定义新的协议)，我们注意到我
们在本文档中解释CDNI的整体运作时，仍然需要提到这些接口。

我们也注意到，虽然我们通常对给定的CSP服务时，只显示一个上游CDN，但是完全有可能多个上游CDN服务同一个CSP。事实上，这
种情况在今天是存在的，单个CSP可以把它的内容分发给多个CDN。

下面的简要介绍了五个CDNI接口，对RFC 6707中的定义进行解释。我们在第4节更详细的介绍了这些接口。

-CI：给其他CDNI接口提供引导和参数的操作，以及包括预定位、重新验证、清除元数据和内容的操作。后面的操作子集有时候被
统称为"触发器接口"。

-CDNI请求路由接口：决定哪个CDN(以及可选的CDN中的代理)服务终端用户的操作。这个接口实际上是两个独立相关，并且逻辑捆
绑的接口(//即拆分为了两个独立接口，但是逻辑上有关联)：

*CDNI网点&能力上报接口(FCI)：异步的交换路由信息操作(例如给定CDN的服务网点信息和能力信息)使得一些列的用户请求可
以对CDN进行选择。

*CDNI请求路由重定向接口(RI)：对给定的用户请求选择一个交付CDN(代理)的同步操作。

-CDNI元数据接口(MI)：管理互连CDN如何交付内容传输元数据的接口。CDNI元数据的示例包括地理阻止指令、可用性窗口、访问控
制机制和清除指令，它可能包括以下：

*管理一系列的用户内容请求的异步元数据交换操作。
*管理一个指定用户内容请求行为的同步操作。

-CDNI日志接口(LI)：允许互连CDN交换相关的活动日志。可能包括以下：

*实时交换，适合运行时的流量监控。
*离线交换，适合分析和计费。

对基于CDNI控制接口的触发器操作和CDNI元数据接口的划分，某种意义上有些武断。对这两种情况，信息从上游CDN传送到下游CDN
可以广泛地被视为元数据，描述了下游CDN如何管理内容。例如，由CI传输的预定位信息，重新验证，或者清除元数据类似于通过M
I传输的发布更新元数据的信息。即使CI的清除内容操作可能被视为对那个内容的元数据更新：简单的说，清除就是指定内容的可
用性窗口结束。这两个接口有很多共同点，所以至少，需要在两者之间有一致的数据模型。

我们所描述的区别，和上游如何理解对于从下游CDN响应的"成功应用"的元数据有关(//我们要描述这种区别，这种区别和上游CDN
收到了下游CDN"成功应用"元数据时如何理解这个消息有关)。这种情况下的CI，下游CDN返回一个成功状态消息来保证操作已经成
功完成；例如，内容已经被清除或者预定位。这意味着下游CDN承担了成功完成所请求的操作的责任。相反，通过CDN的MI传送的元
数据就没有这样的保证。返回成功意味着成功接收了元数据，但是没有什么可以推断出元数据何时在下游CDN生效，只能推断出最
终会生效。这是因为全局的元数据同步更新和终端用户的请求当前在进行中(或当前的进展无法区别)。显然，如果"最终"变成了不
确定的时间，CDN不会被视为可信的对等体，但是MI承担的责任不能被明确界定。

最后，有一个实际问题会影响到所有的CDNI接口，那就是是否为HTTP Adaptive Streaming (HAS)优化CDNI。我们在本文档强调和
传递HAS内容的具体问题，但是更多的处理此问题的话题，见RFC 6983。

1.3. 本文档的结构

本文档的其余部分安排如下：
-第2节描述了一些CDNI的基本构件，特别是重定向用户请求到一个给定CDN时的各种选项。
-第3节提供了各种CDNI操作的说明性示例。
-第4节描述了主要CDNI接口的功能。
-第5节展示了使用定义的接口，如何实现CDNI的不同部署模型。
-第6节描述了CDNI的信任模型，特别是CDNI提出的信任传递问题。

2. 构件模块

2.1. 请求重定向

作为核心，CDNI要求从一个CDN到另一个CDN的请求重定向。对于上游CDN收到的任何指定请求，它要么直接响应请求，要么把请求
重定向到一个下游CDN。重定向一个请求到一个下游CDN，有两个主要的机制。第一种是利用DNS域名解析流程，第二种是使用应用
层的重定向机制，例如HTTP 302或者实时流协议(RTSP)的302重定向响应。由于存在大量包含某种重定向机制的应用层协议，本文
档将在示例中使用HTTP(和HTTPS)。类似的机制可以应用到其他应用层协议中。下面是一个DNS和基于HTTP重定向简短讨论，在第3
节有一些使用的示例(//即这里只是简单说明DNS和HTTP重定向，第3节有一些使用示例)。

2.1.1. DNS重定向

DNS重定向基于对相同的DNS名称返回不同的IP地址，例如，平衡服务器负载或者客户端的网络位置的原因。一个DNS服务器，有时
候成为Local DNS (LDNS)，代表终端用户解析DNS名称。LDNS 一次查询其他DNS服务器，直到达到CDN-Domain的权威DNS服务器。网
络运营商通常提供LDNS服务器，尽管用户可以*选择其他的DNS服务器(例如OpenDNS, Google Public DNS)。

后一种可能性很重要，因为权威DNS服务器只能看到向它发起查询的DNS服务器IP地址，而不是原始终端用户的IP地址。

DNS重定向的优点是对终端用户是完全透明的；用户向LDNS服务器发送一个DNS名称，并且得到一个IP地址。另一方面，DNS重定向
是有问题的，因为DNS请求来自LDNS服务器，而不是终端用户。这可能影响到基于用户位置选择的精确性。DNS重定向的透明度也是
一个问题，那就是没有机会考虑到UA或者URL路径组件的属性(//即UA的参数或者URL中的属性，在DNS中是无法处理到的)。我们考
虑DNS重定向的两种主要形式：简单的和基于CNAME的。

在简单的DNS重定向中，权威DNS服务器简单地从一组可能的IP地址中返回其中一个IP地址。应答的选择可以基于集合的特性(例如
，服务器的相对负载)或者客户端的特性(例如，客户端相对于服务器的位置)。简单重定向是直接的。仅有的警告是(1)单个DNS服
务器可以管理的可选IP地址存在限制；(2)下游服务器缓存DNS响应，因此响应中的TTL必须设置一个合适的值，来保持重定向的新
鲜度。

在基于CNAME的DNS重定向中，权威服务器对DNS请求返回一个CNAME，告诉LDNS服务器使用新的名字重新查询。一个CNAME在DNS命名
空间中，本质是一个符号链接，就像一个符号链接，重定向对客户端是透明的;LDNS服务器获得CNAME应答并且重新执行查询。只有
当名字被解析为IP地址时，才会将结果返回给用户。注意DNAME如果得到广泛支持，将会优于CNAME。

与HTTP重定向想比，DNS重定向的优点是可缓存的，减少CDN的重定向DNS服务器负载。然而，这种优势也可能是一个缺点，尤其是
当给定DNS解析器不完全遵依照TTL，这是真实环境中已知的问题。在这种情况下，一个终端用户可能在没有通过上游CDN时，直接
终止于下游CDN，在上游CDN的观点中，这可能是不期望看到的场景。

2.1.2 HTTP重定向

HTTP重定向利用HTTP协议的重定向响应(例如，"302"或者"307")。这个响应使用一个新的URL来替代原始URL。通过适当的改变URL
，服务器可以使得用户重定向到一个不同的服务器。HTTP重定向的优点是(1)服务器可以改变客户端URL包含的字段，例如，特定服
务器的DNS名称，以及正在访问的原始HTTP服务器;(2)客户单向服务器发送HTTP请求，因此客户端的IP地址是可知的，并且可以用
来选择服务器;(3)其他属性(例如content type, user agent type)对重定向机制是可见的。

正如DNS重定向的情况一样，使用HTTP重定向有一些潜在的缺陷。例如，它可能会影响应用行为;如果URL被改成一个不容的域名，
浏览器将不会发送cookie。另外，这可能也是一个优点，这会导致HTTP重定向的结果不会被缓存，因此所有的重定向都必须经过上
游CDN。

3. CDNI操作概述

为了给CDNI的不同组件提供全面的展示，我们通过一对互连的CDN，制作了一个"一天的生活"的内容项目来达到可用。这将有助于
在一个完整的CDNI解决方案中，说明所需要支持的许多功能。我们给出了使用基于DNS和基于HTTP的重定向示例。我们从非常简单
的例子开始，然后显示如何添加额外可能的功能，例如重定向的递归请求和内容删除。

在介绍具体示例之前，我们提出了可能发生的一个高层次的操作试图。这个高层次概述如图2所示。注意大多数操作只会涉及下面
显示的所有消息的一个子集，以及次序和操作次数可能会有很大差异，作为更详细的示例说明。

下面显示了Operator A作为上游CDN，Operator B作为下游CDN，前者和CP有关系而后者是Operator A选择的向终端用户交付内容的
CDN。这两个互连CDN的互连关系可能是对称的，但是每个方向可以被视为独立运作;为了简单起见，我们只展示了一个方向的互连
。(//意思是两个CDN是对等关系，但是对另一个CDN来说，每一个方向都可以被视为是单独运作)

图中所示操作如下：
1.下游CDNS在任何内容请求被重定向之前，使用FCI上报它的交付网点和能力。
2.在任何内容请求之前，上游CDN使用MI将CDNI元数据预定位到下游CDN，从而对稍后的内容请求做好准备，使得那个元数据可用。
(//上游CDN通过MI给下游CDN发送一个预定位元数据，让下游CDN做好准备，应对稍后的内容请求)
3.从UA过来的内容请求到达上游CDN。
4.上游CDN可能使用RI从下游CDN同步请求信息，而忽略它的交付能力决定下游CDN是否是一个合适的请求重定向目标。
5.上游CDN通过对UA发送一些响应(DNS，HTTP)把请求重定向到下游CDN。
6.UA向下游CDN请求内容。
7.下游CDN可能从上游CDN使用MI同步和内容相关的请求元数据，来决定是否服务此内容。
8.如果内容不在下游CDN的缓存中，下游CDN可以从上游CDN获取内容。
9.内容从上游CDN传送到下游CDN。
10.内容从下游CDN传递给UA。
11.一段时间后，也许应CSP(未显示)的要求，上游CDN可以使用CI来通知下游CDN清除内容，从而确保该内容不会被再次交付。
12.在由下游CDN进行一项或多项内容交付活动之后，可能通过LI向上游CDN提供日志交付动作。

以下部分是更具体的例子，来展示如何结合这些操作进行各种交付、控制和一对CDN之间的日志操作。

3.1. 准备工作

最初，我们假设至少有一个CSP和一个代表它进行内容交付的上游CDN进行签约。我们并不特别关心CSP和上游CDN之间的接口，除非
注意到它预计会是和"传统"CDN(非互连)情况相同。现有的机制例如DNS CNAME或者HTTP重定向(第2节)，可以用来引导用户对CSP
的一条内容请求转到CSP选择的上游CDN。

我们假设A提供了一个上游CDN代表CSP服务CDN-Domain cdn.csp.example的内容。我们假设B提供了一个下游CDN。一个终端用户在某
个时间请求URL:
http://cdn.csp.example/...rest of URL...

很可能cdn.csp.example只是其他CDN-Domain(例如csp.op-a.example)的CNAME。尽管如此，以下示例中的HTTP请求假设是上面的示例
URL。(//即虽然请求URL的domain可能是一个CNAME形式，但是下面的例子中的HTTP请求仍然假设使用这个URL，而不用考虑CNAME)

我们的目标是使得CDN B从以上的URL中辨别要服务的内容。在下面的章节中，我们将浏览内容服务的一些场景，以及其他的CDNI操作
，例如下游CDN的内容清除。

3.2. 迭代HTTP重定向示例

在本节中，我们使用从一个上游CDN到一下游CDN的HTTP重定向来说明一个简单示例。这个例子也假设上游CDN和下游CDN都使用了HTTP
重定向；然而，这是独立于跨CDN的重定向方法的选择，所以还可以构造一个替代的例子，仍然显示从上游CDN到下游CDN的HTTP重定
向，但是仍然使用DNS来处理每个CDN内部的请求。

对于这个例子，我们假设A和B已经建立了它们CDN互连的协议，A是上游CDN，B是下游CDN。

该操作允许CDN-Domain peer-a.op-b.example作为上游CDN到下游CDN重定向的目标。我们假设这个域的名称通过某种方式传达给每个
CDN(这个可以通过传输层协议的带外数据或CDNI接口完成)。我们将此域称之为"distinguished" CDN-Domain来传达，它的使用范围
仅限于互连机制；这样的域永远不会被CSP直接使用。(//这种域名只是在互连机制中使用，每个互连CDN可以理解该域名，CSP用不到
这种域名称为distinguished CDN-Domain)

我们假设每个CDN也同意一些distinguished CDN-Domain可以用来从CDN之间获取CSP的内容。在这个例子中，我们使用域名
op-b-acq.op-a.example. (//意思是用op-b-acq.op-a.example作为CDN之间的内容获取域名，即都使用这个域名获取内容)

我们假设operators可以交换 下游CDN准备服务哪种请求 信息。例如下游CDN可能准备服务特定地区的客户请求或者一组IP地址前缀
。这些信息可以通过传输层协议的带外数据或CDNI接口完成。(//每个CDN可以通过CDNI接口来交换每个CDN的服务范围)

我们假定DNS的配置方式如下：

-CP配置为CDN A作为cdn.csp.example的权威DNS。(或者对域名cdn.csp.example返回一个CNAME，A是权威DNS服务器)
-配置A后，一个DNS请求op-b-acq.op-a.example，返回Operator A的地址。
-配置B后，一个DNS请求peer-a.op-b.example/cdn.csp.example，返回Operator B的地址。

图3说明了一个客户请求http://cdn.csp.example/...rest of URL...的处理流程。

图中所示的步骤如下：

1.A的DNS解析器为它的客户发送DNS请求：CDN-Domain cdn.csp.example。返回A的一个Request Router的IP地址。
2.A的Request Router处理HTTP请求，并且意识到这个终端用户最好被另一个CDN服务，特别是由B提供的，因此它返回
一个302重定向消息，这个重定向URL是在在原始URL之前添加由B构造的distinguished CDN-Domain(peer-a.op-b.ex
ample)(注意可能有更复杂的URL，例如将初始CDN-Domain替换成一些不透明句柄)。
(//客户端请求的是cdn.csp.example/...，重定向为peer-a.op-b.example/cdn.csp.example/...)
3.终端用户查询peer-a.op-b.example域名。B的DNS解析器返回B的Request Router的IP地址。注意如果下游CDN的请求
路由使用DNS来代替HTTP重定向，B的DNS解析器会表现为一个请求路由器，并且直接返回交付节点的IP地址。
(//下游CDN的请求路由如果使用DNS的话，会直接返回节点IP地址，如果使用HTTP重定向方式，则还要进行一次重定
向)
4.B的请求路由器处理HTTP请求，并且选择合适的节点服务终端用户的请求，并返回一个302重定向消息，这个消息使用
子域名替换主机名来指向选择的交付节点。
(//客户端请求的是peer-a.op-b.example/cdn.csp.example/...，重定向为node1.peer-a.op-b.example/cdn.csp.example)
5.终端用户发送DNS查询域名node1.peer-a.op-b.example。B的DNS解析器返回交付节点的IP地址。
6.终端用户向B的交付节点发送内容请求。如果命中缓存，不会走6、7、8、9、10步骤，并且内容数据由交付节点直接返回给
用户。缓存未命中的情况下，下游CDN需要从上游CDN(不是CSP)获取内容。distinguished CDN-Domain
peer-a.op-b.example，这个域名向下游CDN表示了需要从上游CDN获取内容;去掉CDN-Domain的前面部分后，得到原始的CDN-
Domain cdn.csp.example，因此下游CDN可以验证这个CDN-Domain属于一个已知的CDN(避免被欺骗作为一个开放代理)。然后
进行CDN请求，就是上面说的内部CDN之间内容获取的CDN-Domain(这种情况下，就是op-b-acq.op-a.example)。
(//B从A获取内容时，使用域名op-b-acq.op-a.example，这个域名是通过CDNI接口协商好的)
7.A的DNS解析器处理这个DNS请求，并且返回A的Request Router的IP地址。
(//Request Router就是一个请求调度处理器，用来返回302或者本身就是一个DNS返回节点地址)
8.A的Request Router处理B交付节点的HTTP请求。A的Request Router通过专用的内容获取域名op-b-acq.op-a.example意识
到这个请求来自一个对等CDN，而不是终端用户。(注意如果没有这个特别规定的内容获取域名，则A把请求重定向到B后就会
有风险，导致无限循环)(//即如果没有这个特定的域名时，A收到B的内容获取请求时，又会把该请求重定向到了B)。A的
Request Router从上游CDN中选择一个合适的交付节点来服务CDN之间的内容获取请求，并且返回一个302重定向消息，这个
消息把CDN之间的内容获取域名替换为A的指向交付节点的子域名。
(//B向A发送op-b-acq.op-a.example请求，重定向为node2.op-b-acq.op-a.example)
9.A的DNS解析器处理DNS请求(//node2.op-b-acq.op-a.example)，并且返回交付节点的IP地址。
10.B从A获取内容。A处理URL其余部分的流程(图上没有显示)：提取标识源服务器的信息，验证该服务器已经注册，并确定CP
拥有源服务器。如果需要它可能在给下游CDN返回内容之前，执行自己的内容获取流程。

这种设计的主要优点是简单：每个CDN只需要知道每个对等CDN的distinguished CDN-Domain，上游CDN把下游的CDN-Domain
放到URL上面做为重定向的一部分(第2步)(//在URL前面添加前缀作为重定向URL)。下游CDN从URL里面取出CDN-Domain后，得到
上游CDN可以正确处理的 CDN-Domain(//意思就是下游CDN把URL前面的部分去掉后，剩下的部分就是上游CDN可以处理的部分)
。CDN不需要知道其他CDN URL的内部结构。此外，CDN间的重定向完全由单个HTTP重定向支持(//意思是CDN间的重定向，一个
HTTP重定向消息就够了);CDN不需要知道其他CDN的内部重定向机制(即基于DNS或者基于HTTP)。

一个缺点是终端用户的浏览器被重定向到一个和新的和原始URL域名不同的URL。这有时候会对端点的安全或验证机制产生影响
。例如，如果期望浏览器发送任何和那个域名相关的cookie时，重要的是任何重定向URL需要有相同的域名(例如csp.example)
。作为另一个例子，一些视频播放器对跨域策略进行强制验证，因此需要CDN重定向的域名适应这种需求。这些问题通常是可
以解决的，但是解决方案会使示例变得复杂，因此在本文档中不再进一步讨论。

我们注意到这个例子开始说明一些CDNI可能需要的接口，但是这个示例并不需要用到所有的接口。例如，从下游CDN获取它可
以服务的客户端IP集合或者地理区域的信息，这关系到请求路由的方面(特别是CDNI网点&能力上报接口)。重要的配置信息例
如重定向的识别名称和CDN之间的获取也可以通过CDNI接口(例如，CDNI控制接口)传输。这个例子也展示了现有的基于HTTP的
方法如何用于获取接口。可以说，CDNI所需绝对最小元数据是获取内容所需要的信息，并且这个信息在本例中是通过"in-band"
URL处理，在HTTP 302响应中。这个例子也假定CSP不需要使用任何分发策略(例如时间窗口或者地理限制)或者互连CDN所需要
使用的传递处理。因此，这个例子中没有明确的CDNI元数据接口。也没有讨论明确的CDNI日志接口。

我们还注意到，没有表明如何决定一个请求应该被重定向到下游CDN还是被上游CDN服务。它可以简单的在一个前缀列表中检查
客户端IP地址，或者有更复杂的考虑，涉及广泛的因素范围，例如客户端地理位置(可能有第三方服务决定)、CDN负载或者特定
的业务规则。

这个例子使用"迭代"CDNI请求重定向方法。也就是说，上游CDN通过把客户端重定向到下游CDN的Request Router来作为请求重定
向功能的一部分，然后下游CDN把客户端重定向一个合适的代理作为重定向功能的剩余部分。如果下游CDN的request routing使用
HTTP重定向，这样终端用户会体验两个连续的HTTP重定向。想比之下，一个可选的方法——"递归"CDNI请求重定向有效的把这两个
连续的HTTP重定向合并成一个，直接给终端用户发送下游CDN的代理节点。这种"低估"CDNI请求路由方法在下一节讨论。

上面的例子使用的HTTP，迭代HTTP重定向机制，可以以类似的方式在HTTPS上工作。为了确保终端用户的HTTPS请求在重定向路径
中不会被降级为HTTP，有必要对每个Request Router，从最初的上游CDN的Request Router到最终的下游CDN的代理，对收到的HTTPS
请求响应一个包含HTTPS URL的HTTP重定向。应该注意的是，使用HTTPS会增加总的重定向流程时间和增加Request Router的负载，
特别是当重定向路径包括许多重定向，从而许多安全套接字层(SSL/TLS)会话。在这种情况下，递归HTTP重定向机制，如下一节描述
的例子中，或许可以帮助减少这种问题。

(//3.2说明了迭代HTTP重定向的例子，迭代会产生很多重定向，因此下面介绍递归HTTP重定向)

3.3. 递归HTTP重定向示例

下面的例子基于前一个示例来说明请求路由接口(具体说是CDNI请求路由重定向接口)启用"递归"CDNI请求路由的用法。我们建立在
基于HTTP重定向方法上，因为它清楚的说明了原则和好处，但是同样可能在基于DNS的重定向中执行递归重定向。

与前面的例子相反，operators不需要预先同意，作为重定向目标服务的CDN-Domain，从上游CDN到下游CDN。我们假设operators对
CDN之间的用来使下游CDN获取CSP内容使用的distinguished CDN-Domain达成一致。在这个例子中，我们使用op-b-acq.op-a.example。
(//意思是CDN之间协商好获取内容的CDN-Domain，这里就是op-b-acq.op-a.example)

我们假设operators也交换 下游CDN准备服务哪种请求 信息。例如，下游CDN可能准备服务特定区域或者一组IP地址前缀的用户请求。
这些信息可以再次由传输层协议的带外数据或者定义的协议提供。

我们假设DNS按如下方式配置：
-CP配置为CDN A作为cdn.csp.example的权威DNS。(或者对域名cdn.csp.example返回一个CNAME，A是权威DNS服务器)
-配置A后，一个DNS请求op-b-acq.op-a.example，返回Operator A的地址。
-配置B后，一个DNS请求node1.op-b.example/cdn.csp.example，返回交付节点的IP地址。注意可能有多个这样的交付节点。

图4说明了一个客户请求http://cdn.csp.example/...rest of URL...的处理流程。(//原文有误，写的图3)

图中所示的步骤如下：
1.Operator A的DNS解析器处理客户基于CDN-Domain cdn.csp.example的DNS请求。它返回一个A的Request Router的IP地址。
2.Operator A的Request Router处理HTTP请求，并且意识到这个终端用户最好被另一个CDN服务——具体是由Operator B提供的
——所以它向Operator B查询CDNI请求路由重定向接口，提供包括URL请求的关于请求的信息集合。Operator B响应一个交付
节点的DNS主机名。
(//Operator A向Operator B的请求路由重定向接口发送一些请求信息，Operator B返回它里面一个代理节点的主机名(子域名))
3.Operator A对从RI获取到的新的URL，响应一个302重定向消息。
4.终端用户使用DNS查询刚收到的域名(node1.op-b.example)。B的解析器返回响应交付节点的IP地址。注意，自从使用RI从B获
取到交付节点的主机名后，之后不应该有更多的重定向(对比上面描述的迭代方法)。
5.终端用户从B的交付节点请求内容，可能会未命中缓存。在这种情况下，需要从上游CDN(非CSP)获取内容。 distinguished
CDN-Domain op-b.example向下游CDN标明了这个内容需要从另一个CDN获取;去掉CDN-Domain(node1.op-b.example/cdn.csp.example)
的前部分后，得到原始的CDN-Domain cdn.csp.example。下游CDN可能验证这个CDN-Domain属于一个对等的CDN(避免被欺骗为开
放代理)。然后它对CDN之间获取内容的"distinguished" CDN-Domain发送一个DNS查询请求，如上面协商的(在这里是
op-b-acq.op-a.example)。
6.Operator A的DNS处理DNS请求，并且返回Operator A的Request Router的IP地址。
7.Operator A的Request Router处理Operator B的交付节点发来的HTTP请求。Operator A的Request Router通过CDN间的专用内容
获取域名(op-b-acq.op-a.example)意识到这个请求是来自一个对等CDN而不是一个终端用户。(注意如果没有这个特别规定的内容获取
域名，则A把请求重定向到B后就会有风险，导致无限循环)。Operator A的Request Router从上游CDN中选择一个合适的交付节点来服
务CDN之间的内容获取请求，并且返回一个302重定向消息，这个消息把CDN之间的内容获取域名替换为A的指向交付节点的子域名。
8.Operator A意识到DNS请求来自对等的CDN而不是一个终端用户(根据内部的CDN-Domain判断)，因此返回交付节点的地址。(注意如果没有
这个特别规定的内容获取域名，则A把请求重定向到B后就会有风险，导致无限循环)
(//意思就是Operator A根据请求的域名判断是CDN请求数据还是终端客户请求数据，CDN请求则返回交付节点的地址，终端用户则是以上
流程)。
9.Operator B从Operator A获取内容。Operator A处理URL其余部分的流程(图上没有显示)：提取标识源服务器的信息，验证该服务器已经
注册，并确定CP拥有源服务器。如果需要它可能在给下游CDN返回内容之前，执行自己的内容获取流程。

递归重定向具有优势(超过迭代重定向)，从终端用户的角度看更加透明，但是缺点是对其他CDN暴露更多的内部结构(特别是边缘缓存服务器
的地址)。想比之下，迭代重定向不需要下游CDN向上游CDN暴露它的边缘缓存地址。

这个例子在CDN A和CDN B使用基于HTTP的重定向，但是可以在每个CDN中使用基于DNS重定向来构建类似的例子。因此，这里要拿走的关键点
仅仅是终端用户只看到了某个类型的单个重定向，和之前的例子中(迭代重定向)的两次重定向相反。
(//意思是这个例子和上面的迭代重定向一样，在CDN中都使用了HTTP重定向，所以两者仅有的不同点就是重定向次数不一样)

RI的使用要求请求路由机制被适当的配置和引导，但是这里没有描述。更多对接口的引导的讨论在第4节提供。

3.4 基于DNS迭代重定向的示例

在本节中，我们将说明上游CDN到下游CDN(也包括下游CDN和上游CDN内部的请求路由)重定向时使用基于DNS重定向的简单例子。
正如2.1节指出的，基于DNS的重定向对基于HTTP的重定向具有优势也有缺陷。(优势就是HTTP重定向服务器对终端用户是透明的
而DNS不是，缺点就是DNS的Request Router看不到客户端的IP地址)

和之前一样，Operator A需要得到下游CDN愿意或者有能力服务的请求集合(例如下游CDN的网点包括了哪些客户端IP前缀或地理
区域)。我们假定Operator B已经向Operator A公布了可以用来构建distinguished CDN-Domain的一些唯一的标识，如下面详细
解释。(这个标识只需要在Operator A是唯一的，但是全局唯一的标识符，例如分配给B的自治系统(AS)号码，用这种方法很容易
实现)。另外，Operator A获取了Operator B对外可见的重定向服务器的NS记录。此外，和之前一样，一个distinguished CDN-D
omain，例如op-b-acq.op-a.example，必须被分配以用来CDN之间的内容获取。

我们假定DNS的配置如下：
-CSP配置为Operator A作为cdn.csp.example的权威DNS。(或者对域名cdn.csp.example返回一个CNAME，A是权威DNS服务器)
-当上游CDN发现一个请求更适合被下游CDN服务时，它返回一个CNAME和"b.cdn.csp.example"的NS记录，"b"是分配给B的唯一
标识符(例如，可能是分配给Operator B的AS号码)。
-下游CDN配置后，一个DNS请求"b.cdn.csp.example"返回下游CDN的交付节点。
-上游CDN配置后，一个DNS请求"op-b-acq.op-a.example"返回上游CDN的交付节点。(//这个是CDN间获取内容的CDN-Domain)

图5描述了DNS和HTTP请求的交换。和图3中主要的不同在于缺少HTTP重定向和对终端用户的透明度。

图中所示的步骤如下：

1.Operator A的Request Router处理CDN-Domain cdn.csp.example的DNS请求，并且意识到这个终端用户最好被另一个CDN服务。
(这可能取决于用户LDNS的IP地址，或者下面介绍的其他信息)。Request Router返回一个DNS CNAME响应——把Operator B的
区别标识符加到原始CDN-Domain的前面(例如b.cdn.csp.example)。
2.终端用户向Operator A的DNS服务器发送修改后的CDN-Domain(例如b.cdn.csp.example)的查询。Operator A的Request Router
处理DNS请求并且通过发送一个NS记录加上指向Operator B的DNS服务器的胶水记录来返回一个授权记录b.cdn.csp.example。(
这个额外的步骤是必要的，因为典型的DNS实现不会使用NS记录当它和CANME记录一起发送时，因此需要两部来实现)

(//[1]客户端向Operator A请求cdn.csp.example，返回cdn.csp.example CNAME b.cdn.csp.example
//[2]客户端向Operator A请求b.cdn.csp.example，返回b.cdn.csp.example NS ns1.b.cdn.csp.examle
// ns1.b.cdn.csp.examle IN A 192.168.0.1
//第一步不能在响应里面加上NS和胶水记录，这样的话LDNS不会向NS发起查询
)
3.终端用户向Operator B的DNS服务器发送修改后的CDN-Domain(例如b.cdn.csp.example)查询。使用第2步收
到的NS和A/AAAA记录，这导致B的Request Router返回一个合适的交付节点。(//这里的终端用户应该是LDNS)
4.终端用户向B的交付节点请求数据。请求URL包含域名cdn.csp.example(注意返回的CNAME不会影响到URL)。至
此，交付节点得到了终端用户的正确IP地址，并且可以发送一个HTTP 302重定向如果第2步和第3步的重定向不
正确时(//因为第2和第3步看不到用户的IP地址，所做的重定向可能不准确)。否则，B验证这个CDN-Domain是否
属于一个已知的peer(避免被欺骗)(//意思是根据客户请求的URL里面的域名判断是否来自其他CDN)。之后它执行
一个如上所说的"内部"CDN-Domain的DNS请求(op-b-acq.op-a.example)。(//获取内容的CDN-Domain)
5.Operator A意识到DNS请求来自peer CDN，而不是终端用户(根据域名判断)，因此返回它里面一个交付节点的地址。
6.Operator A给下游CDN服务内容。尽管没有显示，Operator A处理URL其余部分的流程：提取标识源服务器的信息，
验证该服务器已经注册，并确定CP拥有源服务器。

这种方法的优点是对终端用户更加透明，并且对基于HTTP来说，需要更少的往返流程(最坏的情况下，即DNS没有缓存
任何所需的信息)。一个潜在的问题是上游CDN依赖于有能力对DNS请求中的终端用户地址学习正确的服务此用户的下游
CDN。在标准的DNS操作中，上游CDN将会只获取到客户端LDNS的地址，这个地址不能保证和客户端在同一个网络(或者
地理区域)。如果不是(例如终端用户使用了全局DNS服务)，那么上游DCN将不能确定服务该用户的合适的下游CDN。在这
中情况下，假设上游CDN有能力检测到那种情况，一种选择是，上游CDN对待终端用户作为任意用户，而不去连接peer CDN。
另一个选择是，上游CDN"退回"到一个基于HTTP重定向策略(即，使用第一方法)。注意这个问题会影响到现有的依靠DNS决定
如何重定向客户端请求的CDN，但是对于CDNI却不那么严重，因为LDNS通常和下游CDN在同一个网络中。

和前面的例子一样，这个例子部分说明了CDNI中涉及的各种接口。Operator A可以通过CDNI的网点&能力上报接口动态学习
Operator B愿意和有能力所服务的前缀集合或者区域。用于获取内容的distinguished name和Operator B的标识符也可以
通过CDNI接口传输(或者，另一个可选择的方式是静态配置)。(//有歧义)。和之前一样，最小的元数据足以获取内容作为
重定向流程的一部分，以及标准的HTTP用来CDN之间的内容获取。本例中没有明确的讨论CDNI日志接口。

3.4.1.使用DNSSEC的注意事项

虽然可以使用DNSSEC结合上面介绍的基于DNS的迭代重定向机制，需要注意的是上游CDN可能需要即时对记录签名，当CNAME返
回时，因此这样的提供签名，可能对每个到来的查询会不同。尽管没有什么可以阻止上游CDN执行这样的即时签名，这在计算
上是昂贵的。在这种多个下游CDN的情况下，因此会返回多个不同的CNAME，是相对稳定的，一个可选的解决方案是上游CDN对
所有可能的CNAME预先生成签名。对每个到来的查询，上游CDN可以决定合适的CNAME并且和与它关联的预生成签名一同返回。
注意：在后一种情况下，维护序列号和SOA的签名可能是一个问题，从技术上讲，它应该在每次使用不同的CNAME时改变(序
列号和SOA前面)。然而，在实践中，直接的SOA查询相对较少，上游CDN可以推迟递增序列号和对SOA重新签名，直到它被查
询，然后即时执行。

(//意思是对CNAME的预先签名可以降低计算消耗，每当使用不同的CNAME，序列号和SOA签名都应该更改，然而正常情况下，
直接请求SOA的情况很少，所以使用不同CNAME时，先不增加序列号和对SOA重新签名，而是当收到查询时再执行序列号的增
加操作和SOA重签名)

注意前一节中第2步中，NS记录和胶水记录通常情况下需要和Operator B管理它们的权威域的记录相同。即使它们不同，也不
会导致DNS解析过程失败，但是LDNS会首选使用它缓存的权威数据来进行后续查询。这种前后矛盾的操作是普遍问题，但是这
种结构是重要的，因为上游CDN将依赖这种特性来使得重定向结果和预期的那样。一般来说，管理员有责任保持它们的一致性。

(//意思是Operator A回给LDNS的NS和glue记录和Operator B权威域的记录不一样，这样LDNS会优先使用缓存的权威数据。虽然
这是个问题，但是上游CDN需要这种机制来进行重定向。zzsb)

3.5 动态网点发现示例

有能力动态发现下游CDN愿意和有能力服务的请求集合，这种情况是有益的。例如，一个CDN当前可能有能力服务一个特定的客户
端IP前缀集合，但是一段时间后，那个集合可能因为IP网络的拓扑和路由策略而改变。下面的例子说明了这种能力。我们选择使
用基于DNS重定向的示例，但是基于HTTP重定向也可以很好的使用这个方法。

这个例子和图5的不同之处，只是添加了RI请求(第2步)和对应的响应(第3步)。RI REQ可以是一个例如"你可以对这个IP前缀的客
户端服务吗?"或者"提供你当前可以服务的客户端IP前缀列表"。在任何一种情况下，Operator A可能会缓存那个响应来避免查询
相同的问题。或者，另外，Operator B可以主动上报它愿意和有能力代表Operator A的请求集合信息；在这种情况下，Operator
B可以主动发布RR/RI REPLY消息，而非对RR/RI REQ消息的直接响应。(//即不需要收到请求,直接发出响应)(注意从DNS请求中确
定客户端子网的问题，正如上面描述的，和第3.4节完全一样)。

当Operator A收到了RI响应，它现在就能确定Operator B的CDN是一个合适的下游CDN，因此它重定向时会考虑这个候选CDN。如果
选择了那个下游CDN，对请求的重定向和服务项之前那样进行(即在缺少动态获取网点能力时的流程)。(//意思就是和之前的流程一
样，之前介绍的流程都没有动态获取网点的步骤)

3.6. 内容清除示例
下面的例子说明了下游CDN如何使用CDNI控制接口获取一项内容的预定位。在这个例子中，用户请求一个特定的内容，并且Operator
A到Operator B对这个请求进行相应的重定向，可能(或可能没有)较早的发生。然后，在某个时间点，上游CDN使用CI请求特定的URL
请求那个内容在下游CDN中删除。下面的示例图说明这个操作。应该注意的是，上游CDN通常不知道下游CDN是否缓存了给定的内容项。
但是，它可以发送内容清除请求来确保没有剩余缓存的版本可以满足任何它可能有的合同义务。

(//就是上游CDN通知下游CDN删除某个内容项。)

CI用于上游CDN到下游CDN传输删除之前获取的内容的请求。请求中的URL指定了需要清除的内容。这个例子对应到基于DNS重定向的场景
，如3.4节。如果已经使用了基于HTTP的重定向，清除的URL将是这种格式:peer-a.op-b.example/cdn.csp.example/...

下游CDN期望给上游CDN确认消息，如图中的CI OK消息，完成目标内容的清除来自下游CDN中的所有缓存服务器。

3.7. 预定位内容获取示例

下面了例子说明了如何使用CI在下游CDN中预定位一个内容项。在这个例子中，Operator A使用CDNI元数据接口请求那个被特殊URL标识的
内容，预定位到Operator B CDN。
(//上游CDN A使用CI把内容预定位到CDN B中，意思就是提前把内容发送到下游CDN，这样用户被重定向到下游CDN时就可以直接服务内容)

图中所示的步骤如下：
1.Operator A使用CI向Operator B请求预定位一个由URL指定的特别的内容项。Operator B通过确认响应来表示它愿意执行此操作。

第2步和第3步和第3节中第5步和第6步完全相同，只是这一次的步骤由预定位产生，而不是缓存缺失。
(//意思是第3节是由于下游CDN没有命中缓存，所以要从上游CDN获取内容，而这里是由于预定位，从上游CDN获取内容。虽然触发方
式不同，但是流程是一样的)

步骤4、5、6、7和第3节中的步骤1、2、3、4完全一样。只是这一次，Operator B的CDN可以在不触发动态内容获取时，直接服务终端
用户的请求，因为下游CDN已经预定位了内容。注意，根据下游CDN的操作和策略，预定位的内容可能被下游CDN预定位到所有的缓存服
务器，或者其中一部分缓存服务器。在后一种情况下，当缓存的内容没有被预定位时，CDN间的动态内容获取可能发生在下游CDN内部;
然而，这种CDN内部的动态获取不会涉及到上游CDN。
(//预定位而已，如果下游CDN的缓存服务器没有全部预定位到内容，例如边缘缓存A预定位到内容，边缘缓存B没有预定位，则边缘B服
务用户请求时从边缘A获取内容，而不是从上游CDN获取)

3.8. 异步CDNI元数据示例

在本节中，我们通过一个简单的示例来说明异步交换CDNI元数据的场景，下游CDN在响应的内容请求之前获取内容的CDNI元数据。下面
的例子假设CDN之间的重定向基于HTTP，并且使用递归的CDNI请求路由，如3.3节所示。然而，CDNI元数据的异步交换同样适用于基于DNS
的CDN间重定向和迭代请求路由(这种情况下，CDNI元数据在消息流的处理中可能会稍微有所不同)。

(//异步CDNI元数据交换，可以用于CDN之间基于HTTP或者DNS重定向的场景，和CDN之间递归或者迭代请求路由)

图中所示的步骤如下：
1.Operator A使用CI向Operator B触发可用性信号。 (//意思是Operator A向Operator B触发预定位信号)
2.Operator B对此触发信号回复确认。
3.Operator B使用MI向Operator A请求最新的元数据。
4.Operator A对请求的元数据进行响应。本文档不限制CDNI元数据信息的具体形式。对于这个例子的目的，我们假设Operator A向
Operator B提供的CDNI元数据标识了下面的内容：
*对于被引用CDN-Domain，CDNI元数据对任何内容都是可用的。
*CDNI元数据由交付节点需要强制执行的分发策略或者特定的请求验证机制(例如，URI签名或者令牌验证)。
5.内容请求和平常一样。
6.CDNI请求路由重定向请求(RI REQ)由Operator A的CDN发布，如3.3节讨论的。Operator B的Request Router可以访问和请求内容
相关的CDNI元数据，并且这个内容在1-4步已经被预定位。其可能或可能不会影响到响应。
7. Operator B的Request Router发出一个CDNI请求路由重定向响应(RI RESP)，如3.3节中描述。
8.Operator A执行内容重定向如3.3节中讨论的。(//原文有误，写成Operator B)
9.收到终端用户的内容请求后，交付节点检测到之前获取的CDNI元数据对请求的内容是可用的。按照本例中指定的CDNI元数据，交付
节点将涉及到在服务内容之前进行适当的请求认证机制(这种详细的认证没有显示)。
10.假设请求认证成功，则像3.3节描述的，进行内容数据服务(可能在CDN间内容获取之前)。

(//首先Operator A向Operator B发送一个预定位消息，Operator B回复确认。
//之后Operator B请求内容的元数据，Operator A响应元数据
//之后Operator A收到客户端的内容请求
//之后Operator A向Operator B发送路由请求重定向，Operator B响应此请求
//之后Operator A给客户端发送重定向
//之后客户端向Operator B请求内容 (//此处可能有Operator B向Operator A请求内容的步骤，因为Operator B可能还没有要服务的内容)
//之后Operator B服务内容)

(//异步获取元数据就是在没有收到客户端请求时，主动获取
//同步获取就是收到客户端请求时，触发获取)

3.9. 同步CDNI元数据获取示例
在本节中，我们通过一个简单的示例来说明同步获取CDNI元数据的场景，下游CDN处理第一个请求时，获取对应内容的CDNI元数据。正如上一节中，
这个例子假设CDN之间使用了基于HTTP的重定向和递归的CDNI请求路由(如3.3节所示)，但是动态的CDNI元数据获取也适用于其他的各种请求路由类
型。

图中所示的步骤如下：
1.正常的内容请求。
2.和之前例子一样的RI请求。
3.在收到CDNI请求路由请求时，Operator B的CDN启动同步获取处理终端用户所需的CDNI元数据。我们假设元数据服务器的URL在之前通过带外的手
段得到。
4.收到CDNI元数据请求后，Operator A的CDN做出响应，创建对Operator B的CDN可用的相应的CDNI元数据信息。这个元数据被Operator B的CDN处理，
在给请求路由请求应答之前(在一个简单的情况下，元数据可以只是一个允许或拒绝的响应，在这种特定的请求中)。
(//意思是A给B发送了一个请求路由请求，B不立刻响应，而是B先请求A的元数据，收到A元数据响应后，最后再响应最开始的请求路由请求)
5.正常响应RI请求。
6.给终端用户发送重定向消息。
7.Operator B的交付节点收到用户的请求。
8.交付节点对终端用户的内容请求触发额外的CDNI元数据的动态获取。注意存在不发生此步骤的情况，例如，元数据已经在之前获取过。
9.Operator A的CDN响应对Operator B可用的相应的CDNI元数据的CDNI元数据请求。这个元数据影响到Operator B如何处理终端用户的请
求。
10.服务内容(可能在CDN之间的内容获取之前)如3.3节所示。 (//因为此时只是获取到了元数据，但是不一定有内容)

(//内容的CDNI元数据对这个内容进行了描述，例如包括如何服务客户，上面的流程都在交互元数据，但是没有交互内容，所以最后一步
给用户服务内容之前，应该有一个内容获取的步骤)

3.10 多个上游CDN的内容和元数据获取
单个下游CDN可能从多个上游CDN收到用户的请求。当一个下游CDN收到终端用户的请求，它必须确认可以获取请求内容的上游CDN的身份。
(//收到用户请求时，需要知道从哪个上游CDN获取用户请求的内容)

理想情况下，终端用户请求的获取路径将遵循请求的重定向路径。下游CDN需要从给它重定向的上游CDN中获取内容。

确定采集路径需要下游CDN对基于终端用户的请求信息重建重定向路径。(//即修改用户请求的url，得到采集路径)。对基于重定向的方法：HTTP或者
DNS，这个重建重定向路径的方法会有所不同。(//即基于HTTP重定向的重建重定向方法和基于DNS重定向的重建重定向方法不同)

HTTP重定向中，当收到终端用户请求时，重写的URL需要包含足够的信息来使得下游CDN可以直接或间接地确定上游CDN。根据URL在重定向时如何被重
写，HTTP重定向方法可以被更进一步地细分为：有站点聚合的HTTP重定向和没有站点聚合的HTTP重定向。有站点聚合的HTTP重定向隐藏了原始CSP的身
份。没有站点聚合的HTTP重定向不试图隐藏原始CSP的身份。使用这两种方法，重写的ULR包括了识别接近的邻居上游CDN的足够信息。

DNS重定向中，下游CDN收到发布的URI(而不是重写的URI)，并且没有足够的信息识别合适的上游CDN。下游CDN可以通过检查上游CDN发送的CDNI元数据
来缩小范围，确定哪个上游CDN管理着请求内容的托管元数据。如果只有一个上游CDN托管着请求内容的元数据，下游CDN可以假设那个重定向请求来自
这个上游CDN并且从这个上游CDN采集内容。如果有多个上游CDN托管着请求内容的元数据，下游CDN可能需要准备好信任任何一个上游CDN来采集内容。
如果下游CDN没有准备好信任任何上游CDN，那么需要确保通过使用带外约定，对于给定的内容，只有一个上游CDN把请求重定向到下游CDN。

内容获取可能在内容元数据获取之前进行。如果可能，元数据的获取路径应该也跟随重定向路径。此外，我们假设元数据，在基于HTTP重定向时是基于
重写URI索引的，在基于DNS重定向时是基于发布的URI索引的。因此，RI和MI是紧密结合的，请求路由的结果(一个指向下游CDN的重写URL)作为元数据
查询的输入参数。如果内容元数据包括采集内容的信息，那么MI也和采集接口紧密结合，元数据查询的结果(采集URL)作为内容采集的输入参数。

4.主接口

图1列出了CDNI工作组范围内的主要接口，还要其他几个。这些接口的详细规范放到其他文档，参见RFC 6707和RFC7337对接口的一些讨论。

图1没有显示用户和CSP之间的接口。虽然对于CDNI来说那个接口不在范围之内，但是值得强调的是它确实存在并且可以提供有用的功能，例如端
到端的性能监控和一些认证授权的形式。

还有一个重要的接口，位于用户和上游CDN以及下游CDN(图1中表示为"Request"接口)的请求路由功能之间。正如在之前的例子中看到的，那个接口
可以用来作为传递元数据的一种途径，例如下游CDN从上游CDN获取内容所需要的最小信息。

在本节中，我们将提供每个CDNI接口的功能概述，并且讨论它们如何配合到整体方案中。我们也权衡设计调查，探讨几个跨接口的关注点。我们从
一个权衡影响到所有接口的检查来开始——in-band或者out-of-band通信的使用。
(//)

4.1. In-Band接口 VS Out-of-Band接口

在到达各个接口之前，我们注意到有一个高级别的设计选择，涉及到现有的in-band通信信道和定义新的out-of-band接口。

在peer CDN之间，通信的信息使用现有的in-band协议需要完成各种互连功能。HTTP 302重定向的使用是一个在in-band中(嵌入到URI中)实现请求路
由方面的示例。注意使用现有的in-band协议并不意味着CDNI接口是空的;用来完成各种接口功能的协议仍然有必要指定规则(约定)。

除了HTTP重定向外，还有其他的in-band通信。例如，代理服务器使用的许多HTTP指令也可以用来对peer CDN之间通知各自的缓存活动。其中，一个
特别相关的是If-Modified-Since指令，用来和GET方法一起使用：如果在这个字段指定的时间内请求的对象未被修改，对象的副本将不会被返回，相
反，会返回一个304(not modified)响应。

4.2. 跨接口的考虑

尽管CDNI接口大部分是独立的，但有一套在所有接口上一致地执行约定。在这之中最重要的是如何命名资源，例如，CDNI元数据和控制接口对给定的指令
如何识别资源集合，或者CDNI日志接口识别资源集合。

理论上，CDNI接口可以明确识别每个独立的资源，实际中，使用类似的方式命名资源集合(URI集合)。例如，URL集合可以通过CDN-Domain(即URI起始处的
FQDN)或者URI-Filter(即CDN-Domain包括URL子集的正则表达式)来标识。换句话说，CDN-Domains和URI-Filters提供了一个统一的含义来聚合URL集合(和
子集)，为其中一个CDNI接口定义操作范围。

4.3 请求路由接口

请求路由接口包括两个部分：异步接口用来使下游CDN向上游CDN上报网点和能力(标识为FCI)，允许上游CDN决定是否向这个下游CDN重定向特定的用户请求
；同步接口用来使上游CDN把用户请求重定向到下游CDN(标识为RI)。(这有些类似于IP中的路由和转发)

如第3节所示，请求路由的RI部分可以由DNS和HTTP实现。命名约定可能由CDN之间的通信——是否应该路由一个请求或者服务内容来完成。

我们还注意到，RI在递归重定向中起着重要作用，如3.3节所示。它只是用一个重定向步骤(从用户角度看)，就可以使得用户被重定向到正确的下游交付节点。
这可能对互连CDN的链超过两个CDN时有特别的价值。对RI更进一步的讨论，见[REDIRECTION]。

为了支持这些重定向请求，每个CDN之间交换附加信息是必须的，这由请求路由的FCI部分处理。根据需要支持的方法，这些可能包括：
-operator的唯一ID(operator-id)或者有区别的CDN-Domain。
-operator的NS记录，一套对外可见的Request Routers。
-下游CDN的附加能力，例如有能力支持不同的CDNI元数据请求。

注意下游CDN愿意服务的请求集合，在某些情况下可以是静态的(例如，一组IP前缀)，因此可以离线交换，甚至可以作为对等协议的一部分进行协商。然而，
它可能更具有动态性，这种情况下有FCI支持的交换会很有帮助。更进一步的网点&能力上报接口讨论可以看[FOOTPRINT-CAPABILITY]。

4.4 CDNI日志接口

上游CDN对重定向到的下游CDN的内容交付具有可见性是有必要的。这允许上游CDN根据下游CDN缓存的多个交付内容，对它的客户进行合适的计费，以及向这些
CP上报准确的流量统计。这是LI的角色。

其他和CDNI可能相关的操作数据也可以通过LI交换。例如，下游CDN可以向上游CDN上报它获取的内容数量，和代表上游CDN缓存的内容消耗了多少缓存容量。

流量日志可以简单的离线交换。例如，下面流量日志和Apache日志文件格式有些偏差，其中条目包括以下字段：
-Domain 原始服务器的完整域名
-IP address 请求的客户端的IP地址
-End time 传输的结束时间
-Time zone end time的时区
-Method 传输的自身命令(例如GET、POST、HEAD)
-URL 请求的URL
-Version 协议版本，例如HTTP/1.0
-Response 表示传输结果的响应代码
-Bytes Sent 发送给客户端的字节数
-Request ID 此传输的唯一标识符
-User agent 用户代理，如果提供的话
-Duration 以毫秒表示的传输持续时间
-Cached Bytes 从缓存中服务的字节数
-Referrer 客户端中的referrer字符串，如果提供的话

其中，只有Domain字段对下游CDN是不明确的——它被上游CDN设置为CDN-Domain，而不是真实的原始服务器。因此，这个字段可以用来过滤流量日志，只有和上游
CDN相匹配的条目会被上报到相应的operator。更进一步的LI讨论，可以见[LOGGING]。

一个未解决的问题是谁来过滤。一种选择是下游CDN过滤它自己的日志，并向每个上游CDN直接发送相关的记录。这需要下游CDN知道属于每个上游节点的
CDN-Domain。如果这个信息(CDN-Domain信息)已经被另一个接口在peer之间(//CDN之间)交换，则可以直接进行上报。如果(//CDN-Domain信息)不可用，
并且operators 不希望向他们的peer上报CDN-Domain，则第二个选择是对每个CDN发送它的非本地流量记录和它服务的CDN-Domain集合到一个独立的第三
方机构(即CDN交换)，这个第三方代表每个参与的CDN负责过滤、合并和分发流量记录。

第二个未解决的问题是实时流量信息。例如，除了离线的流量日志，准确的实时流量监控也可能是有用的，这是这些信息要求下游CDN每当它从缓存中服务
上游内容时通知上游CDN。下游CDN可以做这些，例如，每当它收到终端用户的HTTP GET请求时向上游CDN发送一个传统的HTTP GET请求(If-Modified-Since)
。这允许上游CDN记录那个请求为实时流量监控的目的。上游CDN也可以使用这个信息来验证后面从下游CDN收到的流量日志。

在LI中，另一个折衷的设计是聚合度或数据汇总。一种适合的情况是HTTP自适应流(HAS)的交付，因为大量的单独请求会导致大量的日志信息。这种情况在
下面讨论，但是其他的聚合形式也可能是有用的。例如，可能诸如字节传递的批量指标每小时就足够了，而不是每个请求的详细日志。看起来可能有一系列
的日志粒度需求，以及指定类型和聚合度所需要的途径。

4.5. CDNI控制接口

CDNI控制接口最初用于引导其他的接口。作为一个简单的例子，它可以用来项上游CDN提供下游CDN日志服务器的地址，以便引导CDNI日志接口。也可以用于，
例如建立其他接口的安全关联。

CI的另一个功能是允许上游CDN对下游CDN进行预定位、重新验证或者清除元数据和内容。这些操作，有时候统称为"触发接口"，更进一步的讨论在[CONTROL
-TRIGGERS]。

4.6 CDNI元数据接口

CDNI元数据接口的角色是使得上游CDN向下游CDN传输CDNI分发元数据。这些元数据包括地理-阻塞限制、可用性窗口、访问控制策略等等。也可能包括便于下
游CDN采集内容的信息(例如，内容的替代源，从源采集内容时所需的认证信息)。完整的CDNI元数据接口讨论，见 [METADATA]。

某些分发元数据可能部分使用in-band的模拟机制。例如，对于任何地理阻塞限制或可用性窗口的情况，上游CDN可以选择只有当下游CDN上报的交付网点
对请求的URL是可接受时，向下游CDN重定向请求。同样，只有当当前时间有可用性窗口时才会被重定向。然而，这种方法会有缺点，例如对阻止在时间窗
口之外的重播，或者利用下游CDN覆盖比地理-阻塞限制更广范的网点。

同样，一些访问控制的形式也可以通过每个使用HTTP指令执行的请求执行。例如，能够对一个有条件的GET请求做出响应，给了上游CDN一个影响下游CDN如何
交付内容的机会。最小的情况是，上游CDN可以使下游CDN之前缓存的内容无效(即清除内容)。

所有这些带内技术都可以说明上游CDN可以对一些访问控制策略做出选择(以增加CDN之间通信负载为代价)，而不是使用MI向下游CDN授权执行。作为一个结果
，MI可以向上游CDN提供一种方式，来表达它保留执行力的期望。例如，这可以通过在元数据中包含一个关联到确地内容的"check with me"标记。这种通过
各种CDN之间的采集协议(例如HTTP)的带内技术的实现，需要更进一步的研究，并且可能需要小范围的扩展或者对采集协议改变语义。

4.7. HTTP自适应流的考虑

我们考虑HTTP自适应流(HAS)和对CDNI接口的影响，因为大对象(例如视频)被分割成一系列的小的独立的块。对接下来每个说明，更彻底的讨论包括权衡的可选
设计的概述，可以见RFC 6983。

首先，对于内容采集和文件管理，对CDNI接口来说已经超出范围，但是尽管如此，这些关系到整体运行，我们假设对于处理大量的块不需要有附加的措施。这意
味着下游CDN对不同的块没有明确它们之间的关系，并且下游CDN把每个块当做独立的内容项来处理。结果就是上游CDN和下游CDN之间的内容获取也是发生在每个
块的基础上。这种方法符合RFC 6983中提出的建议，这也表明了将来可能会对这方面进行改进。

(//意思是上游CDN和下游CDN之间的内容获取，不需要有附加的措施，下游CDN只要当做每个块是独立的就可以)

第二，关于请求路由，我们注意到HAS清单文件可能会对请求路由进行干扰，因为清单文件包括指向内容块位置的URL。为了确保清单文件不会妨碍CDNI的请求
路由，并且不会对CDNI资源放置过多的负载，要么清单文件的使用可以限制于只包括相对URL，要么上游CDN可以在清单中更改URL。我们处理这些问题的方法
是双重的。作为强制性要求，每个CDN需要有能力处理包括相对或者绝对路径的URL的未更改的清单文件。为了限制重定向的数量，和CDNI接口的负载，作为一
个可选的特征，上游CDN可以通过使用CDNI请求路由重定向接口获取的信息来更改清单文件里面的URL。因为清单文件的修改是一个上游CDN可选的内部过程，
这不需要做一些标准化的工作。

第三，对于CDNI日志接口，有几个潜在的问题，包括大量的独立请求块可能导致大量的日志信息，以及关联相同HAS会话中的块请求的日志信息。对于最初的
CDNI规范，我们的方法是期望参与的CDN通过CDNI日志接口支持每个块的日志(例如，把每个块当做独立的内容请求，来记录每个块的请求)。可选的，LI可能
包含一个内容采集标识符(CCID)和/或一个会话标识(SID)作为日志字段的一部分，从而使应用程序有益于在这种会话级别信息中(例如基于会话的分析)，促进
在每会话日志中处理每个块的关系。这种方法符合RFC 6983中提出的建议，这也表明了将来可能会对这方面进行改进。

第四，对于CDNI控制接口，特别是对给定的CDN清除HAS块，我们的方法是期望每个CDN支持每个块的内容清除(例如，把每个块当成独立的内容项来清除)。可选
的，一个CDN可以支持基于"Purge IDentifier (Purge-ID)"进行内容清除，允许使用一个引用来清除关联到给定内容采集的所有块。这个Purge-ID可以和上面
讨论的HAS日志的CCID结合到一起，或者，可以保持不同。(//意思就是Purge-ID可以和CCID使用同一个字段，也可以使用各自独立的字段)

4.8 URI重写

当使用HTTP重定向，内容URI可能被重写，当重定向发生在上游CDN内部，上游CDN到下游CDN，下游CDN内部。在级联CDN的情况下，内容URI可能在每一跳CDN被
重写。在任何一对uCDN/dCDN之间使用的内容URI，变成了一个可以涉及到的公共句柄，在他们的CDN之间通信中不会模糊不清。这个句柄允许上游CDN和下游CDN
使用其他CDNI接口在上游方向(例如，当使用LI时)和下游方向(例如，当使用MI时)关联交换的信息。

考虑一对uCDN/dCDN使用HTTP重定向的情况。我们对内容URI介绍了下面的术语，来简化讨论：
"u-URI"表示请求中的内容URI，由上游CDN提供；
"ud-URI"表示上游CDN和下游CDN共同句柄的内容URI，从上游CDN重定向到指定的下游CDN的请求。
"d-URI"表示授权的下游CDN提供的请求中的内容URI。

在我们简单的成对示例中，"ud-URI"实际变成了一对uCDN/dCDN用来关联所有CDNI信息的句柄。特别的，对于给定的一对CDN执行HTTP重定向，上游CDN需要对
所有的MI信息交换时，把u-URI映射到ud-URI句柄，而下游CDN需要在LI信息交换时把d-URI映射为ud-URI句柄。

在级联的CDN情况下，传输CDN(//中间CDN)在重定向到下游CDN时会重写内容URI，从而在传输CDN和下游CDN之间建立新的句柄，这个句柄和上游CDN到传输CDN
的句柄不同。传输CDN有责任管理句柄之间的映射，所以所有的两个CDN之间的正确句柄需要使用它们之间的CDNI通信。

总之，对给定的一对CDN的所有CDNI接口都需要使用"ud-URI"句柄作为它们内容URI的引用。

5. 部署模型

在本节中，我们描述了一些可能实现的部署模型通过使用上面描述的CDNI接口。我们注意这些模型并不是所有的，其他的许多模型也是可以的。

虽然图1的参考模型显示了每侧CDNI接口的所有的CDN功能，可以根据涉及到这些功能的任何子集进行部署，因此只支持CDNI接口的相关子集。正如已经在第3
节指出的，实际的CDNI部署不需要实现所有的接口。这样的一些部署的例子如下所示。

注意，虽然我们指的是上游和下游CDN，但是区别适用于特定的内容项和事物。那就是，给定的CDN对于一些事务来说是上游，但是对其他的事务是下游，取决
于很多因素例如请求客户端的位置和请求内容中的特殊部分。

5.1 网状CDN

虽然图1的参考模型使用一个上游CDN和一个下游CDN显示了单向的CDN互连，通过这个可以建立任意的CDNI网络，例如图11所示的网状例子。(支持任意的网状
模型可能或者可能不在工作组的初始范围，但是模型允许这样做)

5.2 CSP和CDN结合

注意我们的术语是指功能方面，而不是经济或商业方面。也就是说，当我们考虑执行功能时，给定的组织可能同时是CSP和一个完整的上游CDN，如图12所示。

5.3. CSP使用CDNI请求路由接口

作为另一个例子，一个CP可能选择运行它自己的请求路由功能，作为从多个CDN选择的途径。在这种情况下，CP可能作为一个CSP和一个特殊受限CDN的结合的
模型。在这种情况下，如图13所示，再请求路由的控制面板下，CDNI请求路由接口可以用于CP操作的受限CDN和完整CDN组织操作的下游CDN之间。CDNI工作范
围之外的接口可以用在CP组织的CSP功能实体和完整CDN(作为上游CDN)组织操作的CDN，作为CDNI控制面板，而不是请求路由面板(即控制、分发、日志)。

(//意思是CP的CDN和上游CDN只进行请求路由通信操作，其他的操作在CSP和上游CDN的CDNI控制接口完成，而不用通过CP的CDN)
(//这一节说的就是CSP里面的CDN只使用CDNI的请求路由接口和上游CDN通信，而其他的操作还是常规的CP和上游CDN之间的通信)

5.4 CDN联盟和CDN交换

这里有两个附加概念，和之前的CDNI不同。第一个是CDN联盟。我们的观点是CDNI是更一般的概念，包括两个或更多的CDN给他们各自的用户提供内容服务，虽然
联盟意味着多边的互联方案，但是其他的CDNI方案也是可能的(例如，两边对称，两边不对称)。一个重要的结论是CDNI技术不应该被假定成一个特定的互联协议
，而是应该足够通用，允许发展替代的互联方案。

第二个经常用在CDN联盟上下文的概念是CDN交换——一个第三方的代理或者交换用来促进CDN联盟。我们观点是一个CDN交换提供有价值的机制来衡量在一个多边(
联盟)协议中的多个CDN，但是这个机制是建立在CDNI机制的核心之上。例如，如图14所示，交换可能对每个CDN的网点和能力聚合和重新分配信息，以及收集、
过滤和重新分配流量日志，这是每个参与者进行互连结算所需要的，但是DCN内部的请求路由、内容分发(包括内部内容采集)、控制，这些在上游CDN和下游CDN
之间涉及到直接的影响——在成对的对等安排的操作(//意思是CDN之间也会有这样的操作)。转到图14，我们在这个例子观察到：

-每个CDN对其他的CDN支持一个直接的CDNI控制接口
-每个CDN对其他的CDN支持一个直接的CDNI元数据接口
-每个CDN对CDN交换支持一个CDNI日志接口
-每个CDN支持CDN交换的CDNI请求路由接口(用于动态聚合和重新分配CDN网点发现信息)和一个对其他CDN的直接RI(用于实际请求重定向)

(//主要是利用第三方来控制所有的CDN)

注意，CDN交换可以可选的支持不同的功能集合(例如，只记录日志，或者记录日志和完整的请求路由，或者所有的CDN功能包括内容分发)。所有这些选项都是
IETF CDNI规范所允许的。

6. 信任模型

在CDNI方案中，有许多需要处理的安全问题。实际上，大多是类似的或者和一个简单的不互连CDN中是相同的。(//这些安全问题大多类似，或者和独立的CDN有
相同的安全问题)。在一个标准的CDN环境中(没有CDNI)，CSP在一定程度上信任一个独立的CDN执行多种功能。CDN被信任用于分发内容，对终端用户提供适当的
质量体验。CSP信任CDN不会损坏或者修改内容。CSP通常信任CDN根据交付内容的数量，提供可靠的记账信息。CSP也可能信任CDN去执行一些操作，例如使内容
失效和基于确定原则例如用户位置和一天的某个时间来限制用户对内容的访问，并且CSP使用URI签名等技术强制对每个请求执行授权。

一个CSP也信任CDN不会分发CSP的保密信息(例如一个内容项的热度)或者终端客户端的保密信息(例如，哪个用户看了哪个内容)。

一个CSP没有必要对一个CDN完全信任。CSP在某些情况下，可以通过向CDN分发时，采取措施来保护它的内容，例如加密内容并且使用一些带外方式分发密钥。
CSP也依靠检测(可能来自第三方)和上报来验证CDN充分发挥作用。CSP可以使用基于客户的计算计数来验证CDN提供的记账信息时可靠的。HTTP条件请求可能
用来向CSP提供一些对CDN的检查。换言之，CSP可以在短期内信任一个CDN执行一些功能，在大多情况下，CSP能够验证这些动作是否被正确执行和采取行动(
例如把内容移动到不同的CDN)如果CDN没有按照期望执行。(//意思就是CSP可以验证动作是否执行，如果CDN没有正确执行，则采取动作)

其中一个信任问题是CDNI提出的传递信任。一个CDN和CSP有直接的关系，可以向另一个(下游)CDN"外包"交付内容。那个CDN也可以外包给另一个下游CDN，等
等。

这种授权链中的*CDN有负责确保CSP的需求得到满足。没有这样做大概是因为和传统的单个CDN情况一样严重。因此，上游CDN本质是信任下游CDN代其执行
功能和CSP信任独立CDN的方式是一样的。监控和上报类似的用来验证下游CDN正确执行。然而，在CSP和终端用户的路径之间引入多个CDN会使画面复杂化。例如
，第三方对CDN执行(或者其他方面，例如适时失效)的监控可能有能力指出在交付链中的某个地方出现了问题，但是不能指出是哪个CDN出错了。

总之，我们假设上游CDN将会向下游CDN授予一定的信任，但是它会验证下游CDN是否正确执行，并且如果行为不正确时采取纠正措施(包括断绝和那个CDN的联系
)。我们不期望CSP和它的*CDN的信任关系和今天独立CDN的情况会有所不同。然而，在特定的交付链中识别CDN的故障，用来监控CDN执行和行为的更复杂的工
具和技术是有需要的。

我们期望CDNI的具体接口的详细设计将需要考虑到信任传递问题。例如，明确确认被下游CDN执行的某些动作(例如，内容清除)，可能有助于缓解一些传递信任
问题。

7. 隐私考虑
一般来说，CDN有机会从终端用户收集详细行为信息，例如，记录下载了哪个文件。然而本文档描述的互连CDN的概念，不一定允许一个给定的DCN对任何特定用
户去收集更多的信息，这有可能通过一个CDN到更多的组织共享这些数据。作为一个例子，CDNI日志接口的目的是允许下游CDN向上游CDN共享一些日志记录，用
于计费目的和共享流量统计。实际上CDNI接口提供机制来共享这种潜在用户敏感信息，表明给这些接口包括适当的隐私和保密机制是有必要的。这些机制的定义
在各自的CDN接口文档中。

8. 安全考虑
虽然独立的DN引入了各种安全问题，我们在这里特别关注CDN互连时会出现的额外问题。例如，当一个CDN有能力代表一个CSP分发内容时，需要考虑这个内容可
能被分发给没有被认证的团体，并且有机制来处理这样的担心(//非互连CDN的问题，而且有机制处理)。本节我们的重点是CDNI如何引入了独立CDN情况没有出现
的新的安全问题。对CDNI安全需求的更详细的分析，见[RFC7337]的第9节。

CDNI出现的许多安全问题都和传递信任有关，如第6节描述的。如上面提到的，为CDNI接口设计的各种接口必须关心附加的风险，那就是一个和CSP没有直接关系
的CDN现在可能为那个CSP分发内容。减轻这些风险的机制可能和独立CDN情况类似，但是它们的适用性必须在这种更复杂的环境下验证。

今天的CDN提供了很多手段来控制内容的访问，例如时间限制，地理阻塞和URI签名。这些机制必须在CDNI环境中继续发挥作用，这种考虑可能会影响某些CDNI
接口(例如元数据、请求路由)的设计。更多关于CDNI中URI签名的信息，见[URI-SIGNING]。

就像单个CDN一样，每个对等CDN必须确保不会被作为一个"开放代理"来代表恶意的CSP分发内容。独立的CDN通常通过CSP明确的注册将要服务的内容(或源服
务器)来解决这个问题，简单地把这些信息传递到下游CDN可能会有问题，因为它泄漏了比上游CDN愿意指定的更多的信息。(为此，前面示例中内容获取的步骤
强制下游CDN从上游CDN检索内容，而不是直接从源服务器获取)

解决这个问题有几种方法。一种是上游CDN对路由到下游CDN的每个URL，对从共享密钥生成的签名令牌编码，并且下游CDN对基于这个令牌验证请求。另一个是
让每个上游CDN上报它们服务的CDN-Domain集合，然后下游CDN在缓存和分发关联对象之前通过这个集合检查每个请求。虽然简单明了，这个方法需要operator
泄漏附加的信息，这可能(可能不)是一个问题。

8.1 CDNI接口的安全性

在RFC7337中注意到，所有CDNI接口必须能够在不安全的IP网络中安全运行。虽然CDNI接口期望可以使用现有的应用协议例如HTTP或者XMPP协议实现，我们也期
望对这些协议的安全机制也能用于CDNI接口。如何保证这些接口的详细信息在相关的接口文档中指定。

8.2 数字版权管理

数字版权管理(DRM),有时候也成为数字限制管理，通常通过CDN分发内容使用。一般来说，DRM依靠CDN分发加密的内容，通过其他方式(例如直接从CSP到终端用
户)给用户分发解密密钥。为此原因，DRM被认为已经超出范围[RFC6707] ，并且对CDNI不会产生附加的安全问题。