问题描述
出于安全考虑，我们希望 Multicast Receiver 能够只选择接收从特定 Multicast Source 发来的组播数据，即 Multicast Receiver 需要告知组播网络，接收来自哪些特定 Multicast Source 的组播流量。
IGMPv1 与 IGMPv2 的报文中均无法携带 Multicast Source 的信息，因此无法配合 SSM 使用（其实可使用 SSM Mapping 功能解决这个问题）。
解决方案
IGMPv3 主要是为了配合 SSM（Source-Specific Multicast）模型发展起来的，提供在报文中携带 Multicast Source 信息的能力，即主机可以对组播源进行选择。
IGMPv3 vs. IGMPv2
lIFE54。ZHIli123.CoM相同点：
1）查询器选举机制一致：IP地址小的为查询器；
2）使用 General Query 报文，来查询组成员加组信息；
3）使用 Group-Specific Query 报文，来查询特定组播的成员存活情况；
改进点：
1）IGMPv3 Membership Query 报文，包含 Gereral Query、Group-Specific Query、Group-and-Source-Specific Query（新增）；
2）IGMPv3 Membership Report 报文，不仅包含主机想要加入 Multicast Group，而且包含其想要接收来的 Multicast Source 的信息；
3）抑制机制：鉴于同个组播组的不同成员可能希望接收来自不同源的组播，所以 IGMPv3 无 Report 报文抑制机制（协议本身无此设计）；
4）离组机制：IGMPv3 具有组成员离开通知机制，但是没有定义专门的成员离开报文，成员离开通过特定类型的 Report 报文来传达。
查询器选举机制
查询器选举机制与 IGMPv2 保持一致，IP Address 小的为查询器，这里不再赘述。
组成员加组机制
IGMPv3 组成员加组机制与 IGMPv2 类似，但有以下不同：
1）IGMPv3 Membership Report 报文，能够携带 Multicast Source 信息。
2）IGMPv3 Membership Report 报文，没有 Report 报文抑制机制。
组成员探测机制
lIFE54。ZHIli123.CoM在 IGMPv3 中，具备组成员离组机制，所以无需特意来探测组内是否存在成员。
组成员离组机制
1）IGMPv3 没有专门的成员离开报文，成员离开需要借助 Membership Report 实现；
2）IGMP Querier 在收到改变源组对应关系的成员关系报告后，会发送 Group-and-Source-Specific Query 报文，确认是否还有组成员存在。
改变源组关系的成员关系报告报文很多，比如终端设备原来接收来自 Multicast-Group-S1 的组播数据，那么通过发布（G1，EXCLUDE，S1）报文或（G1，CHANGE_TO_EXCLUDE_MODE，S1）报文都能够改变源组关系，但并非所有的改变都与离组相关。
The post 「IGMPv3」- 工作原理 appeared first on K4NZ BLOG.