1. Introduction

The IEEE bridge standard [BRIDGE] specifies how LAN packets are 'bridged', or as is more commonly used today, switched between LAN segments. The operation of a switch with respect to multicast packets can be summarized as follows. When processing a packet whose destination MAC address is a multicast address, the switch will forward a copy of the packet into each of the remaining network interfaces that are in the forwarding state in accordance with [BRIDGE]. The spanning tree algorithm ensures that the application of this rule at every switch in the network will make the packet accessible to all nodes connected to the network. IEEEブリッジ標準[BRIDGE]は、LANパケットがどのように「ブリッジ」されるか、または今日より一般的に使用されているように、LANセグメント間でスイッチングされるかを規定しています。マルチキャストパケットに関するスイッチの動作は次のように要約できます。宛先MACアドレスがマルチキャストアドレスであるパケットを処理する場合、スイッチは[BRIDGE]に従って、転送状態にある残りの各ネットワークインターフェイスにパケットのコピーを転送します。スパニングツリーアルゴリズムにより、ネットワーク内のすべてのスイッチでこのルールを適用することで、ネットワークに接続されているすべてのノードがパケットにアクセスできるようになります。

This behaviour works well for broadcast packets that are intended to be seen or processed by all connected nodes. In the case of multicast packets, however, this approach could lead to less efficient use of network bandwidth, particularly when the packet is intended for only a small number of nodes. Packets will be flooded into network segments where no node has any interest in receiving the packet. While nodes will rarely incur any processing overhead to filter packets addressed to unrequested group addresses, they are unable to transmit new packets onto the shared media for the period of time that the multicast packet is flooded. In general, significant bandwidth can be wasted by flooding. この動作は、接続されているすべてのノードが見るか処理することを意図したブロードキャストパケットにはうまく機能します。しかし、マルチキャストパケットの場合、このアプローチはネットワーク帯域幅の使用効率を低下させる可能性があります。特に、パケットが少数のノードのみを対象としている場合にそうです。パケットは、受信に関心のあるノードがないネットワークセグメントにフラッディングされます。ノードが要求していないグループアドレス宛てのパケットをフィルタリングするために処理オーバーヘッドが発生することはほとんどありませんが、マルチキャストパケットがフラッディングされている間は、共有メディアに新しいパケットを送信できません。一般に、フラッディングによってかなりの帯域幅が無駄になる可能性があります。

In recent years, a number of commercial vendors have introduced products described as "IGMP snooping switches" to the market. These devices do not adhere to the conceptual model that provides the strict separation of functionality between different communications layers in the ISO model, and instead utilize information in the upper level protocol headers as factors to be considered in processing at the lower levels. This is analogous to the manner in which a router can act as a firewall by looking into the transport protocol's header before allowing a packet to be forwarded to its destination address. 近年、多くの商業ベンダーが「IGMPスヌーピングスイッチ」と呼ばれる製品を市場に投入しています。これらのデバイスは、ISOモデルにおける異なる通信層間の機能の厳密な分離を提供する概念モデルに準拠しておらず、代わりに上位レベルのプロトコルヘッダー内の情報を、下位レベルでの処理で考慮すべき要素として利用しています。これは、ルーターがパケットを宛先アドレスに転送するのを許可する前に、トランスポートプロトコルのヘッダーを調べることでファイアウォールとして機能する方法に似ています。

In the case of IP multicast traffic, an IGMP snooping switch provides the benefit of conserving bandwidth on those segments of the network where no node has expressed interest in receiving packets addressed to the group address. This is in contrast to normal switch behavior where multicast traffic is typically forwarded on all interfaces. IPマルチキャストトラフィックの場合、IGMPスヌーピングスイッチは、グループアドレス宛てのパケットの受信に関心を示したノードがないネットワークセグメントでの帯域幅を節約するという利点を提供します。これは、マルチキャストトラフィックが通常すべてのインターフェイスで転送される通常のスイッチの動作とは対照的です。

Many switch datasheets state support for IGMP snooping, but no recommendations for this exist today. It is the authors' hope that the information presented in this document will supply this foundation. 多くのスイッチのデータシートにはIGMPスヌーピングのサポートが記載されていますが、これに関する推奨事項は現在存在しません。本書で提示される情報がこの基盤を提供することが著者の希望です。

The recommendations presented here are based on the following information sources: The IGMP specifications [RFC1112], [RFC2236] and [IGMPv3], vendor-supplied technical documents [CISCO], bug reports [MSOFT], discussions with people involved in the design of IGMP snooping switches, MAGMA mailing list discussions, and on replies by switch vendors to an implementation questionnaire. ここで提示される推奨事項は、以下の情報源に基づいています：IGMP仕様[RFC1112]、[RFC2236]および[IGMPv3]、ベンダー提供の技術文書[CISCO]、バグ報告[MSOFT]、IGMPスヌーピングスイッチの設計に関与した人々との議論、MAGMAメーリングリストでの議論、および実装アンケートに対するスイッチベンダーからの回答。

Interoperability issues that arise between different versions of IGMP are not the focus of this document. Interested readers are directed to [IGMPv3] for a thorough description of problem areas. 異なるバージョンのIGMP間で発生する相互運用性の問題は、本書の焦点ではありません。問題領域の詳細な説明については、興味のある読者は[IGMPv3]を参照してください。

The suggestions in this document are based on IGMP, which applies only to IPv4. For IPv6, Multicast Listener Discovery [MLD] must be used instead. Because MLD is based on IGMP, we do not repeat the entire description and recommendations for MLD snooping switches. Instead, we point out the few cases where there are differences from IGMP. 本書の提案は、IPv4にのみ適用されるIGMPに基づいています。IPv6の場合、代わりにマルチキャストリスナー検出[MLD]を使用する必要があります。MLDはIGMPに基づいているため、MLDスヌーピングスイッチに関する説明と推奨事項全体を繰り返すことはしません。代わりに、IGMPと異なるいくつかのケースを指摘します。

Note that the IGMP snooping function should apply only to IPv4 multicasts. Other multicast packets, such as IPv6, might be suppressed by IGMP snooping if additional care is not taken in the implementation as mentioned in the recommendations section. IGMPスヌーピング機能はIPv4マルチキャストにのみ適用されるべきであることに注意してください。推奨事項のセクションで言及されているように、実装で追加の注意が払われない場合、IPv6などの他のマルチキャストパケットがIGMPスヌーピングによって抑制される可能性があります。