用于打包内容路由和分发的设备和方法与流程

文档序号:22508521发布日期:2020-10-13 09:49阅读:232来源:国知局
用于打包内容路由和分发的设备和方法与流程

相关申请

本申请要求2019年2月26日提交的具有相同标题的共同拥有且共同未决的美国专利申请序列号16/286,200的优先权的权益,其内容通过引用整体并入本文。

本申请要求2018年2月26日提交的具有相同标题的共同拥有且共同未决的美国临时专利申请序列号62/635,430的优先权的权益,其内容通过引用整体并入本文。

本申请一般还涉及2013年8月2日提交的题为“打包内容分发设备和方法(packetizedcontentdeliveryapparatusandmethods)”的共同拥有且共同未决的美国专利申请序列号13/958,467(现在是2014年11月10日提交的题为“打包内容分发设备和方法(packetizedcontentdeliveryapparatusandmethods)”的美国专利号9,467,369和14/537,735)的主题,前述每一篇均通过引用整体并入本文。

本公开一般涉及通过网络的内容和/或数据分发的领域。更具体地,在一个示范性方面,本公开涉及用于经由网络的打包内容分发的设备和方法。



背景技术:

在内容分配网络中向多个订户提供内容是现有技术中熟知的。在典型配置中,内容通过任何数量的不同拓扑分配给订户装置,所述拓扑包含例如:(i)混合光纤同轴(hfc)网络,其可以包含例如密集波分复用(dwdm)光纤部分、同轴电缆部分和其它类型的承载媒体;(ii)卫星网络(例如,经由碟形卫星天线从轨道实体到用户的stb);(iii)光纤分配网络,例如“光纤接入”或fttx(它可以包含例如其ftth、fttc、fttn和fttb变体);(iv)混合光纤/铜缆或“hfcu”网络(例如,光纤分配网络,通过已安装的pots/pstn电话布线或cat-5电缆进行节点或最后一英里的分发);(v)微波/毫米波系统等。

在向用户或订户提供内容中利用了各种类型的内容分发服务。例如,可以根据广播时间表提供某些内容(又名“线性”内容)。还可以按需提供内容(例如,经由视频点播或vod、免费视频点播、准视频点播等)。还可以从位于用户场所(例如,经由dvr)或其它位置(例如,经由设置在网络位置处的个人录像机或网络个人录像机)处的记录装置或经由“启动”范例向用户提供内容,这也为用户提供了更多的对内容回放的控制(“非线性”)。

可以利用各种系统和方法来将媒体内容分发给订户。例如,所谓的“因特网协议电视”或“iptv”是一种系统,通过所述系统,服务可以通过包交换网络基础设施(诸如例如因特网和宽带因特网接入网络)使用因特网协议组的架构和联网方法分发给订户,而不是通过传统的射频广播、卫星信号或电缆电视(catv)格式进行分发。这些服务可以包含例如实时tv、视频点播(vod)和交互式电视(itv)。iptv跨使用ip协议的接入无关的包交换网络分发服务(包含视频、音频、文本、图形、数据和控制信号)。

也可以使用所谓的“过顶”或ott分发,其中来自可能与网络运营商无隶属关系的第三方来源的内容经由网络运营商的基础设施(例如,经由基于ip的传输)直接向请求用户或订户提供内容,即根据熟知的因特网协议网络层协议,基于用户的网络或ip地址,例如经由高速docsis电缆调制解调器对内容进行打包和路由,以向请求用户进行分发。传统上,ip单播(点到点)或多播(点到多点)已被用作所述机制,通过所述机制,经由用户访问规定的url并使用其认证信息登录以获得内容的访问权,ott内容通过网络进行分配。然后,ip内容经由单播/多播流传输到一或多个请求用户,并由用户的pc、膝上型计算机或其它支持ip功能的最终用户装置上的媒体播放器应用程序(“app”)接收和解码。

存在多种类型的可以被视为“ott”内容分发的情况。以网络运营商为中心的(“广播”)ott模型通常使用订户isp(例如,电缆mso)来分发ott服务。对于这种方法,ott分发可能涉及牢固地嵌入智能tv或机顶盒中的应用控制的紧密耦合以及具有凝聚力的主要内容起源策略。这通常包含基于流视频的工作流,所述工作流将内容发布源与mso内容管理系统相连接。这又与最终用户或订户装置中的应用同步;内容以基于应用的电子节目指南(epg)或用户装置上的其它用户界面的形式呈现。

