Subject: [magma] A issues for the IGMP snooping draft

From: "Ben Carter" <[email-masked]>
Date: Thu, 09 May 2002 14:07:31 -0700

We supply infrastructure for retail service providers to deliver services to end user customers. This includes over one 

hundred channels of video over multicast IP. This amount of multicast is far more traffic than our edge connections can 

handle. Our network lives and dies on layer 2 multicast containment. Full containment is essential.

It appears to me that there are some scenarios where the *default* behavior specified in the IGMP snooping draft does not 

scale adequately to provide sufficient flood protection for our application. While the draft does allow an option to contain 

multicast traffic when leaves and joins (membership reports) have not been received, many vendors apply only the snooping 

draft's *default* behavior. 

My apologies in advance if I am incorrect and have wasted anyone's time with this very long post. Also, I am having a devil of a time with the formatting on this document. If it is difficult to read, I am happy to email a copy to anyone who so desires.

Please use Diagram 1 for all examples. 

Issue #1:
When a snooping interface receives packets for which no IGMP leave or join has been received, the packet will be flooded 

automatically. This presents a problem when snooping infrastructure is located between multicast routers using a flood and 

prune protocol. If Router A and B are communicating using a flood and prune protocol, and we assume the 600Mbps of multicast 

traffic, the houses (connected at 10Mbps) will most likely lose their ability to communicate with the network every time the 

Mcast routing protocol floods. 

Issue #2:
I see the logic behind the default flood behavior. But it doesn't seem to offer us full protection against version 

mismatches. The recommendation of setting the multicast router to version 2 is not always an option for us because we are a carrier 

supplying layer 2 VLANs to connect service providers with their customers. We do not have control over what equipment will be 

deployed at end points of our network VLANs.
 
If switch B is IGMP version 2 snooping capable and receives an IGMP version 2 join for channel 1 from house A, then receives 

a version 3 join for channel 1 from house B, house B will not receive the requested channel.  

Issue #3
The default implementation does not work for multicast hosts directly connected to the layer 2 snooping domain. If a customer 

were to connect a multicast source to our network the *default* flooding behavior causes some strange things to occur.

Issue #4:
Also, with the default flood behavior we see problems when abnormal network events occur. With our application, receiving 

unsolicited traffic causes major problems because core multicast traffic exceeds the bandwidth capacity of our edge devices. 
(please see diagram 1):
For this example each "channel" refers to a ~4Mbps MPEG2 video stream. Assume house connections are 10Mbps and all others are 

100Mbps.

1) Houses A,B and C are watching channels 2,3 and 4 respectively. 
2) Switch B resets due to momentary power failure and boots up with no IGMP snooping state.
3) When switch B comes back up it will still be receiving channels 2,3 and 4 from Switch A, but will have no IGMP 

membership information. 
4) Switch B will flood all 3 channels to houses A,B and C. 
5) Channels 2,3 and 4 are ~4Mbps MPEG2 streams, and the houses connect to the network at 10Mbps. These 3 channels 

represent more traffic than the house links can handle. This will send more data to these 3 houses than their network 

connection can handle, possibly eliminating the hosts ability to receive or reply to the IGMP general query issued by Switch 

A when it senses the 'link up' topology change, breaking their network connection until Router A times out the streams or 

Switch A receives a leave for channels 2,3 and 4 from some other port.

This behavior can probably be fixed if it is specified that the switch MUST refrain from flooding until it receives replies 

to the general query issued after the 'link up' topology change was detected by switch A. The default contain and query 

method outlined below seems to solve this also. 

In an effort to address these issues I would like to propose one possible solution. Rather than flooding by default, using a 

'contain and query' method seems to solve some of these issues. To achieve this I would Change Section 8 from:

8) If a switch receives a *non* IGMP multicast packet without having
first processed Membership Reports for the group address, it MUST for-
ward the packet on all ports.  In other words, the switch must allow for the possibility that connected hosts and routers 

have been upgraded to support future versions or extensions of IGMP that the switch does not yet recognize. A switch MAY have 

a configuration option that suppresses this operation, but default behavior MUST be to allow flooding of unregistered 

