In early IGMP networks, devices located between the IGMP client and the IGMP router did not detect IGMP flows. In Figure 3, the top set-top box issues a request to view Channel 4, and the DSLAM forwards the request to the edge router. In response, the edge router begins forwarding the multicast group associated with Channel 4. However, if it does not detect IGMP flows, the intermediate device (in this case, the DSLAM) cannot appropriately forward the multicast traffic. By default, most switches broadcast incoming multicast traffic to all ports. In this case, the broadcast results in the bottom client receiving an unrequested channel.
Figure 3: DSLAM Without IGMP Flow Recognition

In these early networks, broadcasting of unrequested channels was not considered a problem, because multicast usage was low and the intermediate devices were typically LAN switches with lower interface and bandwidth costs. Now that IPTV requires higher bandwidth (often 4 Mbps per channel) and bandwidth costs more, it is crucial to ensure that IPTV channels are forwarded only to those subscribers currently viewing them.
To provide more intelligent control of bandwidth, DSLAMs and other intermediate devices now recognize IGMP flows. These devices examine incoming flows and build outgoing interface (OIF) tables. Figure 4 shows a simple example of an outgoing interface table for the DSLAM. The outgoing interface table enables the DSLAM to appropriately forward each multicast group (or channel) from the correct port.
Figure 4: DSLAM with IGMP Flow Recognition

The intermediate device builds the outgoing interface table in one of two ways—IGMP snooping or IGMP proxy.
![]() |
Caution: Some intermediate devices implement IGMP subsystems that use characteristics of both IGMP snooping and IGMP proxy. Most commonly, these devices might determine whether to forward IGMP packets (IGMP proxy) but do not modify the source IP address (IGMP snooping). We recommend that you avoid these nonstandard implementations. |