Subject: Purpose of Suppress Router-Side Processing Flag

From: Todd Hayton <[email-masked]>
Date: Tue, 8 Jan 2002 16:50:44 -0500 (EST)

Hey there,

I was exmining Cisco's implementation of IGMPv3 and had a question
regarding what benefit the S Flag provides. According to the draft,
the s flag is set in a query if a source's timer is greater than LMQT and
cleared otherwise.

So, my understanding of this is that if a router has a pending guery for a
source and then it receives a report indicating desired reception for that
source, then that source's timer gets raised to GMI, but the pending
query does NOT get cancelled. And so when the pending query gets sent out
it has the s flag set.

My question is why not just cancel the query if a report has been
received? If the S Flag is set and no other routers are going to
update their timers because of this, then what benefit is being provided
by sending out this query?

Here are the traces I've been observing of how Cisco implemented this:

1) Note: OK, we first send an ALLOW

Receiver > 224.0.0.22: igmp v3 report, 1 group record(s)
                            [gaddr 232.1.1.2
                             allow { 10.0.0.1
                                     10.0.0.2
                                     10.0.0.3
                                     10.0.0.4 }]
                         4500 0034 b591 0000 2002 41c4 c0a8 02b4
                         e000 0016 2200 c7ec 0000 0001 0500 0004
                         e801 0102 0a00 0001 0a00 0002 0a00 0003
                         0a00 0004

2) Note: A BLOCK is now sent for source 10.0.0.3 immediately followed by
         an ALLOW for source 10.0.0.3.

Receiver > 224.0.0.22: igmp v3 report, 1 group record(s)
                            [gaddr 232.1.1.2
                             block { 10.0.0.3 }]
                         4500 0028 b594 0000 2002 41cd c0a8 02b4
                         e000 0016 2200 e4f6 0000 0001 0600 0001
                         e801 0102 0a00 0003

Receiver > 224.0.0.22: igmp v3 report, 1 group record(s)
                            [gaddr 232.1.1.2
                             allow { 10.0.0.3 }]
                         4500 0028 b595 0000 2002 41cc c0a8 02b4
                         e000 0016 2200 e5f6 0000 0001 0500 0001
                         e801 0102 0a00 0003

3) Note: Query sent in response to block with S Flag cleared.

Querier > 232.1.1.2: igmp query v3 [gaddr 232.1.1.2 { 10.0.0.3 }]
                         46c0 0028 9c5e 0000 0102 db49 c0a8 02bc
                         e801 0102 9404 0000 110a f9b1 e801 0102
                         023c 0001 0a00 0003 0000 0000 0000
                          ^
                          |
                          S Flag = 0

3) Note: Query sent again, but this time the source timer must be bigger
         than LMQT because the S flag is now SET. In fact, according to
         the debug output the source timer gets raised to GMI before the
         query gets sent out:

  IGMP: Updating expiration time on (10.0.0.3,232.1.1.2) to 180 secs
  IGMP: Building v3 Query source list for 232.1.1.2 on Ethernet0 (0 / 1 srsp)
  IGMP: Send v3 Source Query on Ethernet0 for group 232.1.1.2

Querier > 232.1.1.2: igmp query v3 [gaddr 232.1.1.2 { 10.0.0.3 }]
                         46c0 0028 9c5f 0000 0102 db48 c0a8 02bc
                         e801 0102 9404 0000 110a f1b1 e801 0102
                         0a3c 0001 0a00 0003 0000 0000 0000
                          ^
                          |
                          S Flag = 1

regards,
Todd H

---

From: Isidor Kouvelas <[email-masked]>
Date: Tue, 08 Jan 2002 17:43:46 -0800

In order to maintain the IGMP protocol robustness (i.e. making sure
that ROBUSTNESS reports follow the original query that caused the
timers to be lowered) the querier has to send the remaining queries
after the report is received. To prevent these remaining queries from
lowering the timers again the SRSP flag is set. The SRSP flag should
have been part of queries even in IGMPv2.

thanks
I