Re: [magma] IGMPv3 merging of pending SLC records

[Indranil Bhattacharya <myselfindranil at gmail.com>]

Hello Subrata,

 

                    In this case, TO_IN(a) will be sent after Step3. However, I see that this will break the protocol robustness.

 

                    After 1 and 2, there is a block(a) record pending. Step 3 is again a filter-mode-change. So, a TO_IN(a) will be sent. After robustness_variable TO_IN(a)s have been sent, considering no filter-mode change occurred in this period, if we send block(a) then forwarding on that LAN is broken.

 

                   I think the following line, "However these records are not transmitted in a message but instead merged with the contents of the pending report, to create
   the new State-Change report." should be interpreted as merging between same record types and typically source list changes. That means

 

INCLUDE(A)  EXCLUDE(B) -------> TO_EX(B)  and SLC(ALLOW(A)) is discarded.

 

EXCLUDE(A) INCLUDE(B) --------> TO_IN(B) and SLC(BLOCK(A)) is discarded.

                 

Thanks,

Indranil

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.

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, {})
-> 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
-> 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
-> 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.
"

Thanks in advance,
Subrata Sa
_______________________________________________
magma mailing list
magma at ietf.org
https://www.ietf.org/mailman/listinfo/magma