Subject: igmpv3 questions and comments

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 16 May 2001 11:28:54 +0900

Hi.

I have several comments and questions for IGMPv3 spec.

[1]
As a host side, timer controled by IPMulticastListen() invokation 
is independent from interface timer or group timer?
Or, this timer should be overwrapped by Query timer (i.e. interface 
timer or *the same group's* group timer)?

For example, IPMulticastListen() is invoked and the node is about to
send State-Change Report even the report is the first one or resent
one which is controled by Robustness Variable.
After that, the node receives General Query or Group-Specific Query
for the same group.
What should the node do? Cancel State-Change Report? Or each report,
State-Change Report and Current-State Report, should be sent? Or it
depends on each timer?

e.g. Let's see following time chart with Robustness Variable=3.

     1        2     3   4     5  6
     |        |     |   |     |  |
     V        V     V   V     V  V
  ----------------------------------------> time

1. IPMulticastListen() was invoked.
2. First timer for State-Change Report was expired.
   (Then, State-Change Report was sent.)
3. General Query or Group-Specific Query for *the* gorup was
   received.
4. Second timer for State-Change Report was expired.
   (State-Change Report should be sent?)	<--- *
5. Interface timer or *the* group timer was expired.
   (Current-State Report should be sent?)	<--- *
6. Third timer for State-Change Report was expired.
   (State-Change Report should be sent?)	<--- *

There is no description about above three * notations.

I think following may be the correct story;
  When an interface timer for pending responce of General Query or
  Group-Sepcific Query for the same multicast address is sooner than
  the scheduled timer of State-Change Report invoked by
  IPMulticastListen, pending State-Change Report(s) scheduled by
  Robustness Variable is (are) canceled at that time.

If I am correct, above 6's notation won't be occured.

What's correct?

[2]
3.2 in an I-D says;
   For example, if the socket records for multicast address m on
   interface i are:

            from socket s1:  ( i, m, EXCLUDE, {a, b, c, d} )
            from socket s2:  ( i, m, EXCLUDE, {b, c, d, e} )
            from socket s3:  ( i, m, INCLUDE, {d, e, f} )
  
   then the corresponding interface record on interface i is: 

                             ( m, EXCLUDE, {b, c} )

At this situation, when the application using socket s3 wants to stop
itself (i.e., close socket s3), the node must send LEAVE message from
interface i. So, at this situation, the application tries to call (m,
EXCLUDE, {d,e,f}). However, according to an I-D, the interface state
is finally cleared (i.e., (m, EXCLUDE, {}) calculated with (m,
EXCLUDE, {b,c}) and (m, EXCLUDE, {d,e,f}) ), and after that, this
node sends only ALLOW({b,c}) based on the rule of section 5.1 in an
I-D, and the the kernel doesn't send BLOCK({d,e,f}) to mention the
LEAVE.

And another example. When the interface i has (m, EXCLUDE, {b,c})
state like above and some application calls (m, INCLUDE, {a}), the
interface state will not be changed. So, at this time, JOIN message
will also not be transfered?

Am I talking wrong stories?

[3]
Also using above 3.2's sample.
In this case, an include list of the interface SHOULD be cleared?
I mean, after keeping above state, if this node calls (m,
INCLUDE,{b,c,g}), this node has which filter, (m, INCLUDE, {g}) or
(m, INCLUDE, {d,e,f,g})?

There is also no description about this state in an I-D.

[4]
5.2 in an I-D says;
2. If the received Query is a General Query, the interface timer is
   used to schedule a response to the General Query after the selected
   delay.
   Any previously pending response to a General Query is canceled.
So, any previously pending response to a General Query is canceled,
*even if* an interface timer set by previous General Query is sooner
than the selected delay?

[5]
How about local group handling? IPMulitcastListen() can specify LOCAL
group address? I may say "yes" because some application, not a user
application but e.g., a routing daemon, may want to restrict neighbor
nodes. Of course, it would be able to make a filter not to receive
routing message without using IPMulticastListen(), with using upper
layer filtering implementation, though.
(Actually, IGMPv2's implementation on *BSD kernl doesn't set Report
timer for LOCAL group, because it's done by each application
(including a routing daemon). This is because there was no mechanism
to set some filtering policy by *protocol* (i.e. IGMPv1/v2), I think.)
And, local group addresses except ALL-HOSTS and ALL-ROUTERS will be
queried by specific queries (Group- and Group-and-Source-Specific
Query)? 
And these should be reported by any query (General, Group-, and
Group-and-Source-Specific Query)?
Also, local group addresses should be reported within a report message
for General query?

I cannot find these specification in an I-D.

Thanks.
--
Hitoshi Asaeda