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的交付节点发送内容请求。若是命中缓存，不会走六、七、八、九、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获取内容。虽然触发方
式不一样，可是流程是同样的)

步骤四、五、六、7和第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不会产生附加的安全问题。