br>[0154] 2.源DR创建针对相同的内容的所需要的会话描述信息（会话描述协议），现在将 被切换至多播模式。根据这对于客户端重新预订多播流来说是否是必要的，也触发源以生 成针对该内容的多播特定的URI。
[0155] 已经决定切换到针对给定的媒体流的多播的源DR接着将登记消息中针对该流的 来自源的到来的分组封装到相应的RP。注意，如果单个源保存许多内容片段并且源DR已经 决定完全地切换到多播，则相应的源DR根据组地址登记带有各自RP的每个内容片段。另 选地，如果仅一些内容流被切换到多播，那么源DR仅处理针对这些流的登记消息。
[0156] 如果没有组已经由此点被创建，则RP向源发送登记-停止，但是创建至源的SPT 路由表项而没有输出接口。
[0157] 3.存在针对主机加入多播流的两种可能情况。它可以具有现有的单播会话，伴随 着媒体服务器使用诸如RTSP/RTP的媒体流协议集合，或者当它第一次请求来自源的内容 时它可以被分配多播组信息以立刻连接。当多播会话已经被建立时后者是可适用的，并且 主机很乐意接收当前被传送的数据（例如，实时流/TV而没有追赶服务）。我们将分别考虑 这些情况中的每个情况：
[0158] a.来自主机的新鲜的请求
[0159] 主机请求单播流，而不知道多播流或它的组地址的存在。鉴于存在几个包括只有 特定的殊媒体服务器实现才有的专有的那些的媒体流和控制协议，我们指定一个必须实现 从服务器到应当经由多播预订服务的客户端进行通信的方法。这可以通过在响应于客户端 浏览器的HTML中嵌入新的多播URI或者在单播请求被服务器/源DR接收到之后使用响应 消息来进行，该服务器/源DR给客户端提供组地址字符串或URI以获得这种方法。例如， 当浏览器请求该链接时，服务器改变链接到内容流的HTML字符串，使得主机被直接映射到 多播流而不用进一步交换。
[0160] b.将现有的单播流传递到多播树
[0161] 这需要从源/源DR到主机的实时反馈，需要它以建立新的多播会话。其具体的实 现依赖于针对具体的媒体流实现的协议栈。如果反向信道针对服务器是可用的以向客户端 发送命令，这可以被用于发出新的多播组地址字符串或URI以获得此。另选地，如果RTSP 正被用于单播中，则源使用宣告、重定向或者设置参数（SeLParameter)消息来请求向主 机宣布该变化。主机也可以被设置以进行周期的获得参数（GeLParamet er)请求以证实针 对它的会话的当前多播/单播状态。也可能主机请求内容以在给定的时间开始，使得流可 以从转换已经被触发的点继续进行。该特征无法被用于固定流下载中，但是我们稍后将返 回于此。如果使用HTTP，则主机可以被配置成周期性地请求流方法的当前状态，其中，媒体 服务器/源DR用新的URI或者主机随后必须建立成员关系的组地址对该当前状态进行响 应。
[0162] 两个步骤的结果是上层协议触发扩展的IP模块（RFC 1112)，该扩展的IP模块 (RFC 1112)支持多播以向它的直接连接多播路由器发出成员加入请求。大多数主机实现下 文中在我们的实施方式中将使用的但是消息本身是协议相关的IGMP。
[0163] 带有特定的组地址的IGMP成员报告（IGMP加入）被发送至主机DR。这导致在主 机DR中从它的停用状态变化到J 〇inDeSired(*，G)或者JoinDesirecKS.G)状态（实现-相 关）。针对该变化创建路由条目。
[0164] 随后，主机DR使用已知的哈希函数触发朝向RP或源的a(*，G)或（S，G)加入/删 除消息。是否触发RPT或SPT的选择依赖于实现。我们覆盖RPT所需要的设置，从其很好 地理解SPT。RFC 362和RFC 4601中覆盖了所有这些动作以及何时使用每个选项。本工作 的创新的方面是基于我们的预测的分析方法触发多播功能的网络的自主的能力。详细的实 施方式是基于PM-SM的示例。
[0165] 加入/删除消息基于单播路由协议（0SPF、IS-IS、RIP是这种的示例）逐跳的朝向 RP或源行进。使用原始的多播方法完成建立树的该方面。随后，RP或源开始从所请求的时 间范围（如果可适用）向主机多播内容。在这一点上，主机接收相同的内容的两个副本。
[0166] 完成到多播的切换的最后的方面是主机去检测相同的内容的多个副本被正被接 收的能力。这可以通过媒体播放器使两个流（在不同的接口上接收的，由上层协议指定） 彼此匹配并且使用模式检测以识别一个流等同于另一个流。明显地，除了由于网络拥塞的 性质和逐跳传递导致的流之间的潜在的时延变化之外，传输中的错误应该被考虑。
[0167] 另外，值得注意的是接收到的两个流在时间上不是精确地匹配的情况。在该实施 方式中，我们假设所有主机接收相同的实时流并且基本上是同步的。然而，由于网络延时， 分组可以在不同的时间到达主机，导致单播流和多播流之间的小的时间差。接收主机必须 能够使用它的缓冲能力或者对于媒体播放器使可用的上层协议从一个流转换到另一个流。 主机的缓冲器可以存储两个流上到来的分组，如果是支持的/可应用的则潜在地也请求丢 失的块，同时仅向用户播放一个同步的流，直到两个流交叠。如该协议所指示的，一旦这已 经被实现，不考虑单播流是在通过多播树接收的流之前还是之后，主机必须结束与源的单 播会话。在RTSP中，例如，这是通过向服务器发送拆卸消息（Teardown message)来完成的。 如果对于多播来说转换无法被实现，则主机可以发出离开该组的IGMP，这导致它的组成员 被终止并且在该接口上不再接收多播。另选地，可以使用单播故障修复机制。
[0168] 注意，当我们使用P頂-SM、IGMP和RTSP或HTTP作为示例时，我们的目的是覆盖该 功能而不是阻止在主机、路由器和媒体服务器之间向后和向前发送特定的消息。
[0169] 上述过程的结果是已经用情报加强源/源DR以决定根据内容的使用和它的预测 需求自主地触发网络中的多播。我们的系统的发明的方面是智能能力和机制以使用称为 "多播使能器"的新颖的实体自主地触发从多个单播流到单个多播流的切换，并且它的效果 是触发多播树的构建以及对于该树的源/主机成员。当我们假设这里的单个建树机制时， 其它实施方式也可以使用多个多播树。
[0170] 来自多个源的相同的内容流的合并
[0171] 该部分描述了可以如何使用由内容服务器的源DR应用的技术将从多于一个的内 容服务器被发送的多个相同的流合并到单个服务器上。
[0172] 我们考虑具有来自一个以上的内容服务器的可用的相同的内容片段的附加的复 杂性。鉴于到目前为止我们已经描述的，客户端将（潜在地通过负载平衡器）被单独地指向 这些服务器中的每个。这可以导致两个内容服务器可以潜在地分别发送X个和y个会话的 情况，这里X和y值两者都没有达到满足触发多播的条件，但是在单个内容服务器上（χ+y) 个会话的组合实际上将触发多播。我们提供优化该条件的解决方案。
[0173] 我们提出当在源DR处从客户端接收到请求时，发现包括该内容的副本的哪个DR 当前具有针对该段内容的激活的会话。这通过使用诸如HTTP的协议来完成，以向其它源DR 宣布给定的请求已经到达生成该告知的源DR。例如，对于在两个内容服务器A和B上是可 用的内容X，到达服务器A的请求触发从服务器A到B的消息，宣布对内容X的请求已经到 达服务器A。服务器B在接收到该请求时验证它的多播表（上述表1)以确定在到客户端的 会话中内容X当前是否被发送。在这一点上，内容是否作为单播或多播正被发送并不重要。
[0174] 然后，我们可以具有两种情况：一种是服务器B不具有针对该内容的激活的会话 (即，不存在具有特定内容片段的其它服务器），在这种情况下，服务器A继续处理如上所述 的请求，好像它是内容X的仅有的提供商。它可以根据规定的条件将该内容作为单播提供 给请求客户端（例如，所谓的C)，开始新的多播流或者如上所述给用户预订现有的多播流。
[0175] 然而，如果服务器B在其表格中不具有针对内容X的现有的会话，那么它将该信息 返回到服务器A。服务器A现在向客户端C发出带有针对服务器B的地址的重定向消息。 一旦客户端向服务器A发送对内容X的请求，则该内容服务器继续处理该请求，好像它是内 容X的仅有的提供者。
[0176] 使用该机制，我们合并会话请求使得单个片段的内容将由一个内容服务器服务， 并且当相关条件被满足时，多播将从该内容服务器被触发。当当前会话结束时，对内容X的 下一个请求将被发送到两个内容服务器的两者之一（例如，由负载平衡器所确定）。这导致 这样的系统，即，只要内容服务器继续发送一段内容，它将经由从其它源DR重定向继续接 收所有对该段内容的请求，并且将必须将该内容提供给客户端。当在内容服务器上没有针 对一段内容的更多激活的会话时，下一个请求将由下一个分配的内容服务器服务，该内容 服务器接着将是针对未来会话的主要的合并点，直到没有更多激活的会话。
[0177] 工作的示例
[0178] 这里我们提供在现有的RTSP会话上切换到多播会话的示例，假设后面的请求触 发多播，并且网络必须参与到包括建立针对现有的内容用户的成员的多播模式下，该内容 用户被源切换到多播流并且随后终止现有的单播流。
[0179] 尽管多播在网络中不是激活的，我们针对该示例假设一些背景任务被实施。当多 播没有被开启时实施这些任务一直不是必要的，但是当触发条件最后被满足的时候执行它 们可能减少全部操作的时间。这是如在标题为"来自多个源的相同的内容的合并"的上述 部分中所描述的。我们考虑使用针对单播和多播两者的局部范围的地址的专用网络。BSR 被周期性地选择，C-RP使用以" 0"作为它们的组地址的C-RP-Adv消息向BSR告知它们的 候选资格。BSR有规律地向" ALL-P頂-ROUTERS "灌注引导消息以向休眠的P頂路由器传达 RP设置，使得当一旦多播必须被进行而不需要必须等待RP设置被发送给它们时，它们可以 执行组到RP映射哈希函数。第三，DR选择使用断言消息规律地发生以确保每个子网或本地 主机的组具有当需要时可以接收它们的成员报告的多播使能的路由器。第四，使用到彼此 的周期的Hello消息保持P頂路由器是活动的。可以在P頂-SM RFC 4601和RFC 2362中 发现执行这些任务的方法论和选项。
[0180] 现在考虑由主机Hl (地址：10. 1. 4. 10)请求的到源S(IP地址：192. 168. 10. 10)的 固定流，这在浏览器（rtsp://example. com/application/contentStream)上使用提供给 Hl的URI已经被解决。我们称该固定流为C1。假设该URI映射到仅一个源地址以便避免 由负载平衡器引入的复杂性。另外假设主机支持RTSP。媒体播放器使用RTSP设置消息触 发对该URI的请求。该流的设置、播放和控制是现有技术并且可以从RFC2326理解。
[0181] 表2 :在来自Hl的请求之后从Turi提取，时间是t = 16. 58
[0182]
[0183] 在稍后的时间，主机H2 (IP地址：10. 1.4. 11)也请求相同的URI。这再次触发评 估逻辑。根据表2,我们现在具有Turi中的以下参数：N = 20、AD = 97、P = 0.0 US = 567、 PSt+1= P 18= 233〇
[0184] 使用我们的评估逻辑<