packets.

to read:

8) If a switch receives a *non* IGMP multicast stream without having
first processed Membership Reports for the group address, it MUST NOT forward the packet on any port not attached to a 

multicast router, but MUST issue an IGMP general query on all ports except the port receiving the stream. In other words, the 

switch must allow for the possibility that connected hosts and routers have been upgraded to support future versions or 

extensions of IGMP that the switch does not yet recognize, and must ensure that any router or host will recognize that there 

is an older version of IGMP in use. 

This appears to solve these issues:
1. Prune and flood behavior does not clog the links of edge hosts that cannot handle all multicast channels present in 

the core. 
2. When switch B resets, the streams are blocked by default until the hosts re-issue group membership reports in reply 

to Switch B's general query. 
3. House B will receive a version 2 query from the switch and will begin using IGMP V2 to communicate. Even if a version 

3 router is connected to the segment, the responses from house B will become version 2 (due to backwards compatibility 

design) and the router will begin using version 2 on the interfaces attached to our IGMP snooping segments, but still be able 

to use version 3 on other segments.
4. Servers can be attached directly to layer 2 snooping infrastructure.

Of course the law of unforeseen consequences says that there are new issues with this method that I am not seeing *

Diagram 1.

                                                +-----------------+
                                                |     Router A     |
                                                +--------+--------+
                                                         |
                       +---------+              +-------------------+           +-------------+
                       |  Host S1|--------------|     Switch A      |-----------|  Router B   |
                       +---------+              +-------------------+           +-------------+
                                                  |    |     |    |
                      +---------------------------+    |     |    +-----------------------------+
                      |                           +----+     +----+                             |
                   |                              |               |                             |
          +----------+                    +----------+       +----------+                     +----------+
          | Switch B |                    |Switch C  |       |Switch D  |                     |Switch E  |
          +----------+                    +----------+       +----------+                     +----------+
          |    |     |                    |    |     |       |    |     |                     |    |     |
Houses    A    B     C                    D    E     F       G    H     I                     J    K     L 

Ben Carter
Network Analyst
Douglas County PUD
1151 Valley Mall Parkway
E. Wenatchee WA
98802
Voice: (509) 881-2486
Fax: (509) 884-0553

---

From: Bill Fenner <[email-masked]>
Date: Mon, 13 May 2002 17:11:30 -0700

Ben,

  The default in the draft was selected to favor forwards compatability.
It does leave an out, as you quote:

>first processed Membership Reports for the group address, it MUST forward
>the packet on all ports.  ...
>... A switch MAY have a configuration option that suppresses
>this operation, but default behavior
>MUST be to allow flooding of unregistered  

This configuration option is there to ensure that in configurations
like yours, traffic is limited to ports that explicitly requested it.

Your suggestion of having the switch send explicit Queries seems like
it opens up a huge can of worms; instead of that I'd suggest making
the switch an IGMP Proxy router, so that it can be Querier on each port
and make the upstream point to the router.

  Bill

_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma

---

From: "Ben Carter" <[email-masked]>
Date: Fri, 31 May 2002 09:13:15 -0700

Bill,
Thanks for the reply.

The query idea does seem to be an overly complex method. I am convinced, however, that the default flood behavior has major issues.

While I can see what the draft was trying to achieve with the default flood behavior, I don't think these goals have been achieved. It doesn't provide adequate flood protection and isn't very future proof. (IMHO)

My example #2 shows how a host running a 'new' IGMP version will be ignored if it is connected to the same snoopy switch as a 'current' version host subscribing to the same group. Also, there is no protection from unsolicited multicast (from a multicast router running an older flood and prune protocol for example). 

To me it seems unwise to give up backward compatibility in an effort to guess what requirements will achieve forward compatibility.

Thanks
Ben

Ben Carter
Network Analyst
Douglas County PUD
1151 Valley Mall Parkway
E. Wenatchee WA
98802
Voice: (509) 881-2486
Fax: (509) 884-0553

>>> Bill Fenner <[email-masked]> 05/13/02 05:11PM >>>

Ben,

  Bill