PIM-SM——RPT到SPT的切换过程

问题背景

  • 如下图所示,PC1是组播组239.1.1.87的接收者,R4在自己与RP之间建立了一段RPT的分支,而RP则在自己与R1之间建立了SPT。后续组播流量将从Source发出,沿着SPT先到达RP,然后由RP将组播流量沿着RPT转发下去。
  • 在这个网络拓扑中,网络中的组播流量转发其实存在次优路径问题:组播流量从R1出发,流经R2,然后到R3,再到R5,这实际上是一条次优路径,一个更优的方案是,组播流量到达R2后,可以直接被转发给R5,而不用从RP绕一下。
  • 此外,网络中也会存在的另一个问题,如果所有的组播流量都需先经由RP进行分发,当流量特别大时,RP的负担将变得非常重,这也就容易引发故障。
    PIM-SM——RPT到SPT的切换过程_第1张图片

解决方法

PIM-SM的SPT切换机制可以很好地解决这个问题。

示例

以上图中的R4为例,当其在RPT上收到组播报文时,便立即知晓了组播源的IP地址(也就是该报文的源IP地址),既然已经知道了组播源的IP地址,那么R4便可以在自己与组播源之间建立一段SPT的分支,然后通过该SPT的分支直接从Source获取组播流量,由于该SPT分支是直接建立在自己与Source之间的,因此接收组播流量的路径必定是最优的。

需要注意的是,SPT切换机制是发生在与组播接收者直连的最后一跳路由器上的。缺省时,R4在RPT上收到第一份组播报文后立即触发SPT切换,具体过程如下图所示。
PIM-SM——RPT到SPT的切换过程_第2张图片

(1)最后一跳路由器处理流程:

  • 组播报文沿着RPT到达最后一跳路由器R4,R4收到组播报文后,它便知晓了组播源Source的地址,它将立即启动SPT切换(可以通过在R4上设置组播流量的速率阈值,使得当组播流量的速率达到指定的阈值后,才触发SPT切换。缺省时,最后一跳路由器只要一收到组播报文,便立即进行SPT切换)。
  • R4朝着Source的方向发送(10.1.1.1,239.1.1.87)的PIM加入报文。

(2)中间路由器处理流程:

  • 上游邻居R5收到R4的(10.1.1.1,239.1.1.87)加入报文后,将接收该报文的接口添加到(10.1.1.1,239.1.1.87)表项的下游接口列表中。
  • 然后在单播路由表中查询到达 Source的路由,明确了到达Source的出接口及下一跳IP地址后,R5继续向上游邻居R2发送(10.1.1.1,239.1.1.87)加入报文。

(3)中间路由器处理流程:

  • R2此时已经存在(10.1.1.1,239.1.1.87 )表项(source->R1->R2->RP已经构建了一条SPT),它将收到加入报文的接口添加到该表项的下游接口列表中。那么现在R2的(10.1.1.1, 239.1.1.87)表项的下游接口列表存在两个接口,一个是连接RP的接口,另一个则是连接R5的接口。
  • 当它再从R1接收(10.1.1.1,239.1.1.87)组播流量时,便会将该流量从这两个下游接口转发出去。此时网络中的组播分发树如下图所示。
    PIM-SM——RPT到SPT的切换过程_第3张图片

引入问题

因为R5此刻已经处于SPT上,同时,它还在RPT上,因此它会分别在SPT及RPT上收到重复的组播流量,这种操作显然是多余的。

解决方法

R5通过RPT修剪过程,可以将自己从RPT上剪除,解决上述组播流量重复问题。

(4)当R5开始在SPT上收到R2转发过来的(10.1.1.1, 239.1.1.87 )组播流量后,R5将朝着RP的方向发送一个特殊的(10.1.1.1,239.1.1.87 )剪枝报文,试图将自己从RPT上剪除。该剪枝报文中设置了RP比特位,这个剪枝报文会一路发往RP。

(5)RP处理流程:

  • R3收到R5发送的(10.1.1.1,239.1.1.87)剪枝报文后,将接收报文的接口从(10.1.1.1,239.1.1.87 )表项的下游接口列表中删除。
  • 当完成这个操作后,R3发现此时该表项的下游接口列表已经为空,这意味着自己不再需要从SPT上接收组播组239.1.1.87的组播流量,因此它朝着Source的方向发送(10.1.1.1,239.1.1.87 )剪枝报文,试图将自己从SPT上剪除。

(6)R2收到R3发送的(10.1.1.1,239.1.1.87 )剪枝报文后,将接收该报文的接口从(10.1.1.1,239.1.1.87 )表项的下游接口列表中删除。到目前为止,该网络中的组播分发树已经完成刷新。组播流量将沿着SPT从Source流向PCl。

你可能感兴趣的:(组播,PIM-SM)