问题背景
- 如下图所示，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的SPT切换机制可以很好地解决这个问题。
示例
以上图中的R4为例，当其在RPT上收到组播报文时，便立即知晓了组播源的IP地址(也就是该报文的源IP地址)，既然已经知道了组播源的IP地址，那么R4便可以在自己与组播源之间建立一段SPT的分支，然后通过该SPT的分支直接从Source获取组播流量，由于该SPT分支是直接建立在自己与Source之间的，因此接收组播流量的路径必定是最优的。
需要注意的是，SPT切换机制是发生在与组播接收者直连的最后一跳路由器上的。缺省时，R4在RPT上收到第一份组播报文后立即触发SPT切换，具体过程如下图所示。
（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)组播流量时，便会将该流量从这两个下游接口转发出去。此时网络中的组播分发树如下图所示。
引入问题
因为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。