使用内容分发网络(cdn)来将上述内容分发给其用户或消费者(其可以包含诸如jit打包程序或其它进程的网络实体以及最终用户/消费者)。cdn通常包含原点(例如,内容所起源的一或多个原点服务器;本地或“边缘”节点或一或多个服务器,其通常被配置成本地缓存内容,以便尤其减少内容提供中的延迟并提供冗余;服务提供商网络或基础设施,其用于将所请求的内容分发到分配、点、用户场所或服务区域。

现有的用于例如线性内容分发的cdn模型基于利用“任播”作为连接模型来实现客户端到缓存的可达性;对于示范性任播配置,参见例如本文先前并入的2014年11月10日提交的题为“打包内容分发设备和方法(packetizedcontentdeliveryapparatusandmethods)”的共同拥有且共同未决的美国专利申请序列号14/537,735。通常,这些任播地址经由边界网关协议(bgp)从允许服务一或多个给定资源的节点通告。另参见钱德拉,r(chandra,r)、特雷纳,p.(traina,p.)和李,t(li.,t),“bgp团体属性(bgpcommunitiesattribute)”,rfc1997,doi:10.17487/rfc1997,1996年8月,http://www.rfc-editor.org/info/rfc1997,和布拉德纳,s.(bradner,s.),“用于rfc中以指示需求级别的关键字(keywordsforuseinrfcstoindicaterequirementlevels)”,bcp14,rfc2119,doi10.17487/rfc2119,1997年3月,http://www.rfc-editor.org/info/rfc2119,前述每一篇均通过引用整体并入本文。

由于例如过度使用或故障而无法支持所需负载的节点可以撤消任何或所有通告的路由以减小其负载。这种网络路由通告表示资源的任意分组(其可以大到例如“所有线性资源”,或者具体到例如节目频道(例如,“cnntm”));但是,这种粒度受限于可用地址的数量,特别是在因特网协议版本4(ipv4,在rfc791中阐述)下的一个实例中。然而,本方法存在很大的局限性,尤其是在资源级技术(例如,运营)和业务决策进程的背景下,并且还没有为cdn间通信提供公共控制平面。



技术实现要素:

本公开尤其通过公开了用于使用具有增强的寻址空间和资源粒度的网络协议来管理打包内容分发网络的设备和方法来满足前述需求。

在本公开的一个方面,公开了一种操作数据网络的方法。在一个实施例中,所述网络包含一或多个内容分发网络(cdn),并且所述方法包含使用粒度资源路由(rr)映射来通告网络内的一或多个资源以分发给例如客户端进程(例如,jit(及时)打包程序)。在一个变体中,利用具有适当地址空间(例如,ipv6)的因特网寻址协议来完成rr映射。

在另一方面,公开了一种被配置成在其上存储一或多个计算机程序的非暂时性计算机可读设备。在一个实施例中,一或多个计算机程序包含被配置成在被执行时为一或多个cdn内的多个网络资源元素提供资源映射的多个指令。

在又一方面,公开了一种用于分发打包内容的网络架构。在一个实施例中,所述网络包括一或多个内容分发网络,并且包含多层配置,所述多层配置具有基于资源特定性通告经由多个路由向网络客户端分配内容资源的能力。

在另一方面,公开了一种rr映射实体。在一个实施例中,所述映射实体包括由cdn或诸如mso的受管网络运营商维护的计算机化网络装置,并且其被配置成为cdn/一或多个受管网络内的各个资源解析ipv6地址。

在又一方面,公开了地址去聚合的方法(尤其用于在cdn内提供关联性)。

当根据本文提供的公开内容考虑时,这些和其它方面变得显而易见。

附图说明

图1是结合本文描述的各种特征可用的示范性mso网络架构的功能框图。

图1a公开了根据本公开的一个实施例的用于经由内容分发网络(cdn)向客户端装置提供视频或其它媒体内容的架构的示范性配置。

图2a是示出了根据本公开的资源路由映射架构的一个实施例的逻辑框图。

图2b是示出了根据本公开的资源路由映射调用流程的一个实施例的梯形图。

图3a是示出了根据本公开的文字主机名赋值架构的一个实施例的逻辑框图。

图3b是示出了根据本公开的文字主机名调用流程的一个实施例的梯形图。

图4a是示出了根据本公开的ipv6编码路径确定架构的一个实施例的逻辑框图。

图4b是示出了根据本公开的ipv6编码路径调用流程的一个实施例的梯形图。

图5a是示出了根据本公开的路由查找架构的混合模型的一个实施例的逻辑框图。

图5b是示出了根据本公开的混合模型架构调用流程的一个实施例的梯形图。

图6是示出了根据本公开的缓存分层架构的一个实施例的逻辑框图。

图7是示出了根据本公开的ebgp资源对等架构的一个实施例的逻辑框图。

图8是示出了示范性免结算对等费用结构的逻辑框图。

图9是示出了根据本公开的外部缓存对等架构的一个实施例的逻辑框图。

图10是示出了根据本公开的本地缓存对等架构的一个实施例的逻辑框图。

图11是示出了根据本公开的中转缓存对等架构的一个实施例的逻辑框图。

图12a是示出了根据本公开的地理位置感知dns客户端路由架构的一个实施例的逻辑框图。

图12b是示出了根据本公开的图12a的地理位置感知dns客户端路由架构的消息流的一个实施例的梯形图。

图13a是示出了根据本公开的具有边缘节点httpget重写功能的地理位置感知dns客户端路由架构的一个实施例的逻辑框图。

图13b是示出了图13a的具有边缘节点httpget重写功能的地理位置感知dns客户端路由的消息流的一个实施例的梯形图。

图14a是示出了根据本公开的路由“泄漏”客户端路由架构的一个实施例的逻辑框图。

图14b是示出了根据本公开的路由“泄漏”客户端路由消息流的一个实施例的梯形图。

图15是示出了根据现有技术的典型ip去聚合方法的逻辑框图。

图16是示出了根据本公开的资源前缀聚合架构的一个实施例的逻辑框图。

图17是示出了根据本公开的被配置成针对关联性进行去聚合的架构的一个实施例的逻辑框图。

图18是示出了根据本公开的被配置成针对关联性进行去聚合(例如,在“北向”故障转移场景中)的架构的一个实施例的逻辑框图。

图19a是示出了根据本公开的非rr启用cdn(源)到rr启用cdn(客户端)的基于dns的架构的一个实施例的逻辑框图。

图19b是示出了根据本公开的非rr启用cdn(源)到rr启用cdn(客户端)的基于dns的处理流程的一个实施例的梯形图。

图20a是示出了根据本公开的非rr启用cdn(源)到rr启用cdn(客户端)的基于http302的架构的一个实施例的逻辑框图。

图20b是示出了根据本公开的非rr启用cdn(源)到rr启用cdn(客户端)的基于http302的处理流程的一个实施例的梯形图。

图21a是示出了根据本公开的rr启用cdn(源)到非rr启用cdn(客户端)的边界节点架构的一个实施例的逻辑框图。

图21b是示出了根据本公开的rr启用cdn(源)到非rr启用cdn(客户端)的边界节点流程的一个实施例的梯形图。

图22a是示出了根据本公开的rr启用cdn(源)到非rr启用cdn(客户端)的映射架构的一个实施例的逻辑框图。

图22b是示出了根据本公开的rr启用cdn(源)到非rr启用cdn(客户端)的映射流程的一个实施例的梯形图。

所有附图版权2017-2018特许通信运营有限责任公司(chartercommunicationsoperating,llc)。版权所有。

具体实施方式

现在参考附图,其中类似的附图标记始终表示类似的部分。

如本文使用,术语“应用”通常是指但不限于实施某一功能或主题的可执行软件的单元。应用的主题在多种学科和功能(例如,点播内容管理、电子商务交易、经纪交易、家庭娱乐、计算器等)中有很大不同,并且一个应用可以具有多于一个主题。可执行软件的单元通常在预定的环境中运行;例如,所述单元可以包括在javatvtm环境中运行的可下载javaxlettm

如本文使用,术语“客户端装置”和“最终用户装置”包含但不限于机顶盒(例如,dstb)、个人计算机(pc)和小型计算机(无论是台式机、膝上型计算机,还是其它)、以及移动装置(例如,手持式计算机、平板电脑、“平板手机”、pda、个人媒体装置(pmd)和智能手机)。

如本文使用,术语“计算机程序”或“软件”旨在包含进行功能的任何序列或人或机器可识别的步骤。此程序实际上可以以任何编程语言或环境来呈现,包含例如c/c++、fortran、cobol、pascal、汇编语言、标记语言(例如,html、sgml、xml、voxml)等;以及面向对象的环境,例如公共对象请求代理架构(corba)、javatm(包含j2me、javabeans等)、二进制运行时环境(例如,brew)等。

术语“客户场所设备(cpe)”是指位于客户或用户的场所内并连接到网络的任何类型的电子设备,例如机顶盒(例如,dstb或iptv装置)、电视、电缆调制解调器(cm)、嵌入式多媒体终端适配器(emta)(无论是独立的,还是与其它装置集成)、数字录像机(dvr)、网关存储装置(furnace)和itv个人计算机。

如本文使用,术语“因特网”和“互联网”可互换地用于指代互连网络,包含但不限于因特网。

如本文使用,术语“存储器”或“存储”包含适于存储数字数据的任何类型的集成电路或其它存储装置,包含但不限于rom、prom、eeprom、dram、sdram、ddr/2sdram、edo/fpms、rldram、sram、“闪速”存储器(例如,nand/nor)和psram。

如本文使用,术语“微处理器”和“数字处理器”通常旨在包含所有类型的数字处理装置,包含但不限于数字信号处理器(dsp)、精简指令集计算机(risc)、通用(cisc)处理器、微处理器、门阵列(例如,fpga)、pld、可重配置计算结构(rcf)、阵列处理器和专用集成电路(asic)。此些数字处理器可以含在单个整体式ic管芯中,或者分布在多个组件中。

如本文使用,术语“mso”或“多系统运营商”是指但不限于具有通过那些媒体分发包含节目和数据的服务所需的基础设施的电缆、卫星或地面网络提供商。

如本文使用,术语“网络”和“承载网络”通常是指任何类型的电信或数据网络,包含但不限于混合光纤同轴(hfc)网络、卫星网络、电信网络和数据网络(包含man、wan、lan、wlan、互联网和内联网)。此些网络或其部分可以利用任何一或多种不同的拓扑(例如,环形、总线、星形、环路等)、传输媒体(例如,有线/rf电缆、rf无线、毫米波、光纤等)和/或通信或联网协议(例如,sonet、docsis、ieeestd.802.3、atm、x.25、帧中继、3gpp、3gpp2、lte/lte-a、wap、sip、udp、ftp、rtp/rtcp、h.323等)。

如本文使用,术语“网络接口”是指与组件或网络的任何信号或数据接口,包含但不限于火线(例如,fw400、fw800等)、usb(例如,usb2)、以太网(例如,10/100、10/100/1000(千兆比特以太网)、10-gig-e等)、moca、串行ata(例如,sata、e-sata、sataii)、超ata/dma、coaxsys(例如,tvnettm)、射频调谐器(例如,带内或oob、电缆调制解调器等)、wi-fi(802.11a,b,g,n)、wi-max(802.16)、pan(802.15)、蜂窝(例如,lte/lte-a、3gpp、3gpp2、umts)、cbrs或irda系列的那些。

如本文使用,术语“一或多个资源”用于但不限于指代一或多个内容元素或块、或被配置成分发或启用对它们的访问权或其提供的设备或进程或服务。

如本文使用,术语“服务器”是指任何计算机化的组件、系统或实体,无论其形式如何,其适于向计算机网络上的一或多个其它装置或实体提供数据、文件、应用、内容或其它服务。

如本文使用,术语“wi-fi”是指但不限于ieee-std.802.11或相关标准(包含802.11a/b/g/n/v)的任何变体。

如本文使用,术语“无线”是指任何无线信号、数据、通信或其它接口,包含但不限于wi-fi、蓝牙、3g(3gpp/3gpp2)、hsdpa/hsupa、tdma、cdma(例如,is-95a、wcdma等)、fhss、dsss、gsm、pan/802.15、wimax(802.16)、802.20、nfc(例如,iso14443a/b)、窄带/fdma、ofdm、pcs/dcs、lte/lte-a/td-lte、模拟蜂窝、紫峰、cdpd、卫星系统、毫米波或微波系统、声学和红外(即irda)。

示范性实施例的详细描述

现在详细描述本公开的设备和方法的示范性实施例。尽管在具有多系统运营商、数字联网能力和多个客户端装置/cpe的受管混合光纤同轴(hfc)电缆系统架构的背景下描述了这些示范性实施例,但是可以将本公开的一般原理和优点扩展到其它类型的网络和架构(无论是宽带、窄带、有线或无线、地面或卫星、受管或非受管(或其组合),还是其它),因此以下在本质上仅是示范性的。

还将理解,尽管通常在机构服务提供(例如,学术、商业、政府、非营利性等)的背景下进行描述,但是本公开也可以容易地适于其它类型的环境(例如,家庭网络等)。无数其它应用也是可能的。

此外,尽管在通过外部受管网络提供服务的背景下进行了描述,但是本文描述的架构和技术可以容易地应用于内部网络管理。所呈现的外部受管网络实施例仅用于证明本文描述的原理的灵活性和一般适用性(例如,可以在有或没有网络的完全管理员控制的情况下实施),并且不应以任何方式被认为是限制性的。

而且,尽管主要在熟知的因特网协议(尤其在rfc791和2460中描述)的背景下描述了某些方面,但是将理解,本公开可以利用其它类型的协议(并且实际上是包含其它互联网和内联网的承载网络)来实施上述功能。

最后,尽管相对于ip视频资源描述了本公开的各个方面,但是本文描述的设备和方法可扩展到可以由(例如,ip)地址表示的任何资源,包含但不限于其它文件类型(图像、文档、音频文件)、网络资源(包含第4层端口号的潜在替代),甚至是大容量存储装置的一部分(例如,hdd上的扇区或块)。

概述-

如上所述,对资源集(例如,当前实例中的线性服务或内容)进行分组的当前模型不能为技术/运营和商业目的提供足够的对资源的具体控制。本限制的一个可操作实例是,资源集的范围与资源可用性的缩小性质不符,因为它接近资源的原点。在一个现有配置中,所有线性资源(~4500个服务)由32个ip地址(例如,71.74.45.128/28和2001:1998:0aff::0/124)表示,这对cdn节点起作用——因为所有节点有权访问所有资源——但是;本方法在原点(打包程序进程)层失效。具体地,打包程序实体/进程各自负责服务的子集,通常大约100个服务左右。这意味着无法在本层处使用资源通告机制。线性分发的“原子”或基本单位可以被视为内容元素“块”,并且在一些情况下,期望以这种相对较高级的粒度进行操作。

因此,转移到离散地表示资源(例如,使用ip地址,例如在ipv6协议下提供的ip地址)的模型,其尤其有利地允许资源的直接通告,同时还受益于ip的固有可聚合性。本文描述的示范性解决方案进一步有利地(i)继续利用网络的现有bgp方面,和/或(ii)利用公共控制平面,其可以例如由不同的cdn运营商和不同的分发组件用来通告资源。

此外,在给定cdn内部,可以通过增加资源寻址/通告的粒度实现一些益处,包含:(i)资源关联性(即相同类型的请求将被路由到相同的节点,从而在表面上改善效率以及客户/订户体验);(ii)资源级平衡(网络的节点可以以资源级或基于每个资源转移流量,从而允许细粒度调平);(iii)动态资源范围划分(节点可以基于受欢迎程度选择服务请求或允许更高层服务请求,从而防止低受欢迎程度资源“污染”或稀释缓存);和(iv)“零接触”提供和资源重定位(即允许节点通告资源消除了对资源起源的静态配置的需求,从而避免了现有方法下所需的许多更改。

此外,使用公共控制平面有利地允许cdn运营商和资源提供商向其它运营商动态通告资源。具体地,ip互连的许多要求直接适用于资源对等。ip对等尤其提供了启动对等控制的机制以及在网络的规定位置或组件处接受(资源或路由)公告的逻辑。此外,它提供了一种机制,允许路由的公告程序和接收程序都断言对一个通告的偏好(相较于另一个通告)。此外,bgp团体属性提供了一种传达另外的有关给定资源的元数据的机制,其可以是信息性的或指示性的。最后,利用路由聚合可以有利地用于限制“资源路由表”中的路由的数量,因为一个cdn只需要知道对等cdn正在使用的聚合——无需明确知道所述资源域内的具体资源可达性,从而简化了支持架构和协议。

如下面更详细地描述,尽管本文阐述了用于资源命名的两个示范性机制以及将所述命名映射为ipv6地址的能力,但是考虑了本公开的普通技术人员可以认识到其它方法。

服务提供商网络–

图1示出了典型的服务提供商网络配置,其可与本文描述的增强型资源寻址和通告设备和方法的特征一起使用。

在本公开的一个实施例中,本服务提供商网络100用于提供线性和其它类型的内容向网络用户或订户的分发以及其它功能(例如,从服务提供商的服务节点(hfc电缆或fttc/ftth引入电缆)到不同的场所或处所/住所的主干和回程传输)。在某些实施例中,服务提供商网络100还有利地允许订户或帐户特定性数据(尤其包含特定docsis调制解调器、cpe和/或与此订户或帐户相关联的移动客户端装置)的聚合和/或分析作为在本文所述的示范性分发模型下向用户提供服务的一部分。仅作为一个实例,装置特定性id(例如,基于网络的id、mac地址等)可以与例如在一或多个网络头端107处维护的mso订户数据互相关,以允许或至少促进(i)对mso网络的用户/装置认证;(ii)提供服务的区域,场所或处所的各个方面与特定订户能力、人口统计或设备位置的相关,例如用于分发位置特定性或针对性内容或通告;和(iii)订阅级别(以及因此订户对某些服务的特权和访问权(如适用))的确定,以及其它事项。

此外,可以由mso维护特定装置的装置配置文件,使得mso(或其自动代理进程)可以对装置进行建模以进行渲染/解码、dcas/drm/加密、无线或其它能力。

图1的mso网络架构100对于符合本公开的各个方面的打包内容(例如,包或帧结构或协议内携带的编码数字内容)的分发特别有用。除了点播和广播内容(例如,实时视频节目)之外,图1的系统可以经由因特网协议(ip)和tcp(即通过docsis或带内qam承载)将因特网数据和ott(过顶)服务分发给最终用户,但是可以用数字通信领域中熟知的其它协议和传输机制来替代。

图1的网络架构100通常包含一或多个经由光纤环137与至少一个集线器117通信的头端107。分配集线器117能够经由插入的网络基础设施145向各个“客户端”装置106(其可以包含cpe,例如dstb等)以及网关装置160(如适用)提供内容。

在图1的mso网络100中,各种内容源103、103a用于向内容服务器104、105和原点服务器121提供内容。例如,可以从本地、区域或网络内容库接收内容,如在题为“用于通过带宽有效网络分发打包内容的设备和方法(apparatusandmethodsforpacketizedcontentdeliveryoverabandwidth-efficientnetwork)”的共同拥有的美国专利号8,997,136中所讨论,其通过引用整体并入本文。可替代地,可以从线性模拟或数字馈送以及第三方内容源接收内容。因特网内容源103a(例如,web服务器)将因特网内容提供给一或多个打包内容原点服务器121。其它ip内容也可以在一或多个原始服务器121处接收,例如ip语音(voip)和/或iptv内容。还可以从订户和非订户装置(例如,源于pc或智能手机的用户制作的视频)接收内容。

图1的网络架构100可以进一步包含传统的复用器/加密器/调制器(mem;未示出)。在当前背景下,内容服务器104和打包内容服务器121可以经由lan耦合到诸如802.3z千兆比特以太网(或“10g”)装置的头端交换装置122。为了经由mso基础设施(即qam)进行下游分发,视频和音频内容在头端107处进行复用,并经由光纤环137传输到边缘交换机装置138(其还可以包括802.3z千兆比特以太网装置)。

在一个示范性内容分发范例中,基于mpeg的视频内容(例如,mpeg-2、h.264/avc)可以通过相关的物理传输(例如,docsis信道)分发给基于用户ip的客户端装置;即mpeg-over-ip-over-mpeg。具体地,可以使用ip网络层协议来封装更高层的mpeg或其它编码内容,其随后利用本领域熟知的类型的mpeg打包/容器格式以通过rf信道进行分发或进行其它传输(例如,经由复用传输流(mpts))。此打包模式的分发可以是单播、多播或广播。

诸如图1的实施方案的电缆调制解调器112和客户端/cpe106的各个装置可以被配置成监视特定的赋值rf信道(例如,经由端口或套接字id/地址,或其它此类机制)以获取旨在用于它们所服务的装置/订户场所/地址的ip包。与因特网服务相关联的ip包由边缘交换机接收,并被转发到电缆调制解调器终端系统(cmts)139。cmts检查所述包,然后将旨在用于本地网络的包转发到边缘交换机。在一个变体中,其它包被丢弃或路由到另一组件。

边缘交换机将从cmts接收的包转发到qam调制器,所述qam调制器在一或多个物理(qam调制rf)信道上将所述包传输到“客户端”cm或cpe装置112、106。ip包通常在与用于广播视频和音频节目的“带内”rf信道不同的rf信道上传输,但是这不是必需的。

可以与前述分发机制同时(或取而代之)地使用mso主干网131和其它网络组件来经由非mso网络将打包内容分发给“客户端”装置。例如,可以摄取所谓的“ott”内容(无论是紧密耦合,还是其它方式),存储在mso的网络基础设施内,并经由插入的服务提供商网络(其可以包含公共因特网)111(例如,在本地咖啡店,经由经由调制解调器连接到咖啡店的服务提供商的wlanap分发给用户的移动装置,其中用户的ip启用最终用户装置利用因特网浏览器或mso/第三方app根据基于http的方法通过mso主干网131将内容流传输到与连接到wlanap的服务提供商调制解调器(或光纤解调器)连接的第三方网络。

网络架构100还有权访问第三方边缘装置(例如,边缘服务器109)和原点服务器110。众所周知,内容通常被缓存在“本地”缓存处并由其提供,以在经由客户端装置106提供用户请求的内容时减少延迟。边缘缓存109从原点装置110接收缓存内容,但是也可以使用其它源。将理解,尽管图1的架构100示出了原点和边缘服务器在受管mso网络之外,但是这种服务器中的一或多个可以驻留在mso网络内(即由mso管理)。此外,所示出的其它实体,例如内容/因特网内容源103、103a、打包内容服务器121以及内容服务器104、105,可以用作原点服务器。类似地,图1中示出的集线器117可以包含缓存设备,并且其本身可以用作边缘服务器装置。可以使用符合本公开的方法和设备的多种不同的拓扑和功能方法。

也可以利用符合本公开的用于内容的交换式分发的方法和设备。例如,可以仅提供存在至少一个来自用户装置的请求的内容。在一个实施例中,可以利用2001年9月20日提交的题为“用于在电缆电视系统中有效提供节目素材的技术(techniqueforeffectivelyprovidingprogrammaterialinacabletelevisionsystem)”的共同拥有、共同未决的美国专利申请序列号09/956,688(其通过引用整体并入本文)中公开的方法和设备来提供ip内容的“交换式”分发。例如,可以采用某一机制,由此会话的分发至少部分地基于确定所述会话是否有任何用户处于活动状态的逻辑;例如,没有剩余“观看者”(或会话参与者)的多播可能会崩溃,并且带宽将被收回。

图1a示出了用于经由内容分发网络(cdn)向客户端装置106提供视频或其它媒体内容的架构191的示范性配置。内容提供实体(例如,一或多个打包程序197)经由分配网络111和cdn缓存199与客户端装置106通信。在本公开的一个实施例中,分配网络111包括互联网,诸如例如图1中示出的因特网。尽管在网际协议网络的背景下进行了描述,但将认识到,本公开的原理可以扩展到其它传输方式和网络范例。

请求客户端装置106c可以包含家庭网关装置120(参见图1c)和/或媒体启用客户端装置。此些媒体启用客户端装置可以包含但不限于平板电脑、平板手机、智能收集、智能电视(tv)、台式和膝上型个人计算机(pc)以及便携式媒体播放器。在另一实施例中,媒体客户端装置可以包括文件服务器;文件服务器在商业和住宅用途中都很常见。例如,订户可能具有一个pc,所述pc可以播放媒体文件,但也可以为他/她的其它消费电子产品(例如,智能手机和平板电脑)提供服务。

在本公开的一个实施例中,编码器进程193将来自内容源178、179的源文件192编码成至少一种编码格式(例如,将源文件从一种格式转码为至少一种其它格式)。在另一变体中,源文件192被编码成与一或多个装置类型、编解码器、分辨率、文件格式、音频编码、比特率等中的相应多个相对应的多种编码。所述多种编码可以由cdn缓存199(和打包程序197)经由自适应比特率(abr)流传输而利用。

简短地说,视频压缩在许多现有和新兴产品中使用,例如数字电视机顶盒(dstb)、数字卫星系统(dss)、高清电视(hdtv)解码器、移动装置(例如,平板电脑、智能手机、个人媒体装置(pmd))、数字多功能磁盘(dvd)播放器、视频会议、因特网视频和多媒体内容以及其它数字视频应用。若没有视频压缩,数字视频内容可能会非常大,从而使数字视频内容难以或甚至无法有效存储、传输或观看。这种压缩通常以原始(非压缩)版本中存在的信息的丢失为代价,因此是“有损的”。

存在多种压缩数字视频内容的视频译码方法。因此,已经开发了视频译码标准以标准化各种视频译码方法,使得以大多数视频解码器可以识别的格式来呈现压缩的数字视频内容。例如,运动图像专家组(mpeg)和国际电信联盟(itu-t)已经开发了广泛使用的视频译码标准。这些标准的实例包含mpeg-1、mpeg-2、mpeg-4、itu-th.261和itu-th.263标准。mpeg-4高级视频译码(avc)标准(也被称为mpeg-4、第10部分)是由国际标准化组织(iso)和itu-t联合开发的较新标准。mpeg-4avc标准被发布为itu-th.264和iso/iec14496-10。为了清楚起见,mpeg-4avc在本文中被称为h.264。

大多数现代视频译码标准(例如,h.264)部分地基于具有运动补偿(mc)算法的时间预测。具有运动补偿的时间预测用于去除数字视频广播中的连续帧之间的时间冗余。具有运动补偿算法的时间预测包含运动估计(me)算法,所述算法通常利用一或多个参考图片对特定图片进行编码。参考图片是已经被编码的图片。通过将待编码的特定图片与一个参考图片进行比较,具有运动补偿算法的时间预测可以利用参考图片和待编码的特定图片之间存在的时间冗余,并以比不使用具有运动补偿算法的时间预测对图片进行编码的情况更高的压缩量对图片进行编码相比。

编码器中的运动估计通常是一种计算密集进程,并且因此,在期望速度和处理开销减少的情况下,运动补偿处理的减少或甚至去除可以极大地加快例如视频数据的显示或渲染。

自适应比特率(abr)流传输是一种通过大型分布式网络分配程序内容的技术。特定内容的多个比特率可用于流传输到观看者,并且比特率的选择基于当前的网络条件。这意味着,当存在更大的带宽可用性时,可以选择内容的更大比特率版本。如果可用带宽变窄,则可以选择内容的较低比特率(即较小)版本,以提供无缝的用户体验。abr流传输的非限制性实例包含但不限于通过http的mpeg动态自适应流传输(dash)、用于flash的动态流传输、http自适应流传输、平滑流传输、通过http的自适应流传输和

再次回到图1a,来自内容源的源文件192输入到编码器193。各种内容源178、179可以将源文件204提供给编码器202。例如,可以从本地、区域或网络内容库接收内容,如先前本文并入的共同拥有的美国专利号8,997,136中所讨论。可替代地,可以从线性模拟或数字馈送以及第三方内容源接收内容。因特网内容源(诸如例如web服务器)也可以将因特网内容提供给编码器193。在又一实施例中,可以从订户和/或非订户装置(例如,源于pc或智能手机的用户制作的视频)接收内容。

源文件192可以以各种格式(音频和视频)、比特率、分辨率编码,它们各自可在各种装置上播放。因此,编码器193产生一或多个输出流194。例如,内容分发网络可以使各种各样的用户装置能够播放某一内容。因此,网络运营商选择使编码器193将内容编码成多种格式以在各种播放器上使用。在另一实施例中,网络运营商选择利用自适应比特率流传输,使得通过从输出流194(例如,最佳地利用观看者的装置和当前带宽约束来提供最佳回放体验的流)选择优化流来利用多个比特率流。经由在编码器193处运行的进程或应用来进行优化。

尽管输出流194被示出为单独的文件(例如,mpeg4传输流(.ts)文件),但是在本公开的另一实施例中,所有流(即流194)都以单个“超级”文件呈现。具有包括多个流的单个综合文件尤其减少了cdn缓存199必须管理的文件数量。

编码器193可以利用音频轨道(例如,ac3音频)对输出流194进行编码。可以基于流、最终用户设备以及cdn缓存199使用的协议和格式的要求来选择不同的编码格式和比特率。

编码输出流194还任选地由加密器195经由加密算法(例如,aes、des、公共密钥加密等)来加密。编码和加密输出流存储在存储装置196中。在一个实施例中,编码器193和加密器195的功能可以被集成到单个设备中。

打包程序197利用所存储的输出流来向请求客户端装置106c提供清单(或索引/播放列表)文件198a和视频片段198b。具体地,清单文件198是包括数据流的每个视频片段198b的地址列表的数据结构,并且包含关于视频片段的信息,例如比特率、隐藏式字幕、音频等。不同的abr模型可以使用不同的清单文件。例如,利用http平滑流传输(hss),每个组成部分(隐藏式字幕、音频等)都位于单独的文件中,其中清单文件198a中具有每一个的地址。利用http实时流传输(hls),音频嵌入到片段198b中,并且因此不会在清单文件中单独列出。

在另一实施例中,清单文件198a包含元数据和媒体片段条目的列表。元数据的常见实例包含例如版本信息、协议、文件格式、支持编解码器、分辨率、加密、时间信息(传输时间、表示时间、时间戳等)、地理信息(受限位置、表示位置等)、内容类型标记、同步信息、控制数据等。换句话说,元数据描述了媒体片段198b,并且可以在评估或以其它方式利用媒体片段198b时用作参考文件。在一个实施方案中(本文随后更详细地描述),元数据可以包含数据并且被结构化以便有助于认知延迟管理实体,无论是客户端侧还是网络侧),以促进各种交换延迟减少的机制。

清单文件198a中的媒体片段条目列表包括网络地址列表(其可以是远程的或本地的),媒体内容的相对应片段198b可以在其中访问和/或下载。例如,每个媒体片段条目可以由统一资源定位符(url)列出。在一些实施例中,条目可以是计算资源“路径”格式。计算路径可以是绝对路径(即路径提供片段198b在文件结构中的详细阐述且唯一的位置)或相对路径(即路径提供片段在文件结构中的相对位置)。另外,在一些实施例中,条目可以是符号格式,使得条目的至少一部分必须被进一步解释(即,不是人可读的)。这种的常见实例可以包含例如超文本标记语言(html)标签、专有标签、java、javascript等。此外,一些实施方案可以替代或混合任何前述技术以灵活地适应各种操作模型。如本文随后更详细地描述,可以选择性地选择url或其它网络地址,以最小化由于例如“路径跳”或访问和呈现内容的参考部分时的其它时延源引起的延迟。

在另一实施例中,在表面上“统一的”服务提供商(例如,特许)可以是多个逻辑实体的集合。多个逻辑实体可能对进一步通过各种网络资源分配服务或启用由合作公司或提供商提供的另外的功能很有用。例如,多个逻辑实体可以为特定服务组或地理区域提供本地内容;使内容提供实体更接近最终用户提供了更低的延迟,并可以增加网络冗余。网络资源的常见实例包含例如广播、多播、视频点播、通告服务、本地服务等。在一个具体实例中,一个示范性流清单文件可以包含来自以下的条目:www.charter.comvod.charter.com(视频点播服务)、www.nhk.jp(第3方内容)、www.adserver.com(第3方通告服务)等。参见例如2016年7月7日提交的题为“用于在加密内容中呈现关键帧的设备和方法(apparatusandmethodsforpresentationofkeyframesinencryptedcontent)”的共同拥有的美国专利申请序列号15/204,610,其通过引用整体并入本文。

在另一实例中,媒体片段列表可以包含url链接列表,所述url链接列表进一步插入html标签或javascript,这被配置成有助于通告插入和/或补充节目的执行。例如,视频客户端可以用定制的本地存储通告代替商业广告,而不是例如默认广播商业广告。

在示范性实施例中,每个媒体片段198b是媒体内容的编码和加密子片段或片段。媒体片段198b在以适当的顺序解密、解码和播放时呈现原始媒体内容。在一个实施方案中,每个媒体片段表示与特定分辨率、编解码器和时间戳相关联的视频的一部分。媒体片段198b根据时间戳序列进行组装。

打包程序197可以基于用户的注册来生成列出用于回放内容的所有组成部分的清单文件198a。在一个替代实施例中,清单文件198a(或多个清单文件)是预先生成的,以与一种特定abr格式一起使用。清单文件198a是基于具体装置和最终用户装置的要求生成的。例如,360和one视频游戏系统需要不同的清单文件才能运行。此外,不同的流传输标准可能需要不同的清单文件198a来操作。例如,关于超文本传输协议(http)实时流传输和媒体流传输,可以不同地实施通过超文本传输协议的mpeg动态自适应流传输(dash)协议。因此,每一个可能需要不同的清单文件。

媒体片段198b由打包程序197生成。片段198b可以具有预定的长度。另外,描述片段的元数据可以在打包程序197处生成,或者可替代地在编码器193处生成。如本文所讨论,媒体片段198b形成清单文件198a的生成基础。然而,应当理解,前述功能可以在各种其它网络实体处(例如,编码器193或cdn缓存199处)实现,前述仅仅是示范性的。

在另外的实施例中,编码器193还可以将编码输出流194分成片段198b,以供cdn缓存199使用以提供给客户端装置106c。此外,在此些实施例中,编码器193生成参考片段198b的位置的清单文件198a。

在一个示范性实施例中,可以在接收客户端装置106c上利用2014年3月19日提交的题为“用于记录媒体流的设备和方法(apparatusandmethodsforrecordingamediastream)”的共同拥有、共同未决的美国申请序列号14/220,021(其通过引用整体并入本文)中讨论的类型的媒体客户端。媒体客户端基于清单文件198a重放所存储的“片段”媒体内容。在一个示范性实施例中,基于存储在相关联的数据结构(例如,流清单文件198a)内的信息,解压缩所存储的视频内容流片段198b以进行回放。

资源路由(rr)映射方法和设备-

在本文描述的方法和设备的一个示范性实施例中(参见本文的图2a和2b),提供给客户端(其可以是例如诸如jit打包程序197的网络客户端,诸如例如2017年8月29日提交的题为“用于减少数字内容交换操作中的延迟的设备和方法(apparatusandmethodsforlatencyreductionindigitalcontentswitchingoperations)”的共同拥有且共同未决的美国专利申请序列号15/689,733(其通过引用整体并入本文)中描述的那些或其它(例如,最终用户客户端106))的url看起来很像它们在现有方法下所做的(例如,http://linear-scope010.timewarnercable.com/live/1005/hls/ae/nikphd/index.m3u8)。实施资源路由(rr)方法的第一步是使原点200向资源到路由映射代理进程202(例如,可操作以在mso网络中运行或在第三方服务提供商的控制下运行的计算机化进程)注册url。在一个示范性实施方案中,本注册经由使用api(例如,将输入提供给api,并且api自动返回到输入与注册进程/路由映射有关的进程数据)来进行。资源到路由映射代理将ipv6地址赋予url(在一个变体中,基于使用提取算法从url提取的任意可配置元组)。然后,原点将经由bgp向cdn内的其它节点通告对所述ipv6地址的“可达性”。在一个实施方案中,这些通告并非针对网络装置本身做出。假设例如2级cdn(边缘层和原点),从控制平面的角度来看,前述通告就足够了。

从数据平面的角度来看,给定客户端将首先对主机名进行dns查找,并且在一个变体中,将主机名解析为任播地址(ipv4或ipv6,取决于客户端)。然后,客户端向所述解析任播地址发出httpget请求。当边缘缓存(节点)109、117接收所发出的请求时,它将对资源到路由映射代理实体进行调用,从而请求相关联的ipv6地址。在接收ipv6地址之后,边缘缓存/节点或其代理将进行ip路由查找例程,并(从原点)服务器找到所选择的路由。然后,边缘缓存/节点将使用所述原点服务器的ip地址(基于bgp路由的下一跳)作为上游装置,并将httpget请求发送到所述地址以实现回填。

在一个实施方案中,映射缓存机制可以尤其用于防止缓存对于每个请求都需要咨询映射服务器。

在第二示范性实施例中(参见图3a和3b),经由使用直接资源命名方法排除了对上述类型的映射代理202的需要。提供给客户端(装置或进程)的url可以被配置成采用以下几种形式之一,包含但不限于:(i)文字ipv6插入作为主机名(http://[2001:0db8:85a3:0000:0000:8a2e:0370:7334]),或(ii)插入ipv6地址作为url的路径部分(http://linear-scope010.timewarnercable.com/2001:0db8:85a3:0000:0000:8a2e:0370:7334)。这些方法具有不同的使用情况,从而取决于客户端能力和备用要求而提供不同的选项。

在前一种(文字主机名)方法(i)中,客户端将仅向所述地址发出请求;不需要其它逻辑(包含dns)。边缘缓存/节点117接收所述请求,并且标识这是基于rr的请求,使用目的地ip地址作为查找的路由;复制上述进程,从而将原点110提供给边缘节点109、117以进行回填。本模型的结果是,必须在网络装置本身上知道所述请求的具体路由信息,因为这是ip包的目的地地址。这就需要在某一点处(例如,在边缘处)将rr信息经由bgp暴露给网络。在一个实施方案中,这可以使用聚合来完成(因为每块路由将通告过多的路由),并且明确地仅需要ipv6。另外,本模型需要一种保持http持久性的机制,因为每个httpget请求的tcp端点都不同;但是,如上所述,这些要求被客户在“边缘关联性”方面所得的益处显著抵销。

在图4a和4b的方法中,主机名包括url,客户端可以使用所述url来解析为边缘节点,如针对以上图2a和2b的“资源路由映射”方法所描述。ipv6启用和rr感知客户端可以选择改为使用url的“路径”部分(其在示范性实施方案中为ipv6地址)作为ip包的目的地。对于以这种模式工作的客户端,其余进程与先前描述的文字ipv6即主机名方法相同,边缘节点找到原点的进程也是如此。同样,这要求对于给定资源的ipv6地址,网络必须使用明确的路由信息。本模型的一个优点是,它允许客户端决定实施哪种方法;即如果它想使用rr模型,或者如果不能进行ipv6支持(或rr感知),则回退到更传统的dns方法。在这种情况下,客户端会将主机名解析为cdn边缘节点109、117,并发出请求。cdn边缘节点可以在标识指定的路径(路由)似乎含有基于rr的ipv6地址之后对所述地址进行路由查找以找到正确的原点。与上文描述的文字主机名方法不同,在本模型下,不需要另外的用于http持久性的空间;但是,也没有提供客户端到边缘关联性。

图5a和5b示出了根据另一实施例的混合方法,涉及图3a-3b和4a-4b的前述方法的元素。关于http持久性,在文字主机名ipv6地址是引用(内容)清单文件的url并且清单含有ipv6编码内容“块”名称的情况下,客户端可以继续使用文字主机名进行其tcp连接(从而保持http持久性),并使用使用所述主机名的相对url获取随后的块。由于对这些块的所有请求都将路由到同一服务器,因此本方法中也存在关联性。

多层cdn-

到目前为止,所有实例都基于具有直接从原点(或原点集合)回填的缓存边缘节点109、117的单层cdn。将层添加到cdn可以但并非一定更改先前描述的机制。如图6中所示,在一个实施例中,中间层缓存600可以被配置成作为路由反射层来操作,从而将到原点学习路由重新通告到边缘节点。可替代地,在另一种方法中,插入的层可以被配置成包含在适当的情况下启用路由的“智能”重通告的逻辑。这种“缓存范围划分”可以提高效率,因为各层可以选择基于一或多个度量(例如,资源受欢迎程度)来分配缓存资源。例如,可以通过选择将bgp路由中的下一跳更改为其本身(表面上是“受欢迎的”资源)(如图6的顶部中所示)或其它(“不受欢迎的”资源)(如图6的底部中所示)来实施本功能。不更改下一跳将使原点110成为下一跳,从而使边缘节点跳过一或多个中间层,并直接进行到原点,从而防止中间层上的缓存污染。

可以由上游装置(在这种情况下为原点110)标识是否“允许缓存”或“绕过”资源,因为其本身通常就知道对给定资产进行了多少次请求。如何进行通信将在详细描述团体的使用的下一节中讨论。

bgp团体-

使bgp成为cdn控制协议的有吸引力的选项的其特性之一是,它可以携带任意信息,而所述信息对于协议是不透明的,例如“bgp团体”的形式。bgp团体通常体现为本地有效的数字字符串(以ipv4类型字符串或[整数]:[整数]字符串的形式,二者都是可接受的),其通常仅用作信息提供(例如,“本路由来自纽约”)或用作执行路由政策(例如,“本路由可以向客户通告”)。存在多种由符合标准的路由器授权的“熟知”团体,参见以下表1:

表1

这些团体被设计成控制路由传播,并且可以肯定地用于符合本公开的设备和方法的其本身目的。此外,将bgp作为cdn内或cdn间通信的控制平面的一部分,将认识到团体的其它使用情况,包含以下有关表2讨论的那些(实例的非详尽列表)。

表2

cdn间控制平面-

如上文所讨论,更细粒度的rr的高度有利方面之一是,此方法可以提供用于在不同服务实体之间通信资源“可达性”的公共的易于理解的控制平面。在此些模型中(参见图7的实例),cdn702、704实际上表现为谨慎的自治系统以及其它资源asn的“资源对等”(通常可与ipasn相互对等以通告ip可达性信息的方式相比)。这些资源asn进行互操作的基本原理在很大程度上反映了传统的ip对等。在一个示范性实施方案中,资源节点经由ebgp(外部bgp)接口彼此“对等”,并且向由ipv6前缀表示的资源通告可达性。这些通告的语义可以采取多种形式(包含基于例如业务考虑的那些);但是,这些对等点上允许使用的前缀及其特殊性确实会影响对等cdn上的功能,如本文随后更详细地描述。

因此,在一种方法中,rr前缀被用于cdn间通信;在一个实施方案中,此些前缀是注册商分配的块,其被赋予到资源asn以表示资源的集合。一个实例可以是为mso分配2605:1234::/32;这意味着,所述特定mso中分配了ipv6地址的所有资源都将从本子网中编号。

对等关系-

像ip(v6)可达性对等一样,资源对等实体可能具有不同的业务关系,从而为不同的商业结算提供不同的能力。现在描述与本公开一致的这种对等关系的各个实施例。

资源对等的一种基本形式是免结算对等,在这种形式中,任何一个实体都不向对方付费便有权访问彼此的可达性信息。例如,这种类型的对等可以用于大致相等地受益于所述关系的大型实体之间。在免结算协议下(图8),asn1802将为第一对等点付费,asn2804将为第二对等点付费,依此类推。

在外部缓存中(图9),资源源通告资源可达性。在ip路由的背景下,可达性信息被暴露给对等的网络。在这种模式下,“客户”资源asn902将其一或多个资源前缀通告给提供商资源asn904。提供商asn随后将有权访问那些资源,并且可以使用所述路由信息来回填资源。这允许提供商asn在其边缘上缓存和提供资源。外部缓存的主要目标是使资源更靠近消费者,从而改善客户体验。

相反,在本地缓存(图10)中,有效地使用了与外部缓存相反的方法,因为那些资源asn(提供商)1004不是向其它资源asn通告资源路由,而是向本地asn(客户)1002通告资源路由。这允许本地asn1002回填和缓存来自提供商1004的资源,旨在减少ip对等带宽。这通常与中转ip对等关系相符。

中转缓存(图11)提供了一种使cdn在源和请求者之间提供缓存中转的机制。在这种情况下,客户端197和资源215都不在中转提供商网络1104上,但是提供商正在使其缓存基础设施可用于资源源并使所述资源可用于客户端的网络。这只是第二ebgp连接,从而允许客户网络的cdn1102从中转提供商网络1104回填。

客户指导-

与rr实施方案有关的另一个考虑是,必须将资源/内容的“客户”导向正确的cdn的正确边缘节点,以便获得期望的资源。如果不使用缓存资源,则使资源缓存是无效的和低效的。因此,现在详细描述满足本要求的两个示范性选项。

1.地理位置感知dns-

在第一种方法中(参见图12),可以使用基于dns的cdn指导(可与现有技术cdn中通常所采用相比)。本方法的基本前提是将cdn主机名的dns查找提供给“智能”dns服务器1210,所述服务器1210包含确定客户端的位置(诸如例如使用ip到地理位置定位工具或服务)以及相关边缘节点109、117的位置和一或多个状态的逻辑。dns服务器1210标识适当的边缘节点,并使用相对应的ip地址响应dns请求。一旦请求在cdn内,就可以进行上述处理以满足请求。

如图12b总所示,各个节点(边缘、asn1、asn2)向资源路由映射进程202发出映射请求,并基于由映射器202返回的ipv6地址进行路由查找。

作为如图12b中的每个节点针对资源路由映射器202进行映射请求的替代方案,第一节点(例如,边缘节点109、117)可以将httpget请求的路径部分改变或重写为从映射器进程返回的文字ipv6地址,如图13a和13b中所示。这有利地允许随后的cdn节点简单地对路径中提供的ipv6请求进行路由查找,但是确实要求边缘节点保持原始请求和重写请求之间的映射“状况”或状态,并且要求原点能够将ipv6地址反向映射回扩展路径。值得注意的是,可以在边缘节点109、117上利用实施“反向查找”的类似逻辑,从而去除保持状况的需要。

2.边缘路由泄漏-

解决客户指导问题的第二种解决方案(参见图14a和14b)是允许对等cdn1404上的边缘节点向(其它)对等网络1402通告rr信息(或反之亦然),如经由各种节点间通告1410所示。本模型具有两个特征:(i)直接资源命名,如本文先前所述;和(ii)仅ipv6(除非如前所述,客户端回退到ipv4,但这确实排除了客户端到边缘关联性)。利用直接资源命名来允许客户端197向明确定义的ipv6地址发出http请求。后者是前者的结果,因为必须完全支持ipv6才能转发ipv6包。在本配置中,未使用任何路由映射器202;但是,网络路由器1408尤其与边缘节点109、117关联使用。

需重要注意的是,在资源路由被暴露给ip网络的场景中,必须仔细配置泄漏的网络,因为任何泄漏的节点都可能会响应(field)直接的客户端请求。例如,如果中间层节点(参见例如图6中的节点600)无意中泄漏了资源路由,则它可能会看到直接的客户端请求,从而绕过边缘节点。在某些情况下这可能是期望的,但是在此些配置中,应始终严格评估路由泄漏的影响,以确保避免不期望的行为。

此外,除非具体地要求/协商所述功能,否则接收网络无法将所接收的资源路由通告到其它ip网络(经典ip对等)。

路由聚合和去聚合-

在现有的ip对等中,聚合和去聚合相互矛盾;即在功能与可扩展性之间有斗争。聚合是将多个路由汇总为单个较大的公告的实践,通常被视为“良好”,因为它限制了因特网路由表的大小,而去聚合(在可以公告聚合时通告多个具体路由的实践)具有相反的含义。根据本公开,ipv4因特网路由表是大约685,000个路由;这些路由中大约有307,000个可以聚合,这表示由于去聚合,表大小增加了81%。ipv6只会加剧此问题,因为存在可能的前缀的数量的2^96倍(即大约339,302,416,384,000,000,000,000,000,000,000,000,000个)。

服务提供商去聚合的原因很多。安全性是一个常用的理由(即防止子网劫持)。在这种情况下,逻辑是为了防止另一个未经授权方通告地址块,真正的所有者将仅通过所述块的最小允许子网,并且由于最具体的路由在默认情况下总是获胜,因此它们已“固定”其路由信息的起源。

可替代地,可以将去聚合用作流量工程的一种形式;同样,在默认情况下始终优选更具体的路由。作为一个实例,考虑图15,其中asn11502通过顶部对等会话1506通告其/24,并且通过底部会话1508通告所述地址块中的具体实例199.0.65.64/27。本配置的结果是,发往199.0.65.64/27(199.0.65.64-199.0.65.95)的任何流量都将穿越底部连接1508,而发往所述/24(199.0.65.0-199.0.65.63和199.0.65.96-199.0.65.255)中的其它任何地址的流量将利用顶部会话1506。尽管这种方法有很多益处,但它很快会导致出现问题,包含所谓的路由表“臃肿”。

因此,在一个示范性实施例中(参见图16a和16b),本文所述的rr实体向rr对等通告其分配的聚合路由,从而将具体路由保留在其asn内部(例如,图16中的asn11602)。如其中所示,资源asn11602具有2605:1234::/32,其中三个具体的/96源自不同的原点服务器110。尽管有这些具体信息,asn11602仅向asn21604通告表示那些/96的单个/321606。asn2不需要具体信息,并且可以使用/32将所有请求转发到asn1,然后所述asn1具有具体的/96来将请求路由到合适的原点110。

如上所述,聚合通常对于路由生态系统来说是好的,但是也存在期望和/或需要某种程度的去聚合的使用情况。在上述路由泄漏场景下的客户端到边缘关联性的检查中找到了一个代表性的使用情况。在本模型中,除非采取特定措施避免,否则对等网络的边缘将客户asn的路由“泄漏”到ip网络。在上述聚合情况下,每个对等网络边缘将通告表示asn1的前缀的相同/32,从而使所有路由相等,由此允许任何请求到达任何边缘(并排除关联性,或将类似请求路由到类似节点)。在这种情况下,如图17中所示,允许地址1704进行一些去聚合使得对等asn从每个特定边缘节点通告具有不同程度优先级或选择性的具体信息,并且当前缀表示特定资源时,将给定前缀固定到给定节点提供了客户端到边缘关联性。在一个示范性实施方案中,将特定性上边界应用于支持本布置的ebgp会话,以限制由本方法引起的路由表污染。本限制也可以动态地改变(例如,经由控制器实体或进程,例如在图1的管理器实体171内)。

还将理解,ip的可聚合性还有利地允许在边缘装置故障或其它这种情况下提供“北向”备份的便利解决方案。由于网络逻辑被配置成在默认情况下选择最具体的路由,因此可以设想cdn的后续层生成越来越具体的路由的情况。如图18中所示,asn21804的边缘节点109、117没有通告/321808,而只是通告了/961810(因为其主要)。/32由新插入的一或多个中间层节点600通告到ip网络。本配置允许了各个边缘的关联性,其中如果边缘节点中断,则客户端197不能关联到中间层节点600。

混合模式cdn-

在本公开的另一方面,利用了混合或“混合模式”资源管理架构。具体地,在一些cdn运营商不希望或无法利用如上所述的基于rr的控制平面的情况下,使用互操作性层来通过混合或异构cdn集来促进资源分发。考虑了这种混合cdn使用的两种主要场景:(i)源于非rr启用cdn的一或多个资源分发到rr启用cdn,和(ii)源于rr启用cdn的一或多个资源分发到非rrcdn。现在将更详细地描述这两种配置中的每一种。

1.非rr启用到rr启用-

现在参考图19a-19b和20a-20b,分别针对基于dns的查找和基于httpget的查找示出了非rr启用cdn1902分发到rr启用cdn1904的场景。由于将不存在源于源cdn1902、2002的资源路由(rr)信息(因为它不是rr启用的),因此可以使用经典方法(经由重定向服务器2011进行dns“欺骗”或http302重定向),以允许客户端侧cdn从源cdn1902回填内容。如所示,在一个实施方案中,rr启用cdn1904使用与非rrcdn1902相关联的dns服务器1909进行查找。

2.rr启用到非rr启用-

在第二种情况下(参见图21a-21b和22a-22b),客户端197位于非rr启用cdn2104上或与之相关联,这意味着客户端cdn必须使用“传统”方法来找到源(rr启用)cdn2102的右边界节点。满足本要求的一种示范性方法是将本文先前引用的类型的“任播”模型用于上游节点,所述上游节点被配置成用于客户端cdn2104上的cdn主机名,如图21a中所示。这将使客户端cdn2104边缘节点从任播地址或任播地址集合回填(参见图21a上的示范性“任播”地址)。一旦请求已经到达rr启用cdn2102,就可以进行本文先前所述的正常rr映射、路由查找和请求进程。

在一个实施方案中(参见图22a和22b),并非如图21a中从另一cdn2102的边界节点实现客户端(非rr启用)cdn2104,而是利用映射节点2111来提供到适当边界节点的http重定向。在本配置中,映射节点211仅参与控制平面,因为它将携带源cdn2102的rr表,并利用所述表来进行路由查找。然而,不是使用所选择的路由上的下一跳进行回填(如先前选项中所述),而是向上游节点(例如,cdn2104的边缘节点)发出http302重定向。本方法允许源cdn运营商提供映射节点,无需随后“构建”这些映射节点来支持数据平面的需求(因为它们仅在控制平面上运营),从而尤其降低了成本。

原点命名空间-

使用多层缓存架构的一个结果是,用于客户端到边缘通信的原始主机名经常丢失,例如在对架构内的更高层缓存进行后续请求时。在url到映射环境中,这种信息丢失使主机名无法包含在映射算法中,从而将url路径保留为主键或输入变量。由于无法保证路径的唯一性,因此将发生路径到ipv6映射冲突,从而产生不期望的结果(例如,指示错误(例如,“未找到”)的http404消息,或更糟糕的是,错误地分发的资源)。为了解决这个问题,本文描述的设备的一个实施方案使用了被创建并赋予到内容原创者的“原点命名空间”。为了便利性和可扩展性,将从注册表中分配的地址赋予到一或多个资源路由(rr)前缀作为原点命名空间。如果以http头或查询参数的形式表示,cdn可以将所述信息传播到其它实体/节点,以确保原点id+路径作为全局唯一字符串存在。

映射代理标识-

在本公开的一个实施例中,cdn被配置成通过使用各种不同的方法来标识哪个映射服务器请求映射ipv6地址。例如,在资源路由(rr)启用cdn资源与多个cdn对等的使用情况下,可能存在针对每个对等cdn的多个映射服务器,并且单个资源路由cdn可能具有多个映射器。然而,必须针对非直接资源命名环境满足此要求,因此在本文中提出了针对此问题的两种解决方案。取决于给定cdn的能力,以下所述的这两种方法尤其可以独立或同时使用,并且每种方法都允许内容原创者利用服务其内容的不同片段的多个映射实体。

1.利用dns作为映射器标识符-

基于原点命名空间概念,特别是如果表示为ipv6地址,则可以使用资源路由(rr)来利用现有的in.addr.arpa(反向地址)域。具体地,in.addr.arpa域提供了一种将ip地址“反向”解析为主机名的机制。通常,进行反向查找时会关注ptr(指针)记录,因为它们将ip映射为主机名;但是,soa(授权开始)记录允许所述前缀空间的dns授权与给定原点id的适当映射服务器或进程进行通信。

2.利用未使用的bgp路由属性-

同样,使用ipv6地址作为原点标识符,可以使用bgp路由系统来与映射服务器进行通信。bgp路由通过(可以)携带多个引用ip[v6]地址的属性。其中一些可能与非基于转发的bgp基础设施无关。在这种情况下,可以“过载”这些属性中的一个以传达映射服务器信息。尽管具有多个显著属性(包含易于部署、快速收敛以及排除了外部(缓存、读取:dns)系统),但本机制还存在潜在风险;例如,一旦专用于本功能,“过载”属性将无法用于其最初定义的功能。由于这个原因,在一个实施方案中,可以定义新的(例如,任选的)可传递属性来携带本信息。例如,aggregator(类型代码7)属性可以用于为本功能提供载体,因为不期望在/128前缀上使用aggregator属性的使用情况。这有利地允许内容原创者提供动态可更新的(无dns粘性)机制,以用于将下游cdn引导至其请求的资源的“最佳”映射服务器。

示范性节点设备–

可以使用通用软件和/或硬件资源来实施本文所述的任播cdn的示范性实施例。例如,所述软件可以包括运行路由选择后台程序(例如,quagga路由选择套件)、缓存后台程序和/或路由管理器的基于linux操作系统(os)的分发缓存应用。路由管理器可以被配置成基于本文描述的一或多个度量来通告和/或撤回分发路由。

硬件资源可以包含例如通用计算硬件。节点可包含被配置成执行一或多个软件模块的处理逻辑(例如,处理器)、支持应用执行、存储的存储器以及一或多个数据接口。所述接口包含一或多个网络接口,以用于与原点服务器110、缓存层、客户端197和/或其它网络实体进行通信。存储器可以用于存储应用数据和/或缓存内容。所述存储可以用于存储内容、路由表、操作系统数据(例如,os映像)和/或其它数据。在一个变体中,与存储相比,存储器的特征在于访问时间更短,所述存储包括非易失性媒体(例如,磁性、光学和/或基于电荷的媒体(例如,闪存)),而所述存储器可以包括易失性媒体(例如,dram、sram和/或其它)。

在一或多个实施方案中,使用商用现成的计算平台(例如,dellpoweredge服务器和/或另一设备)来配置节点,这有利地消除了对定制或专用硬件的需求。可以根据目标应用的要求(例如,内容流量)来设置各个节点的硬件和/或软件配置。通过非限制性说明,与被配置成提供线性内容的节点相比,vod流量节点可以被配置成包括更大的存储。与vod节点相比,后一种节点可以包含更多更快的访问存储器。在一些实施方案中,网络具有异构配置,其中根据具体的成本和/或性能要求来定制各个节点的硬件配置。本文描述的cdn的软件“无关”实施方案有利地使得能够针对所提供的流量优化软件模块(例如,web服务器)。举例来说,可以选择apache服务器来处理线性内容,并且可以选择nginx服务器来提供vod内容。

在一些实施方案中,被配置成例如支持线性内容分发的给定硬件节点配置通过使用另外的存储(例如,硬盘)而被增强以支持vod。所述另外的存储可以体现在节点服务内和/或作为附接的阵列(例如,经由串行总线和/或作为网络附接存储)。

将认识到,尽管根据方法的具体步骤顺序描述了本公开的某些方面,但是这些描述仅是本公开的更广泛方法的说明,并且可以根据特定应用的要求进行修改。在某些情况下,某些步骤可能变为是不必要或任选的。另外,某些步骤或功能可以被添加到所公开的实施例中,或者可以改变两个或两个以上步骤的进行顺序。所有这种变型被认为在本文中被公开和要求保护。

尽管上面的详细描述已经示出、描述并指出了应用于各个实施例的本公开的新颖特征,但是将理解,在不脱离本公开的情况下,可以由本领域技术人员对所示出的装置或进程的形式和细节进行各种省略、替换和改变。前面的描述是目前考虑的执行本文公开的技术和架构的最佳模式。本说明书并非旨在是限制性的,而应被认为是对本公开的一般原理的说明。本公开的范围应参考权利要求确定。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1