Re: IGMPv3 merging of pending SLC records

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 <[email protected]> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/magma
>

_______________________________________________
magma mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/magma