HCIP-Datacom Core Technology V1.0_18 PIM原理与配置
PIM基础介绍
组播网络基本架构回顾
组播数据转发流程回顾
正常情况下，组播源将它的组播数据推送到第一跳路由器之后，就正式开始整个组播数据的转发，会通过RPF检查，然后再根据组播路由表项，进行数据的转发，然后将这个组播数据沿着构建的组播分发树推送到最后一跳路由器，最后由最后一跳路由器根据IGMP协议，将该组播流量推送给特定的接收者，来实现整个组播数据的正常接收，现在只差最关键的一 步，如何在组播分发网络中去构建这个分发树，帮助去实现从第一跳路由器，传递到最后一跳路由器，同时避免环路的产生。
组播协议介绍回顾
整个组播转发网络中其实是比较复杂的，正常情况下，如果是跨域的组播网络，网络规模就非常大，可能会涉及到不同的组播路由协议，比如说PIM协议无关组播这个协议，它主要是帮助去构建单域类的最大分发树，如果是帮助去跨域之间进行数据转发，还需要通过MSDB来实现，同时在跨域之也要进行一个RPF的流量检查，这个时候还需要MBGP，因此，会发现这样的一个组播网络其实是比较复杂的，本章课程主要是介绍单域内的PIM原理与配置章节。
PIM协议介绍
PIM协议它的全称叫做协议无关组播，很多人现学习这个协议的时候，其实就有点困惑了，为什么这样说呢？因为这个协议明明是用在组播转发网络中，帮助去构建组播分发树的，为什么它的名字又是叫做协议无关组播呢？其实这里去了解它的基本工作原理就不难理解它的叫法了。因为它是根据单播路由表，然后去进行一个RPF检查，RPF检查之后，再通过相应的组播路由表项转发组播数据流。但是这一关键在于，它是利用单播路由的结果进行RPF检查和转发组播数据，而自己不需要维护单播路由协议。这里的协议无关是指与单播路由协议无关。因为它不需要自己去维护单播路由表，它是直接把单播路由表里面的结果拿过来直接构建它的一个转发分发树。如果自己再单独用一个组播路由协议去建立组播转发路径，这样设备消耗的资源就比较大，直接利用单播路由表里忆经建立好的转发路径，去实现转发组播数据流量，又不需要自己去维护单播路由表里面的资源，因此对我来说是一个一劳永逸的事情。
PIM有两种工作模式，分别是Dense Mode，和Saprse Mode。其中Sparse稀疏模式又根据组播服务类型分为两大类，分别是为任意源建立发发树和指定源建立分发树。
PIM-DM与PIM-SM使用场景
Dense Mode一般是用在成员比较少，但是相对集中的一个应用场景中，它的工作机制是非常多的，比如实现一个扩散，然后再裁剪这样的一个工作机制，而Sparsse Mode是比较适用于成员非常多，但是因为网络规模很大，成员分散在各个角落，因此，比较适用于成员多且分散在稀疏的网络规模中，它也有自己的工作机制。在现网中用的最多的是第二种，Sparse Mode。
组播分发树的分类
RP（Rendezvous Point，汇集点）是PIM-SM（稀疏模式）中的核心概念，用于构建共享树(*, G) 表项。
组播分发树主要的作用是构建分发树，分发树分为两种类型。第1种，如果是以组播源为根构建的分发树，为SPT，又称它为源树，因为是以组播源为根的，其中组播组的成员为叶子，STP无论是在Dense Mode中，还是在Sparse Mode中都会去使用它。第二种RPT，是以汇聚点RP为根构建的树，它又称共享树，这种树只有在PIM稀疏模式中。
PIM路由表项
在PIM路由表项里面，主要是通过PIM协议去构建组播路由表项，在PIM网络中一共存在两种路由表项，分别是(S，G)表项和(*, G)表项，针对(S,G)和（*，G）这两个概念应该很熟悉了。所谓的(*,G)是指并不知道数据源，只知道想好要加入的组播组。(S,G)是代表既知道组播源是谁，又能表明自己想要加入的组播组。（S,G）表项主要是用来建立SPT。（*，G）主要是建立RPT。
问题:(*，G)表项在PIM-DM模式中存不存在？
在 PIM-DM（密集模式）中，不存在 (*, G) 表项。
PIM-DM 基于源树（最短路径树，SPT）转发组播流量，所有表项都是 (S, G) 形式，没有汇聚点（RP）的概念，因此不会生成 (, G) 共享树表项。
而 PIM-SM（稀疏模式）中才会使用 (*, G) 表项来构建共享树。
在（*，G）表项中，发现它缺少了哪些信息，它没有上游接口以及RPF检查，为什么它会缺少这一部分信息呢？所谓的(*,G)表项，是指不知道组播源，所以没有办法从组播源到本地路由所接收的端口，判断哪一个为正确端口，它没有办法去计算最优路径，因此，它就缺少了正确接收的上游端口以及应该做的RPF检查。
在(S,G）表项中， 就是由正确应该接收的上游接口以及RPF检查，而(S,G)表项一定是需要通过流量去触发的，因为组播路由表项和交换机的MAC地址其实非常类似，它只有流量经过的时候，它才会生成相应的表项，否则，没有流量经过的话，经过老化时间，它会在表项里面消失了，而不像单播路由协议它会一直存在。
正常情况下，如果关于(S,G)的组播流量，经过了运行了组播协议的路由器，首先它会进行一个RPF检查，然后如果有(S,G)表项，它就根据(S,G)表项对应的下游出接口，将该组播数据流量转发给下游设备，如果没有（S，G）表项，只有(*，G)表项，它会根据(*,G)表项去创建(S,G)表项，然后再通过(S,G)表项指导组播数据流量转发。因此，真正指导数据转发这样的一个表项是(S,G)表项。因此无论是在现网中还是在做实验中，经常会看见组播路由协议它会有两个，它可能同时存在(*,G)和(S,G)，而这个(S,G)就有可能是通过(*,G)表项进一步去创建的。
无论是(S,G)表项，还是(*,G)表项，都有个Flag字段，Flag字段里有不同的含义。这里的WC其实代表（*，G）表项。如果是ACT，代表现网中有组播流量已经到达本设备进行数据的转发。loc代表这台路由器和组播源直连的这样一个路由器上。或者说delete标识字段，可能代表这个表项即将要删除，不再指导数据转发。
PIM路由表项与组播路由表项
正常情况下，如果不是最后一跳路由器，组播路由表项是直接根据PIM(S,G)表项去映射过来的，PIM(*,G)路由表项缺少了入接口信息无法形成组播路由表。
(S，G)表项包含的内容比较多，可以看到运行的是什么模式，知道组播源和组播组信息，最关键的有上下游接口，最后将上下游接口和 （S,G）这样的一个信息，映射过来，就造成了组播路由表项，这样数据转发直接根据组播路由表项和对应的出接口，将组播数据流推送给下游设备。
有一个例外，最后一跳路由器，在IGMP协议中，最后一跳路由器，它的组播路由表项，就非常复杂，它是由IGMP组表项，IGMP路由表项以及PIM路由表项，这三个表汇总而成的，最后形成组播路由表项，而其它组播路由器，在组播转发网络中，它只运行了PIM，除了最后一条路由器以外，所经它们去构建组播路由表项是比较简单的，直接根据PIM的(S,G)表项就可以了。
PM-DM介绍
PIM-DM基本概念
PIM-DM这个模式主要用在成员规模较小，但是比较密集的网络中，通过扩散剪枝，这样的一个方式去构建SPT，同时在去构建SPT的过程中，它还会有很多机制去维护这种工作状态。
如果组播源在Dense Mode中，会将这个组播流量进行全网扩散，在扩散的过程中，如果某一台组播路由发现它的下游没有想要的组成员，再通过路径剪枝的方式，将该网段的流量进行裁剪。最后就形成了从组播源到想要接收的组播成员构建的一棵SPT，然后依赖于组播分发树去转发组播数据流量。
PIM-DM协议报文
PIM协议封装在IP报文中，采用的组播目的地址是224.0.0.13，协议号是113，它的协议报文和Sparse Mode是不一样的。
邻居发现
通过发送Hello报文去发现邻居，这个就有点类似于前面所学的路由协议，当路由协议接口激活了PIM协议之后，它就会发送Hello报文，当然Hello报文里面也包含了其他参数，比如说优选级，延迟等等，通过Hello报文的交互，然后去建立邻居关系，正常情况下，每隔30t秒发送一次Hello报文，里面有一个超时时间，正常默认是105秒，如果在超时时间内收到Hello报文，就认为邻居正常，如果超时了，依然没有收到对方发给我的Hello报文，那么就认为关于PIM邻居失效了，那有可能是设备故障或者链路断开了，这是第一步，建立邻居关系，也是去构建组播分发树的一个必要条件之一。
首次形成组播分发树
当发现邻居之后，就正式开始构建组播分发树。
在第一次构建组播分发树的过程中，一共要用到多种机制，这些机制分别有什么作用。
扩散机制，在Dense Mode中，它是假设每一个组播路由器的下游，都存在着想要接收组播信息的用户，因此它将会组播流量在整个Dense Mode网络中进行全网扩散。
断言机制，在扩散的过程中，如果遇到一个多路访问网络，这个时候就要选举一个组播转发路由器，来避免重复报文的转发。这个就有点类似于选举DR一样。比如说组播源在进行全网扩散的过程中，基中在这两台设备之间，就形成了一个多路访问，将这个组播流量转发给下游设备，就有可能造成下游接收重复的组播报文，因此，它们之间需要一个断言机制，选举一台设备，作为组播转发路由器，就有点类似于DR一样。由其中的一台设备进行数据的转发，另一台设备就不再转发组播数据流量给它的下游设备，来避免这样的一个重复性动作。
剪枝机制,在组播数据流量向下游扩散的过程中，现在某一台组播路由器，它的下游是没有任何组成员的，这个时候组播流量就不应该到达这台组播路由器，因为浪费了带宽，因此需要一个剪枝机制，针对组播路由器下游没有成员的情况下，要告诉上游，不要将组播流量转发给本台设备，来避免带宽的浪费。
扩散机制
组播源发送组播报文到第一跳路由器之后，就正式开始全网扩散，这个扩散是路由器收到组播报文之后，首先会进行RPF检查。
这个检查是检查正确接收组播流量的入接口，它是通过单播路由表去计算到达组播源的最优路径，算出对应的出接口和自己接收到的组播流量的入接口，将这两个接口进行对比，如果是相同就正常接收组播流量，如果不同就代表RPF检查失败，就进行流量的丢弃，检查通过之后，组播路由器就开始创建(S,G)表项，然后向所有的邻居开始推送组播数据流，这个(S,G)表项，默认情况下有一个老化时间，也就是210秒，刚好和前面介绍的第一个概念是有关联的，就是说(S,G)表项是由组播流量触发的，如果，在210秒内没有任何组播流量，所谓的(S,G)表项就会消失。在扩散的过程中，还会遇到一个问题，它的扩散并不是一次性的扩散的，而是周期性的从组播源发送数据流，每隔180秒扩散一次。在组播数据流扩散的过程中，可能会遇到一些问题，比如说如何避免重复组播报文发送给下游设备，如何去判断组播路由器是否想要接收组播数据流量。
pim 路由表项
<R1>display pim routing-table VPN-Instance: public net Total 0 (*, G) entry; 1 (S, G) entry (192.168.10.2, 239.0.0.1) Protocol: pim-dm, Flag: LOC ACT UpTime: 00:15:53 Upstream interface: GigabitEthernet0/0/0 Upstream neighbor: NULL RPF prime neighbor: NULL Downstream interface(s) information: Total number of downstreams: 1 1: GigabitEthernet0/0/2 Protocol: pim-dm, UpTime: 00:15:53, Expires: never下面的是一个多播路由表项,(S,G)表项。
多播路由表项
<R1>display multicast routing-table Multicast routing table of VPN-Instance: public net Total 1 entry 00001. (192.168.10.2, 239.0.0.1) Uptime: 00:13:37 Upstream Interface: GigabitEthernet0/0/0 List of 1 downstream interface 1: GigabitEthernet0/0/2多播转发表项
<R1>display multicast forwarding-table Multicast Forwarding Table of VPN-Instance: public net Total 1 entry, 1 matched 00001. (192.168.10.2, 239.0.0.1) MID: 0, Flags: ACT Uptime: 00:15:13, Timeout in: 00:03:25 Incoming interface: GigabitEthernet0/0/0 List of 1 outgoing interfaces: 1: GigabitEthernet0/0/2 Matched 40172 packets(54473232 bytes), Wrong If 0 packets Forwarded 40172 packets(54473232 bytes)断言机制
断言机制选举规则
正常情况下，组播流量到达路由器之后，第一次会以扩散的形式进行发送，假设这两台设备分别是A和B，当它们从相同的组播源收到相同的组播数据之后，就会进行扩散，同时，会发现路由器A,B,C它们在一个共享网络中，因此，A和B会从邻居也就是说从对方收到组播报文，它个时候，它们就会产生一个疑问，收到的组播报文和要发送的组播报文，是相同的组播，这个时候它们就会发送一个断言报文来进行一个竞选，这个竞选有点类似选举DR，获胜者用来向下游发送达样的一个组播数据。先比较自己到组播源的单播路由优选级，如果优选级相同，再比较开销，如果开销也一样，最后比较下游接口的IP地址大小，通过前面这两个条件，这是不是就是路由表中选举最优路由的两个条件。因此大家可以理解一下，所谓的协议无关组播是什么样的一个概念。通过这样的一个机制也能够判断出，实际上这是为数据源从自己本身，到组播源选择一条最优最短的路径。然后为组播数据向下游进行转发。按照图中的案例可知，当它们发送Assert断言报文之后，先比较路由的优选级，都是20，但是路由器A到达组播源的开销小一点是3，因此，它就成为获胜者，为下游转发数据流量，这个时候，失败者不再为下游转发任何组播流量。同时，会启动一个定时器，这个时间是180秒，也就是说失败设备180秒之后会重新参加选举，比较Assert报文里面的参数，重新成为获胜者，这个180秒参加选举重新比较，其实有点类似于去判断获胜者设备它是否产生故障，是否需要切换。
剪枝机制
首先组播数据源第一次扩散组播数据流量，到达RT2和RT3,现在通过断言机制，RT3获胜，向下游转发组播数据流量，到达RT4,这个时候RT4又将组播数据流量进行进一步扩散，发送给RT5,这个时候问题来了，RT5的下游并没有任何关于该组的成员，也就是说它不需要接收任何该组的组播流量，这个组播流量达本设备之后，实际上是浪费的，反而增加了设备之间的链路带宽和负荷，因此，它就会产生一个剪枝机制，来避免这样的一个资源的浪费。
R5会触发剪枝机制，向上游发送Prune报文，希望上游不要再将该组的组播流量发送给我，同时，自己组播路由器对应的出接口变成了空接口，但是该组播路由表依然会保留，是为了后续如果有新成员要加入，而上游设备收到这样的一个剪枝报文之后，它会将对应的出接口IF3,从组播路由表里面删除，保证组播数据不再下发给RT5。完成一个剪枝的过程。这样就避免了RT4和RT5之间浪费不必要的带宽去发送组播数据流量。同时也避免了设备RT5去处理下游没有任何成员的组播流量。
当通过一系列的机制之后，组播分发树其实就已经确定完成了，这个时候组播流量就会沿着源端，按照组播分发树发送给接收者成员，正常情况下，组播分发树形成之后，不会发生任何改变，但是如何去维护这个组播分发树呢？第一个持续发送组播报文，组播里面的(S,G)表项，是一直需要通过接收到的组播流量报文进行维护的，否则就会进行老化删除，所以为了保证组播路由表项一直存在，需要一直有组播报文的存在才能进行维护。第二个发送状态刷新报文，来维护下行接口不发生任何改变。
实际上相关的接口剪枝完成之后，其实它会启动一个定时器，也就是RT4的IF3接口，这的定时器是210秒，也就是说，剪枝的接口，210秒之后会重新恢复，给下游发送该组的组播数据流量。如果下游没有任何成员，重新再进行剪枝。但是这样会有一个问题，如果210秒之后，下游依然没有任何接收成员，要重新进行流量的扩散，发送给下游设备，再重新进行一个剪枝的这样的流程，实际上是没有必要的，如果去维护这个剪枝状态呢？那就是状态刷新报文。
状态刷新机制
当RT4，将IF3进行剪枝之后，它就会启动一个定时器，这个定时器从210秒之后，重新恢复给下游设备，发送组播数据流，但是下游持续没有任何组成员想要接收，应该保持着该状态成为剪枝状态，而依然不恢复，否则就要重新建立一个剪枝状态，这个时候就会用到刷新机制里面的刷新报文，由组播源的第一跳路由器，周期性的每60秒发送一次，进行全网扩散，当接收的路由器收到状态刷新报文之后，会将该接口的定时器重新计时，避免恢复为下游设备转发组播流量。这就是状态刷新报文的好处，能够使剪枝的端口一直处于抑制转发状态，但是呢，大家是否又可能会产生一个新的问题，如果下游设备没有任何组播成员，需要长时间给它维持在一个抑制的状态，不转发任何组播数据流量。但是如果下游有成员想要加入该组，接收组播流量，该怎么办，通过状态刷新这样的一个机制，是否这样的一个剪枝端口就一直处于抑制状态，无法去恢复它的转发状态，这个时候就要利用到它前面的一个机制，扩散机制。组播数据流每隔180秒从源端开始扩散，也就是说180秒之后，可以通过该端口将流量扩散下去，给这样的一个组播成员，重新建立一棵组播分发树，但是这样的周期是不是又太长了，有没有更好的办法，既能够避免这样周期太长的更新，又能够在如果下面没有组播成员的情况下，抑制该端口。
新成员加组
当有新成员加入到组播组之后，分发树就要进行更新，如何进行更新呢？正常情况下有两种办法，第一种办法是通过组播路由表超时，进行全网周期性扩散泛洪来进行更新，但是这种方法一般是无法控制的，所以在现网中一般也不会推荐大家去使用这种，通过依赖于定时器的办法进行更新，所以就衍生出了一个新的机制，叫做嫁接机制。
嫁接机制
当有一个新的成员要加入到组1后，这个时候成员主机发送IGMP成员报告报文，给上游设备RT5,这个时候RT5它应该立马就知道想要接收该给的组播数据流量，但是这里就有个问题，RT5的上游RT4,该端口一直处于一个抑制状态，无法发送组播流量，如果需要等待周期性的扩散，这样的时间间隔又过于长久，为了避免这种情况，就支动向上游发送一个嫁接报文，告诉上游设备RT4，现在我的下游有新成员想要接收该组的组播流量，你可以将该组播流量发送给我了，当上游设备RT5接收到嫁接报文之后，它的出接口立马将移除的端口重新添加到出接口中，将该组播流量发送给RT5,也就是说将它的端口状态重新恢复到发送组播数据流量的初始状态，从而进行了一个组播分发树的更新，从这里能够看出什么呢？在Dense Mode中状态刷新报文，是针对假想下游，没有任何组播接收成员，进行发送，使端口一直处于一个抑制状态，而如果有下游有想要加入的组播成员，是通过嫁接机制主动反向去重新桥接分发树，来进行一个分发树的更新，也就是说，这两个机制是针对不同的应用场景下去使用的。这两个机制结合在一起，就完善组成了Dense Mode中非常重要的组播分发树，维持和更新的两个概念。
PIM-SM介绍
PIM-SM(ASM)工作原理
PIM-DM的局限性
在网络规模比较大的时候，Dense Mode有很多问题，因此现网中大部分使用的是 Sparse Mode。
在整个网络中，如果网络规模非常大，通过扩散剪枝的方式，全网去扩散组播报文，而且是周期性的，每隔180秒扩散一次，对于网络具有一定的冲击力，这种冲击力就类似于设备的处理，还有链路的带宽影响是比较大的，第二个是某些组播路由器它下面并没有相关的成员，但是它依然需要维护关于PIM的组播路由表项，同时还需要发送相关的剪枝报文，去维护定时器，因此，就完全浪费了设备的性能，对于它而言是没有任何意义的，最后一个是在一个成员比较稀疏的网络里面，如果还是采用Dense Mode，假设在网络里面只有两个用户，剩下没有任何组播组的成员，那么通过扩散剪枝的方式，对整个网络而言是非常大的，而且效率也不是很高，每一台组播路由器既要维护组播路由表项，还要维护相关的定时器，同时对于它而言也没有任何相关的组播组成员，所以效率显得非常低下。面对这些种种问题，一般使用Sparse Mode。
PIM-SM(ASM)介绍
基本组播数据源，Sparse Mode又分为两种类型，是任意源还是指定源。
使用扩散剪枝的主要原因在Dense Mode中是因为它没有办法去确定用户在哪里，所以综的工作的核心思想是假设每个组播路由器下面都有所谓的潜在用户，因此它才会扩散组播流量，而Sparse Mode和Dense Mode最大区别是它事先告诉了某一台组播路由器也就是汇聚点RP，让它知道用户在哪里，再去构建组播分发树，这样就避免了对整个网络的影响，并不是所有的路由器都需要去运行组播路由协议，维护相关的组播路由表项。
Sparse Mode构建树的一个核心思想：第一个有一个非常重要的点叫汇聚点RP，这个汇聚点RP它类似于一个中心点一样，所有组成员的位置首先要告诉这个组播路由器，然后组播源在发送数据流量的时候，也会将组播流量首先转发给RP，因为RP知道哪些成员在哪里，它再通过将组播数据转发给相应的成员，避免了带宽的浪费，同时面对一些部分的次优路径，它还能进行一个自我的优化。
PIM-SM(ASM)协议报文
Sparse Mode和Dense Mode是有些区别的，但是它发送的目的地址和IP协议号都是一样的。
RP介绍
汇聚点RP它就相当于是一个通上达下的中心核心设备，因为它连接着组播源，又要知道接收者用户，所以在整个PIM的路由器中必须知道谁是RP。在配置RP的过程中有两种办法，第一种手工在所有PIM路由器上去静态告诉RP的地址是谁，应该怎么去把数据流发给RP，但是这种明显比较适用于小型网络。第二路是动态RP选举，通过相关机制去选举汇聚点，比较适用于大中型网络，在这里需要提一个重要的一点是，一个组播组只能有一个RP，但是一个RP可以有多个组播组提供服务。也就是说不同的组播组可以有不同的RP,它们可以去选择为哪些组播组提供服务，在选举RP过程中可能会涉及很多参数。
动态选举RP
在选举RP的时候主要会涉及两个角色，一个是C-BSR，一个是C-RP。首先在C-BSR里面会选举一个Bootstrap Router，也就是BSR，这个BSR的角色类似于一个公平的裁判一样，在所有的裁判路由器里面选取一个最公平的裁判路由中器，它是用来收集C-RP信息，然后在C-RP里面去选举一个RP，然后裁判BSR将选取完成的RP信息，通过PIM报文的形式，扩散给所有运行PIM协议的路由器，让它们得知谁是RP。从图中的案例可以了解一下，比如说相关的组播路由器配置了C-BSR和C-RP,首先每台C-BSR运行之后都认为自己是BSR，然后它们互相交互报文，通过里面的参数去比较，谁是BSR，从图中可以看出，左边的为BSR，BSR选举完成之后，由它来收集整个组播网络中C-RP这样的一个信息，然后通过相关的参数比较，比如说C-RP所支持的服务掩码长度以及优选级，通过这些参数的比较选举出来，哪一台设备作为RP，最后它会通过PIM报文将谁是RP这样的一个信息，在全网进行泛红，告诉这些路由器谁是RP，这样就通过动态的机制选举出来最合适的RP，而且也不需要管理员手工静态在每一台设备上进行配置。
首次形成组播分发树
选举完RP之后，正式开始构建分发树，其中在Sparse Mode任意源模型中，分发树有两个，首先以RP汇聚点为根，构建的共享树RPT，第二个是以源为根到RP构建的SPT，其中在整个构建树的过程中，可能也会遇到多路访问网络，为了避免重复的报文，它和Dense Mode一样，也类似于一个DR的这样的一个选举，来避免这样的一个重复的组报文，转发给下游设备。
这个树主要有两部分组成，首先是由成员端DR向汇聚点RP构建一棵RPT，然后再由RP到达源端，去组成一个STP，然后数据流首先会沿着STP，到达汇聚点，然后再由汇聚点给最后一跳路由器，然后再转发给组播组成员，因此，它这棵树是由两部分组成的。
RPT构建
第一个，以RP为根，就开始建立这样一颗RPT。
当组播组成员想要加入到组之后，就会发送IGMP的成员报告报文，会给成员端DR，上图中会有两个DR，一个是源端DR，一个是成员端DR，无论是源端DR还是成员端DR，它的作用都是一样的，为了避免重复报文，只不过一个是在源端，一个在成员端网络里面。当成员端收到了IGMP成员报告报文之后，开始向RP去发送一个基于RP消息的Join报文，这个报文是沿着RP沿途发送的，中间所有经历的组播路由器，在向RP发送Join报文消息的时候都会建立一个(*,G)表项，为什么是(*,G)表项，因为只知道汇聚点是谁，而现在针对的是ASM，不知道源端，只知道汇聚点RP，所以创建的是(*,G)表项，沿着成员端DR到汇聚点RP，沿途发送Join报文，就构建了第一棵RPT，是以RP为根，构建的而成的共享树。
组播源注册机制-形成SPT
成员端到源端DR，这是如何建立组播分发数SPT。
首先组播源将组播报文发送给源端DR之后，源端DR会将报文封装在Register报文中，然后以单播的形式发送给汇聚点RP，这一点非常重要。也就是说组播报文封装在Register报文中，同时是以单播的形式发送给汇聚点，而汇聚点收到这样的一个报文之后，会向源端DR反向发送Join报文，建立SPT。为什么需要组播源注册机制，因为现在所服务的是任意源，这样的一个流量模型，因此，在第一次发送组播报文之前，并不知道谁是源端，所以只有源端在汇聚点注册之后，才能建立(S,G)表项，如果它没有注册，没有办法直接从自己然后到源端DR，发送Join报文构建(S,G)表项。
当源端将组播报文封装在Register报文中，以单播的形式发给汇聚点RP之后，其实这棵SPT已经构建完成了，但是还需要做一些后续的操作，因为源端虽然已经构成了从DR到RP的SPT，但是源端的DR依然会将组播报文封装在Register报文中，发送给RP，这个时候会造成什么问题。第一个源端最初发送的是单播报文，会增加DR和RP的工作量，为什么呢？因为RP要将单播报文解封装之后，拿出组播报文，再沿着汇聚点RPT这棵树，发送给组播组成员。源端DR收到组播报文需要封装。因此这个组播数据流量要先封装成单播，再到RP点解封装成组播再发送，针对这两个设备而言，工作量就比较大。
组播源注册机制-转发组播数据
一旦形成SPT之后，源端DR既发送单播，又发送组播报文，这两种流量里面就重复了，包含了它想要发送的组播数据。因此，SPT一旦建立之后，汇聚点RP立即会发送Register-Stop报文给源端DR，告诉它后续的报文可以直接以组播的形式沿着所建立的SPT发给汇聚点RP，而不需要重新封装成单播再发送给DR，同时也会沿途通过STP建立(S,G)表项，这个就是组播源的注册机制。
这两棵树合在一起，为它的整个组播转发流量。
首先成员端DR，发送Join消息，构建(*,G)表项，建立起一棵RPT，然后通过组播源注册报文之后，会建立起一棵SPT，这里需要注意的是第一次发送的组播报文是以单播的形式沿着SPT，到达汇聚点RP，RP解封装之后，立马会将这个组播报文沿着RPT首先发给用户。然后RP向源端DR发送Rigister-Stop报文，让它下次的流量是以组播的形式发送给RP，这样后续的所有的组播流量就会沿着所构建的SPT加RPT这棵树发送流量给接收组成员这就是它整个转发过程。其中一定需要理解的是组播源的注册机制。
源/末端网络中的重复组播报文
在源端或者末端都可能接收到重复报文，那是因为可能会存在着一个多路访问网络，面对这个问题，就要选举一个类似于DR的角色。所谓DR的角色就是避免重复报文的出现，减轻链路的带宽负荷和设备的处理负荷。
PIM DR选举
PIM DR的选举只要是通过Hello报文里面的优选级和IP地址去比较，然后选举DR，当DR出现故障之后会进行重新选举。
RTP次优路径问题
之前在汇聚点RP，提到了一个概念，就是一个组播组只能对应一个RP，但是一个RP可以对应多个组播组，在特殊场景下，会发现所有的组播流量都会经过RP，由RP再进行转发，这个时候就会产生一系列问题。
现在假设有两个组播源数据分别是S1和S2,它们都对应同一个汇聚点RP，那么第一个问题，所有的数据流量都会经过汇聚点RP，那么对于RP就会形成一个巨大的负担。第二个比较重要的问题是有可能产生次优路径问题，假设组播组成员想要接收G1组的数据，下面一个组播组成员想要接收的是S2的消息，所有的流量都会经过RP。但是针对组播流量(S1,G1)而言，从上面转发而言，并不是最优路径，转发流量从RT2到RT4，再到RT5直接转发给这台PC，是最优路径。因此面对这种情况就产生了一个次优路径的问题。为了解决次优路径的问题，在Sparse Mode中又衍生出了一个新的机制，就是STP切换机制。
SPT切换机制
当数据到达汇聚点RP之后，RP会沿着RPT将数据发送给成员端DR，这个时候成员端DR接收到组播流量之后，它就知道了组播源是谁，立马根据组播数据中的源IP，反向建立从自己到达源的一棵SPT，去判断汇聚点是否在这棵最短的STP上面，用于是否要进行一个STP的切换。成员端DR接收到组播报文之后，由它触发SPT切换，通过自己向源端发送Join消息，形成一棵最短的SPT树，然后它中间会经历相关的端口检查，这个端口就是通过RPF的检查端口，去判断是否是最优路径，然后沿着最优路径向源端发送Join消息，形成了一棵SPT，去判断汇聚点是否在这棵最短SPT上，如果不在的话，针对次优路径，它会主动触发Prune报文，进行一个剪树状态，然后再由成员端DR去维护相应的端口状态，保持数据流量从最优路径转发数据报文，而避免了非要经过汇聚点RP产生次优路径。其实从这个切换机制不难看出，说白了简单概括一点，就是当成员端DR收到了组播报文，通过里面的源IP，它要判断一下，现在接收的组播流量是否是从源到自己本身的DR最优路径，因此它会类似于去怀疑一下，这个RP是否在最优路径上面，所以它为什么会需要去反向建立一棵SPT。
维护组播分发树
当切换之后，最优的SPT稳定之后，成员端也会周期性的发送相关的Join报文和Prune报文，去维护相关的端口，来保持这棵最优路径一直为用户持续转发组播数据流量，除非210秒内没有任何组播流量，相关的路由表项就会消失
PIM-SM(SSM)工作原理
SSM概念回顾
用户组成员在加入组消息中，不仅表明了自己想要加入的组播组，还指定了自己想要接收针对哪些源发送的组播组消息，这样就使生成的表项中不仅有组播组的信息，还有组播源的信息，比如说这台组播组成员在发送IGMP成员关系报告报文中指定了想要接收来自于源1的组播消息，虽然组播源1和组播源2都能提供相同的服务，但是只有关于组播源1的流量才能给我这台设备提供服务。
PIM-SM(SSM)基本概述
如果在PIM的Sparse Mode中，基于指定源的流量模型中，去构建SPT指导流量数据转发就非常简单了，因为指定了源是谁，所以不需要维护RP，也不需要构建RPT，也不需要注册组播源，所以它的机制构成就非常简单，只有邻居发现，DR竞选和构建SPT，其中邻居发现和DR竞选和前面的工作机制是相同的，只需要反向建立SPT，转发数据流量就可以了。
组播分发树形成与维护
在构建组播分发树基于SSM的流量模型中，它主要是依赖于IGMPv3的报文和Join消息，因为只有IGMPv3的成员关系报告报文中才携带了指定源。
首先由组播组成员发送IGMPv3关系报告报文，表明自己想要加入哪个组，同时包含了指定源，到达成员端DR之后，成员端DR根据成员关系报告报文中的组播源，发送Join报文，沿途所经过的设备都会向源端发送Join报文，同时形成一棵组播分发树SPT，构建(S,G)表项，然后再相应的这样的一个端口，通过周期性的发送Join报文来维护组播分发树，但是在ASM的模型中不同的是，基于SSM的构建的分发树会一直存在，不会因为没有组播流量而消失，因为自己会通过周期性的发送Join报文去维护这棵生成树，这个是最大的区别，而不像前面几种类型都是要组播流量，经过设备，通过接收组播流量，来去维护自己的这样一个分发树，至此，就构建完成了组播分发树，组播源就沿着SPT，直接从源端DR到成员端DR,同时这是一棵最优的路径，帮助去实现组播流量的转发。因此会发现，基于SSM的Sparse Mode，非常简单。
PIM模型比较
本章协议，PIM协议，主要是应用在单域内，帮助实现在组播转发网络中，从第一跳路由器转发组播流量，沿着构建的分发树，给最后一跳路由器，其中主要分为Dense Mode和Sparse Mode这两种类型，现网中使用的最多的是Sparse Mode，其中Sparse Mode根据流量又分为两大类，其中比较复杂的是基于ASM的流量模型，它里面有很多源端注册机制，反向SPT切换机制。反观基于SSM的工作模型就非常简单，因为它不需要维护RP,它直接从成员端向源端构建一棵SPT，指导数据流量转发。