1. 引言 (Introduction)

IEEE bridge 标准 [BRIDGE] 规定了 LAN 数据包如何在 LAN 段之间被 "bridged", 或者按今天更常用的说法, 被交换. 交换机处理多播数据包的行为可以概括如下. 当处理目的 MAC 地址为多播地址的数据包时, 交换机会按照 [BRIDGE] 将该数据包的一份副本转发到所有其他处于 forwarding 状态的网络接口. Spanning tree 算法确保网络中每台交换机都应用此规则时, 该数据包可被连接到网络的所有节点访问.

这种行为很适合原本就希望所有连接节点都看到或处理的广播数据包. 但对于多播数据包, 这种方法可能导致网络带宽利用效率较低, 特别是当数据包只面向少数节点时. 数据包会被泛洪到没有任何节点希望接收该数据包的网络段. 虽然节点为过滤发往未请求组地址的数据包通常几乎不会产生处理开销, 但在多播数据包被泛洪的这段时间内, 它们无法在共享介质上传输新的数据包. 总体而言, 泛洪可能浪费大量带宽.

近年来, 多家商业厂商向市场推出了被称为 "IGMP snooping switch" 的产品. 这些设备并不遵循 ISO 模型中在不同通信层之间严格分离功能的概念模型, 而是利用上层协议头部中的信息作为下层处理时要考虑的因素. 这类似于路由器在允许数据包转发到其目的地址之前查看传输协议头部, 从而充当防火墙的方式.

对于 IP 多播流量, IGMP snooping switch 的好处是可以在那些没有节点表示希望接收发往该组地址数据包的网络段上节省带宽. 这与普通交换机行为形成对比, 普通交换机通常会在所有接口上转发多播流量.

许多交换机数据表声称支持 IGMP snooping, 但目前尚无相关建议. 作者希望本文档中给出的信息能够提供这一基础.

本文给出的建议基于以下信息来源: IGMP 规范 [RFC1112], [RFC2236] 和 [IGMPv3], 厂商提供的技术文档 [CISCO], bug 报告 [MSOFT], 与参与 IGMP snooping switch 设计人员的讨论, MAGMA 邮件列表讨论, 以及交换机厂商对实现问卷的回复.

不同 IGMP 版本之间产生的互操作性问题不是本文档的重点. 感兴趣的读者可参阅 [IGMPv3], 其中对问题领域有完整描述.

本文档中的建议基于 IGMP, 而 IGMP 只适用于 IPv4. 对于 IPv6, 必须改用 Multicast Listener Discovery [MLD]. 由于 MLD 基于 IGMP, 我们不会重复 MLD snooping switch 的完整描述和建议. 相反, 我们只指出少数与 IGMP 不同的情况.

注意, IGMP snooping 功能应该只应用于 IPv4 多播. 如果实现中没有按照建议部分所述采取额外注意, 其他多播数据包 (例如 IPv6) 可能会被 IGMP snooping 抑制.