CDNI - RFC 6707 翻译

                  CDNI的相关问题陈述

概述
CDN对可缓存内容提供了许多好处:下降交付成本,提升终端用户体验,提升交付的鲁棒性。对于这些因素,CDN常
用于大规模的内容交付。所以,现有的CDN提供商正在扩大规模,许多网络服务提供商(NSP)也在部署他们本身的CDN。
通常来讲,一个给定的内容项能够被分发给终端用户,而不考虑终端用户的地理位置或者附属网络。这个就是链接独立
CDN的动机,这样每一个CDN就能够在内容服务提供商(CSP)和终端用户的端到端操做之间做为开放的内容交付设施进行互相
操做。然而,当前没有开放的说明或者标准来促进这种CDN之间的互联。web

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的商业、交易和法律相关的方面。

网络

相关文章
相关标签/搜索