CDNI的相关问题陈述
概述
CDN对可缓存内容提供了许多好处：降低交付成本，提高终端用户体验，提高交付的鲁棒性。对于这些因素，CDN常
用于大规模的内容交付。因此，现有的CDN提供商正在扩大规模，许多网络服务提供商(NSP)也在部署他们自己的CDN。
一般来说，一个给定的内容项可以被分发给终端用户，而不考虑终端用户的地理位置或者附属网络。这个就是连接独立
CDN的动机，这样每个CDN就可以在内容服务提供商(CSP)和终端用户的端到端操作之间作为开放的内容交付设施进行互相
操作。然而，当前没有开放的说明或者标准来促进这种CDN之间的互联。
1. 介绍
大量的视频和多媒体内容传输在互联网上迅速增长，预计在未来会持续如此。面对这样的增长，CDN对可缓存的内容提供
了大量的益处：降低交付成本，提高终端用户体验，提高交付的鲁棒性。对于这些因素，CDN常用于大规模的内容交付。
因此，现有的CDN提供商正在扩大规模，许多网络服务提供商(NSP)也在部署他们自己的CDN。
一般来说，一个给定的内容可以被分发给终端用户，而不考虑终端用户的地理位置或者附属网络。然而，一个特定的CDN
对于其负责分发给定的内容，可能这个CDN的扩展范围离用户的位置或者附属网络不够近，或者没有用户需要的资源，来
实现用户的体验和更加分布式CDN设施可以接受的成本。这个就是连接独立CDN的动机，这样集合的CDN范围和资源可以促进
CSP和终端用户的的端到端的内容交付。作为一个例子，CSP可以和权威的CDN签订授权来分发其内容，之后权威CDN可以和
其他的一个或多个下游CDN签订授权来代表权威CDN分发交付部分或者全部内容。
一个典型的端到端内容交付方案涉及以下的业务流程：
-CSP和EU之间的业务处理，CSP控制终端用户对内容的访问授权。
-CSP和授权CDN之间的业务处理，CSP托管CDN代表CSP进行内容分发。
-权威CDN和其他CDN之间的业务，权威CDN可以把实际的服务内容分发请求授权给其他CDN。一个特殊的情况是这个被
授权的CDN也是提供终端用户访问网络的网络服务提供商，这种情况为了相符的网络访问，在终端用户和NSP之间也
有分开和独立的业务关系。
CSP和CDN，CDN和CDN之间的业务构成和细节不在本文档的范围内。然而，从技术角度来说，这个文档涉及到当前没有公开
的说明或标准来促进CDN之间的互联。
一个可能的CDN之间的端到端内容传递流程描述如下：
-授权CDN首先收到来自终端用户的初始内容请求。
-授权(上游)CDN可能直接让自己来服务，或者选择使用CDNI来把请求重定向到位置更合适的下游CDN(例如下游CDN更
接近终端用户)。
-终端用户收到权威CDN的重定向响应后，向下游CDN发起请求。如果需要，下游CDN会从权威CDN获取用户要请求的内
容，如果必要的情况下，权威CDN还会从CSP获取用户要请求的内容。(//例如内容要求实时，或者内容过期)
本文档的目标是概括CDNI的问题领域。第2节讨论了CDNI的使用案例。第3节描述了IETF考虑到的CDNI模型和问题领域。
第4节单独描述了每个CDNI接口，突出的实例候选协议来考虑作为重用或者促进实现CDNI接口。附录B.2描述了CDNI问题
范围和其他相关的IETF工作组和IRTF研究小组的关系。
1.1 术语
本文档使用下列术语：
权威CDN:与CSP有直接关系的CDN，权威CDN或者权威CDN的下游CDN对该CSP的内容进行分发和传递。
互联CDN(CDNI):一对CDN之间的关系，使得一个CDN可以代表两一个CDN提供内容分发服务。CDNI可以完全或部分地通过
一系列的接口在一对CDN之间进行通信实现，为了实现一个CDN代表另一个CDN对用户交付内容。
CDN提供者：操作CDN并且提供内容分发服务的服务提供者，通常被CSP或者另一个CDN提供者使用。注意通常一个实体可以
作为多个角色运行。例如，一个公司可以同时作为一个CSP、NSP和CDN。
CDNI元数据：内容分发元数据的子集具有跨CDN的范围。例如CDNI元数据可以包含地理封锁消息(即定义内容可以被使用或
者阻止的地理区域)，窗口可用性(即定义内容可以被使用或者阻止的时间窗口)和强制执行的访问控制机制(例如URL签名
验证)。CDNI元数据还可能包含期望的分发策略信息(例如预定位、动态采集)和一个CDN可以从哪里、用哪种方式获取内容。
内容：任何形式的数字数据。一种在分发和传递之间附加的额外限制组成的内容方式是连续媒体(即数据进出之间的时间关系)。
内容分发元数据：内容分发元数据的子集和分发的内容有关。这是一个CDN为了启用和控制内容分发的元数据，并且由CDN传递。
在CDNI环境中，一些内容分发元数据可能具有CND内的范围(因此这些数据不需要在CDN之间进行通信)，而一些内容分发元数据
可能有跨CDN的范围(因此需要在CDN之间进行通信)。
CDN:在4到7层之间网络单元协作，对用户进行更加有效的内容交付的网络设施。通常，一个CDN包括一个请求路由系统，一个
分发系统(包括一组代理服务器)，一个日志系统，和一个CDN控制系统。
内容元数据：关于内容的元数据。内容元数据包括：
1.与内容分发相关的元数据(因此涉及到一个CDN对该内容的传递)。我们将这种元数据成为"内容分发元数据"。可以查看
"内容分发元数据"的定义。
2.元数据和实际内容或者内容表述相关联，而和内容的分发没有关联。例如，这种元数据可能包含内容的流派、演员、等级
等相关信息。或者和内容的分辨率、屏幕比例相关的表示信息。
内容服务：CSP提供的服务。内容服务包括完整的服务，不仅仅是提供内容项的访问;例如内容服务还包括任何中间件、密钥分发
、程序指南等等。这些可能不需要和CDN参与内容的分发和传递而和CDN有任何直接交互。
CSP:对终端用户提供内容服务(通过用户代理访问)。一个CSP可能拥有内容服务的部分内容，或者从另一方获取的内容权利。
控制系统：CDN提供的包括自举和控制CDN的其他组件，处理外部系统的交互的功能(例如处理交付服务的创建/更新/删除请求，
或者对特定的服务提供请求)。
交付：CDN代理向UA提供的一条内容的传递。例如，交付可以基于HTTP渐进下载或者HTTP自适应流。
分发系统：CDN中负责分发内容分发元数据，也包括存在于CDN中的内容自身的功能。
下游CDN：对于给定的终端用户请求，由另一个CDN(上游CDN)把请求重定向到的这个CDN(一对直接互联的CDN中的一个)。注意在
连续的重定向中，一个给定的CDN可以当做下游CDN，也可以当做上游CDN。(例如CDN1-->CDN2-->CDN3,其中的CDN2就是这种情况)
动态CDNI元数据的采集：在CDNI上下文中，动态CDNI元数据采集表示在内容的请求被上游CDN授权给下游CDN的这个时间点，下游
CDN从上游CDN获取内容的CDNI元数据(并且在下游CDN中，这个CDNI元数据当前还不可用，当前如果可用就不用进行动态获取了)
。可以查看下游CDN和上游CDN的定义。
动态内容采集：动态内容采集表示一个CDN从内容源获取终端用户请求的内容。在CDNI上下文中，动态获取表示一个下游CDN在
一个内容的请求被上游CDN授权给下游CDN的这个时间点，从内容源(包括上游CDN)获取内容(并且在下游CDN中，这个内容当前还
不可用)。
EU:系统中真实的用户。通常是一个人，也可能是硬件和软件结合模拟的一个人(例如自动化测试)。
日志系统：CDN收集测量和记录分发和传递活动的功能。日志系统的记录信息被用来各种作用，包括控诉(例如用于CSP)，分析和
检测。
元数据：元数据一般是关于数据的数据。
NSP：提供给终端用户网络连接服务的提供商。
OTT：一种服务，例如，使用CDN进行内容交付，由不同于运营商的NSP的运营商运营，该服务已附加。
CDNI元数据采集的预定位：CDNI上下文中，CNDI元数据预定位就是下游CDN在内容之前，或者在没有任何终端用户请求该内容时
，自主地获取CDNI元数据。
内容采集预定位：内容预定位就是一个CDN在终端用户请求该内容之前，或者自主地从内容源获取内容。在CDNI上下文中，上游
CDN在终端用户请求之前，或者主动通知下游CDN从内容源(包括上游CDN)获取内容。
QoE:2.4节定义。
请求路由系统：CDN负责的功能，即CDN收到UA的内容请求，获取和维护一组候选代理节点或者候选CDN的重要信息，并且选择一
个合适的代理或者CDN，把用户重定向到那里。为了实现CDNI，请求路由系统必须支持UA从另一个CDN重定向过来内容请求。
代理：一个设备(通常称为缓存)，配合CDN中的其他元素，在CDN中进行内容分发并且与UA配合完成内容交付。通常，代理会缓存
请求的内容，因此可以对多个UA的同样请求直接发送内容，避免了内容在网络中被多次传输。
上游CDN：对于给定的终端用户请求，把这个请求重定向到另一个CDN的这个CDN就是上游CDN。
UA：终端用户使用的内容服务的软件。例如浏览器，机顶盒，媒体播放器等等。
1.2 CDN背景
假设读者熟悉CDN的架构、特征和操作。对于不熟悉CDN操作的读者，下面的资源可能有用：
-RFC3040描述了CDN构建中的许多组件技术。
-分类中比较了多个CDN的体系结构。
-RFC3466和RFC3570是IETF的CDI工作组输出的文档，并且在2003关闭。
注意：本文档的一些术语和上面相关文档的术语类似，阅读这个文档时，这些术语应该解释为1.1节中的定义。
2. CDNI使用案例
随着视频业务以及其他内容交付应用的日益增长，面对成本效益越来越多的NSP在部署CDN。
CDN允许在网络边缘服务器缓存内容，因此对于给定的内容可以被CDN代理分发给多个UA，而不用在网络中多次传送。这有助于
降低带宽成本和提高用户体验。CDN也用于多个代理复制热门内容，使得可以同时服务于大量用户。这也帮助了处理突发访问
和拒绝服务攻击的情况。
NSP部署的CDN不仅仅受限于NSP支持的自身的内容交付服务，例如电视服务的机顶盒，也用于其他设备的内容交付，包括PC，平
板，手机等等。
一些服务器提供商在多个地理位置和多个NSP之间运作，这些NSP通常在独立的CDN之间运作。他们发展自己的服务(例如用户跨越
附属的NSP时内容服务的无缝支持)，这样就需要互连这些CDN;这是CDNI的第一个使用案例。然而，并没有公开的规范，也没有共
同的最佳实践，定义如何实现这样的CDN互连。
CSP期望他们的内容可以被大量的用户访问到，这些用户通常分布在不同地理位置，在保持高质量体验的同时，不需要这些CDN
提供商保持直接的业务关系(或者扩大当前已有的CDN)。一些NSP正在考虑互连他们各自的CDN，以便这种集体设施可以满足CSP的
成本效益。这代表了CDNI的第二种使用案例。特别的，这将使CSP受益于在网的交付(即当前NSP拥有的网络/CDN网点)，不需要CS
P维护所有CDN之间的直接业务关系。再次，CDN提供商(NSP或者顶级CDN运营商)面临缺少公开的规范和最佳实践。
NSP经常在特定的服务或环境部署CDN作为专用的降低成本的项目。一些NSP为独立的服务使用独立的CDN，例如，可能有一个负责
管理IPTV服务交付的CDN，一个web-TV交付的CDN，和一个向移动终端提供视频交付的CDN。当NSP需要整合他们的业务时，需要互
连这些CDN，这是CDNI的第三种使用场景。再次，NSP面对着CDN互连的开放接口的缺乏。
由于操作原因(例如灾难，攻击)或者商业因素，一个顶级CDN可能选择另一个CDN(例如一个NSP CDN在线代理)服务用户请求的子
集(例如用户的请求附属于那个NSP)，这是CDNI使用的第四个场景。并且CDN提供商(顶级CDN或者NSP)面临缺少公开的规范和最佳
实践。
CDNI-USE-CASES更深入的讨论了CDNI的使用场景。
3.CDNI模型和IETF的问题区域
这一节讨论了IETF在CDNI的问题区域。
互连的CDN在每个CDN之间涉及到多个不同的功能和组件。只有其中一些需要IETF进行额外规范。
一些NSP开始试验探索是否他们自己的CDN用例可以用现有的CDN解决，一组这样的试验在CDNI-EXPERIMENTS文档中。这些试验的
结论是互连CDN一些基本的限制可以在当前已有的CDN技术中实现，目前缺乏的是必要级别的功能没有标准化的CDNI接口，诸如
本文档讨论的，这阻碍的CDNI的部署。
下面列出的是在一对CDN之间所需的四个接口，构成了CDN互连问题，每个接口的功能需求，这是当前没有的标准。作为CDNI接口
发展的一部分，在CDN互连之间，有必要在识别和命名数据对象的公共机制上达成一致。
术语“接口”的使用意味着包含该协议通过哪个CDNI数据表示(例如，CDNI元数据对象)交换以及数据的规范表示本身(即每个对象
有哪些属性/字段包含，其结构等)。
-CDNI控制接口：该接口允许"CDNI Control"系统在互连的CDN之间通信。这个接口可能支持以下：
*允许引导其他CDNI接口(例如接口地址/URL的发现和安全连接的建立)。
*允许配置其他CDNI接口(例如上游CDN指定通过CDNI日志接口上报的信息)。
*允许下游CDN对于交付能力和策略这些静态信息进行通信。
*允许引导CDN之间的内容采集接口(即使这个接口在CDNI工作范围之外)。
*允许上游CDN对下游CDN进行启动或者请求特殊的动作。例如，允许上游CDN发起采集内容或者CDNI元数据，或者向下游CDN
请求清除文件内容和CDNI元数据。
-CDNI请求路由接口：这个接口允许请求路由系统在互连的CDN中通信，保证终端用户的请求可以被上游CDN重定向到下游CDN的代
理服务器，特别的，这个选择的责任可能跨多个CDN(例如，上游CDN需要有选择下游CDN的责任，下游CDN需要有选择代理的责任)
。特别的，CDN路由请求接口的功能被划分为以下：
*一个CDNI请求路由重定向接口，在请求重定向到下游CDN之间，允许上游CDN查询下游CDN。
*CDNI网点&能力通告接口，允许下游CDN向上游CDN提供(静态或动态)信息(例如资源，网点，负载)，来使上游CDN处理一系
列的UA请求时，帮助选择合适的下游CDN。
-CDNI元数据接口：这个接口允许在互连CDN的分发系统通信，保证CDNI元数据可以在CDN之间交换。1.1节定义了CDNI元数据。
-CDNI日志接口：这个接口允许互连CDN的日志系统通信，这将允许日志处理程序运行在多CDN环境。例如，一个上游CDN可以为了
执行对CSP的统一记账或者对多个CDN的结算的目的而从下游CDN收集分发日志。类似的，一个上游CDN为了向CSP提供统一的报告
和检测向下游CDN收集分发日志。
注意当前阶段是试验性考虑，根据功能性对四个接口进行分组，这可能在以后的研究之后改变(例如一些功能子集可能从一个接
口转移到另一个接口)。
上面列出了一个潜在的问题空间，某种程度上因为为了连接两个CDN，有一些'接触点'需要标准化。然而，当前期望CDNI接口不
需要从头开始定义，而是可以在很大程度上重用或利用现有协议;这个在第4节讨论。
形成CDNI问题区域的接口如图1所示。
如图1所示，CDN互连之间的内容获取不在CDNI的范围；这值得做一些额外的解释。这样的决定是本文档描述的CDNI问题空间仅专
注于定义CDNI的控制平面，因此CDNI数据平面(即实际内容对象的获取和分发)已经超出本文档范围。这样一个合理的决定是今天
的CDN通常已经使用标准化的协议，例如HTTP,FTP,rsync等来从他们的CSP客户那里获取内容，并且预计互连CDN可以使用相同的
协议来获取内容。因此，内容的获取已经被认为解决，而这一切都需要遵从CDNI工作组用CDNI元数据获取内容制定的规范，描述
了用于检索内容使用的参数-例如，连接IP地址/主机名时，使用什么协议来检索内容等等。
4.确定CDNI问题的范围
本节概述了CDNI问题空间的工作范围，在约束条件下如何通过重用或利用现有协议来实现CDNI接口。这个讨论并不打算取代任何
工作组的决定作为更适合的协议、技术和解决方案来选择实现CDNI接口，但是意图用一个事实的例证来说明CDNI接口没必要从头
开始创建，而且重用和利用现有的协议是可能的。
第3节在CDNI问题区域内描述了四个CDNI接口(CDNI控制接口，CDNI请求路由接口，CDNI元数据接口，CDNI日志接口)，这些控制
平面的接口工作在应用层(OSI网络中的第7层)。首先，这些接口和其他的许多现有的网络应用想比，不期望展现独特的会话、传
输或者网络需求，而是期望CDNI接口可以定义在现有会话、传输、网络协议之上。
其次，尽管可以针对CDNI设计一个新的应用协议，我们下面的分析说明了这是没必要的，并且建议通过重用或利用现有的应用协
议(例如，HTTP协议[RFC2616]，XMPP协议[RFC6120])来实现CDNI接口。
4.1 CDNI控制接口
CDNI控制接口允许互连CDN的控制系统进行通信。目前CDNI控制接口需要支持的精确的iner-CDN控制功能，相比其他三个CDNI接
口定义的不太完善。
预计对于控制接口，对于其他CDNI接口，现有的协议可以被重用或利用。
4.2 CDNI请求路由接口
CDNI请求路由接口可以使上游CDN向下游CDN查询一个路由功能，来判断下游CDN是否可以(愿意)接受授权的内容请求。同时也允
许下游CDN在上游CDN的请求路由功能的重定向消息中，控制如何给UA响应。
因此，CDNI请求路由接口是一个相当直接的请求/应答接口，并且可以在许多请求/应答协议上面实现。例如，可以使用常用的We
bService方法来实现一个WebService(XML-RPC，已知URI的HTTP请求等等)。这去除了CDNI工作组为CDNI请求路由接口定义一个新
的请求/应答协议的需求。
此外，正如第3节讨论的，CDNI请求路由接口也期望用来下游CDN向上游CDN提供信息(静态或动态信息，例如资源、网点、负载)
，当处理后续UA的内容请求时，以便于帮助上游CDN的请求路由系统选择下游CDN。预计CDNI请求路由功能可以由CDNI工作组通过
充分利用现有的支持动态分配或者信息可达性(例如，利用现有的路由协议)，或者支持应用层级的拓扑信息查询(例如，利用应
用层的流量优化(ALTO)[RFC5693])的IETF协议来制定。
4.3 CDNI元数据接口
CDNI元数据接口使下游CDN的分发系统向上游CDN请求CDNI元数据，以便下游CDN可以正确处理和响应从CDNI请求路由接口收到的
重定向请求、直接从UA收到的内容请求。
因此CDNI元数据接口和CDNI请求路由接口类似，因为这是一个请求/应答接口，而相对于请求路由重定向请求的直接性，CDNI元
数据搜索可能有更复杂的语法因此会有潜在的附加选项。因此，与CDNI请求路由接口一样，CDNI元数据接口可能使用常用的WebS
ervices方法实现成一个WebService(XML-RPC，已知URI的HTTP请求等等)，或者使用其他现有协议例如XMPP[RFC6120]。这去除了
CDNI工作组为CDNI元数据接口定义一个新的请求/应答协议的需求。
4.4 CDNI日志接口
CDNI日志接口使得在互连的CDN中交换内容分发的详细信息和交付活动-例如，交换内容交付的相关日志记录，类似web server的
access log日志记录。
已经存在的一些协议可能被用来互连CDN交换CDNI日志，包括SNMP，syslog，FPT，HTTP POST等等。
5. 安全考虑
CDN的内容分发带有一系列的安全考虑，例如如何在CSP的策略中强制控制EU的内容访问权限，或者如何信任对CSP的计费目的时
由CDN生成的日志信息。这些安全方面已经由当前的CDN提供商和CSP的独立CDN解决。然而，CDN之间的互连通过扩展信任模型到
信任链引入了一组新的安全考虑(即CSP信任一个CDN，之后"信任"到其他CDN)。该机制用来在多CDN环境中降低风险，可能类似于
当前的独立CDN，但是在这种更复杂的环境中必须验证可用性。
CDN的互连可能需要对独立的CDN引入额外的隐私考虑。在一个多CDN的环境中，不同的CDN可能属于不同的法律制度，需要执行不
同的隐私需求。这种隐私需求可能会影响CDNI接口交换的信息粒度。例如，下游CDN的日志系统可能需要在交换包括EU交付详细
日志时，使用一些程度的匿名、混淆或者完全删除一些字段，然后给上游的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毒害。CDN之间的信息交换必须保证信息的保密性和完
整性。
5.4 CDNI日志接口的安全性
日志数据包含了潜在的敏感信息(EU请求的媒体资源，EU的IP地址，潜在的姓名和账户信息等等)。CDN之间移动这些信息必须保
证机密性。对于它可以作为跨CDN收费的基础的观点，这些信息也是敏感的。因此需要适当级别的保护来防止这些信息防止被损
害、复制和丢失。
6. 致谢
7. 信息参考
附录 A. 实现CDNI接口的设计考虑
本节扩展了CDNI接口如何重用和利用当前存在的协议，在单独描述每个CDNI接口之前，考虑重用或利用示例候选协议实现CDNI接
口。然而，这里讨论的选项纯粹是例子，并没有提供任何稍后将使用的协议的共识。
A.1. CDNI控制接口
CDNI控制接口允许互连CDNI的控制系统进行通信。目前CDNI控制接口需要支持的精确的iner-CDN控制功能，相比其他三个CDNI接
口定义的不太完善。
然而，正如第3节讨论的，CDNI控制接口可能需要支持以下类似功能：
-允许上游CDN和下游CDN进行建立、更新或者终止CDNI互连。
-允许引导其他CDNI接口(例如，协议地址的发现和安全关联的建立)。
-允许配置其他CDNI接口(例如，上游CDN指定要通过CDNI日志接口上报的信息)。
-允许下游CDN发送关于交付能力、资源和策略的静态信息。
-允许引导CDN之间的内容获取接口(即使该接口已超过CDNI的工作范围)。
预计控制接口，对于其他CDNI接口，可以重用或利用现有的协议。当控制接口的需求完善后这些将被考虑。
A.2. CDNI请求路由接口
CDNI请求路由接口使得一个上游CDN的请求路由功能向下游CDN的请求路由功能发起查询，以决定是否下游CDN可以(愿意)接受授
权的内容请求和允许下游CDN控制上游的请求路由功能在重定向消息中应该如何响应UA(//下游CDN控制上游CDN响应UA的重定向消
息)。
因此，CDNI请求路由接口需要为上游CDN提供一个上游CDN给下游CDN发送一个"重定向请求"的机制。请求路由接口需要支持在DNS和特定内容应用协议(例如HTTP，RTSP，RTMP等等)之上，上游CDN接收UA请求的初始请求这种需求。
因此，重定向协议预计包含以下信息：
-上游CDN接收UA的初始请求协议(例如DNS，HTTP)。
-UA请求的附加细节，以便下游CDN执行有效的请求路由。对于DNS，通常是DNS解析器的IP地址代表UA发送请求。对于在特定内容
应用协议之上收到的请求，重定向请求可能包含更多和原始UA请求相关的信息，至少期望包括UA的IP地址、和HTTP POST头部相
当的内容、和HTTP绝对路径相当的内容(定义在RFC2616)。
CDNI架构需要考虑下游CDN可能不首先收到上游CDN的重定向请求而是直接收到UA的请求，例如：
-用户代理(或者DNS解析器)可能从请求的路由中缓存DNS或者响应。
-请求路由接口上面的重定向请求的响应可能是可缓存的(//缓存了重定向请求的响应)。
-一些CDN可能依靠简单粗暴的策略，录入CDN B始终同意服务CDN A授权的重定向请求，这种情况下必要的重定向细节会在(CDNI
接口的)范围外交换，例如配置。
收到重定向请求时，下游CDN将使用请求中提供的信息来决定是否可以(且愿意)接受授权的内容请求，并且需要对上游CDN返回决
定后的结果。
因此，下游CDN的重定向响应预计包括下列信息：
-表示接受或拒绝的状态码(可能包含相关的原因)。
-允许上游CDN重定向的信息。这种情况下基于DNS请求的路由，预计上游CDN应该返回给DNS解析器DNS记录(例如CNAME记录)。在
基于应用的路由请求情况下，预计返回给UA包括构建特定应用重定向响应的必要信息。对于UA发出的HTTP请求，上游CDN可以返
回一个含有URI的HTTP 3xx响应。
因此，CDNI请求路由接口是相当直接的请求/应答接口，并且可以通过任何数量的请求/应答协议实现。例如，它可能使用常用的
WebServices方法实现成一个WebService(XML-RPC,对已知URI的HTTP查询)。这去除了CDNI工作组为CDNI请求路由接口定义一个新
的请求/应答协议的需求。因此，CDNI工作只剩下制定以下任务：
-使用推荐的请求/应答协议以及CDNI请求路由接口中制定的额外的语法和流程(例如，如何处理格式错误的请求/应答)。
-重定向请求和应答的语法(即表示/编码)。
-重定向请求和应答的语义(即含义和预期内容)。 (//语法和语义，语法是定义表示或者编码规则，语义是定义表示的含义)
另外，正如第3节讨论的，CDNI请求路由接口还期望下游CDN向上游CDN提供(静态或动态)信息(例如资源、网点、负载)，以帮助
上游CDN请求路由系统处理一系列的UA内容请求时选择下游CDN。预计这样的CDNI请求路由功能可以由CDNI工作组充分利用现有的
IETF中支持可达性信息的动态分配协议(例如，利用现有的路由协议)或者支持应用级别的拓扑信息请求(例如，利用ALTO)来制定。
A.3. CDNI元数据接口
CDNI元数据接口使得下游CDN的分发系统可以从上游CDN获取CDNI元数据，以便下游CDN可以正确的处理和响应：
-通过CDNI请求路由接口收到的重定向请求。
-直接从UA收到的内容请求。
CDNI元数据接口需要对上游CDN提供一种机制：
-向下游CDN分发/更新/删除CDNI元数据。
并且/或者允许下游CDN：
-对CDNI元数据对象直接请求。
-对CDNI元数据进行递归请求-例如，可以使下游CDN沿着具有内部对象关系的关系树查询。
因此CDNI元数据接口类似于CDNI请求路由接口，因为它是一个请求/应答接口。而相对于请求路由重定向请求的直接性，CDNI元
数据搜索可能有更复杂的语法因此会有潜在的附加选项。因此，就像CDNI请求路由接口，因此，与CDNI请求路由接口一样，CDNI元
数据接口可以使用常用的WebServices方法实现成一个WebService(XML-RPC，已知URI的HTTP请求等等)，或者使用其他已有的协议
，例如XMPP[RFC6120]。这去除了CDNI工作组为CDNI元数据接口定义一个新的请求/应答协议的需求。
因此，CDNI工作组只剩下制定以下任务：
-使用推荐的请求/应答协议以及CDNI元数据接口中制定的额外的语法和流程(例如，如何处理格式错误的请求/应答)
-该接口中交换CDNI元数据对象的语法(即表示/编码)。
-该接口中交换CDNI元数据对象的语义(即含义和预期内容)。
-不同CDNI元数据对象表示的关系。
A.4 CDNI日志接口
CDNI日志接口使得在互连的CDN中交换内容分发的详细信息和交付活动-例如，交换内容交付的相关日志记录，类似web server的
access log日志记录。
在今天的CDN中，日志记录用于各种目的。具体来说，CDN使用日志来对计费和支付系统、实时(近实时)分析系统生成呼叫数据记录
(CDR)。这些在CDNI日志接口的应用场景需求，在互连的CDN之间支持有保证并且及时传递日志消息。另外确保收到日志消息的完整
性也是必要的。
一些已存在的协议可以使用在互连的CDN中进行CDNI日志交换，包括SNMP traps消息、syslog、FTP、HTTP POST等。尽管一些候选
协议可能并不能满足CDNI的所有需求。例如，SNMP traps不支持traps的保证传递，因此可能导致日志记录丢失，随之那段交付内
容的CDR和计费记录不能产生，以及任何分析平台都看不到那段交付内容。
尽管为了在CDNI日志接口之间交换日志定义一个新协议是没有必要的，CDNI工作组仍然需要制定：
-推荐使用的协议。
-一组默认的日志字段和它们的语法语义。
-今天在不同的内容交付协议中，还没有一套标准的通用日志字段，并且在某些情况下，甚至没有一套标准的日志名称字段和值在
相同交付协议中有不同的实现。
-生成触发日志的默认生成条件。
附录B. 附加材料
本节记录定义一部分CDNI问题陈述相关信息。
B.1 IETF的无目标
下面列出了作者提出的在内容交付CDNI工作范围外的方面：
-CSP和权威CDN之间的接口(即上游CDN和CSP的交付签约，或者和下游CDN的签约)
-交付CDN代理和UA之间的交付接口，例如流媒体协议。
-对给定的CDN的请求路由系统和UA之间的请求接口。现有的IETF协议(例如HTTP、RTSP、DNS)通常由UA从CDN请求内容，以及通过CD
N的请求路由系统重定向UA的请求。CDNI工作组不需要对此目的定义新的协议。然而，CDNI控制面板接口可能会间接影响通过请求
接口的某些信息交换(例如URI)。
-CDN之间的内容获取接口(即一条内容从一个CDN到另一个CDN传递的数据平面接口)。预计这将使用已有的协议如HTTP或者其他论坛
中定义的从原始服务器到CDN之间的内容获取协议(例如基于HTTP的C2参考点(ATIS IIF CoD //ATIS IIF内容点播服务))。本文档
描述的CDN互连问题空间可能因此只关心在两个互连CDN的互操作性之间使用的内容获取协议的协议/协商方面。
-EU/UA认证。EU/UA认证和授权由CSP负责。
-内容准备，包括编码和转码。CDNI架构旨在允许在互连的CDN之间分发，而内容被看做是不透明的。解释和处理对象，还有代理对
EU之间对这些内容的优化交付是不再CDNI范围内的。
-数字版权管理(DRM)。DRM是一个内容保护系统和UA之间端到端的问题。
-处理CDNI日志的应用(例如计费、分析、上报)。
-CDN内部的接口和协议(即一个CDN内的接口和协议)。
-独立CDN的可扩展性。CDNI的接口/方法的可扩展性是范围内的，单独CDN的如何扩展已超出范围。
-请求路由系统选择CDN或者代理的实际算法(然而，当一些需要在CDN之间传递特定的参数需要输入到这些算法时是在范围内的)。
-代理算法。例如缓存算法和内容获取方法超出了CDNI工作。内容管理(例如内容删除)关系到CDNI内容管理策略是在范围的，但是
当缓存决定不再缓存一个内容时的内部算法是不在范围内的。
-元素管理界面。
-互连CDN的商业、交易和法律相关的方面。
