Re: IGMPv3 merging of pending SLC records
Subrata Sa <[email protected]> Fri, 17 Jul 2009 12:40:31 +0530
| Newsgroups | gmane.ietf.magma |
|---|---|
| Message-ID | <[email protected]> |
On Thu, Jul 16, 2009 at 3:55 PM, Subrata Sa<[email protected]> wrote: > Hello, > > This is regarding IGMPv3 host side behavior on merging of pending > Source-List-Change (SLC) records. > My theoretical i.e. IPMulticastListen() calls (2, 3) given below are misleading - please ignore them. I'm giving actual user API i.e. setsockopt() calls below. > In the example below, two SLC requests of opposite types (block, > unblock) are made *when previous Filter-Mode-Change (FMC) record is in > retransmission state*. I understand that the SLC records should be > scheduled later. Question is how the SLC records should be merged? I'm > thinking that both (BLOCK, ALLOW) SLC records be sent as given in (5) > below. What do you think? Am I missing something? > > 1. Call IPMulticastListen(s, i, G, EXCLUDE, {}) setsockopt(s, .., IP_ADD_MEMBERSHIP, {G, i}), ..) > -> Stack sends TO_EX(G, {}) FMC record (R1) > -> State-change timer (T1) is started for retransmission > > 2. Before T1 expires, call IPMulticastListen(s, i, G, EXCLUDE, {a}) > i.e. block source setsockopt(s, .., IP_BLOCK_SOURCE, {G, a, i}, ..) > -> This SLC record is scheduled later as FMC record retransmission is > pending (see reference A given below) > > 3. Before T1 expires, call IPMulticastListen(s, i, G, INCLUDE, {a}) > i.e. unblock source setsockopt(s, .., IP_UNBLOCK_SOURCE, {G, a, i}, ..) > -> This SLC record is also scheduled later as FMC record > retransmission is pending (see A below) > > 4. Now T1 expires > -> FMC record TO_EX(G, {}) is retransmitted (R2) > -> As SLC records are pending, state-change timer (T2) is scheduled > > 5. Now T2 expires > -> BLOCK(G, {a}), ALLOW(G, {a}) SLC records are sent (R3) > -> State-change timer (T3) is started > > 6. Now T3 expires > -> R3 is retransmitted (R4) > > -- > Reference A) RFC 3376 section 5.1, page 21: > > " > If the interface reception-state change that triggers the new report > is a filter-mode change, then the next [Robustness Variable] State- > Change Reports will include a Filter-Mode-Change record. This > applies even if any number of source-list changes occur in that > period. > " > Indranil, Kawaguchi, thanks for your response. -Subrata Sa