Re: [magma] IGMPv3 merging of pending SLC records

[Subrata Sa <kiteflyer77 at gmail.com>]

On Sat, Jul 18, 2009 at 5:58 PM, Subrata Sa<kiteflyer77 at gmail.com> wrote:
> On Fri, Jul 17, 2009 at 12:40 PM, Subrata Sa<kiteflyer77 at gmail.com> wrote:
>> On Thu, Jul 16, 2009 at 3:55 PM, Subrata Sa<kiteflyer77 at gmail.com> 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?
Seeing both ALLOW and BLOCK records for the same source in a single
report may be misleading to router. I'm going to delete the source (a)
from opposite source list (e.g. BLOCK) when a unblock (i.e. ALLOW)
request has come from user. But this would result in sending ALLOW(a)
record after TO_EX({}) record. I think this is less misleading than
the previous choice.

>>>
>>> 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)
I would delete source a from block list for the the group (G).

>>>
>>> 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
ALLOW(G, {a}) SLC record would be sent (R3)

>>>
>>> 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.
>>> "
-Subrata