Re: [magma] IGMPv3 merging of pending SLC records

["K.Kawaguchi" <[e-mail]>]

Hi,

Oops. I correct a clear description mistake.

> Hi,
> 
> I am RFC 3376. 5.1 / RFC3810 6.1 is applied as follows.
> (RFC3810 compared with RFC3376, description is added.)
> 
> 1. Call IPMulticastListen(s, i, G, EXCLUDE, {})
> 
>    - The status of an interface changes from INCLUDE (null) to EXCLUDE (null).
>    - This status change record is TO_EX(null).
>    - Transmission record is:
>        Filter mode: Exclude : [RV] time (udapte)
>    - Since there is no pending record, it is transmitted as it is.
>    - Transmission time and each transmission counter are planned.
>        Timer: T1
>        Filter mode: Exclude : [RV]-1 time
> 
> 2. Before T1 expires, call IPMulticastListen(s, i, G, EXCLUDE, {a})
> 
>    - The status of an interface changes from EXCLUDE(null) to EXCLUDE(a).
>    - This status change record is BLOCK(a).
>    - Transmission record is merged with the contents of the pending record.
>      Filter mode: Exclude : [RV]-1 time
>      Source a   : Block   : [RV] time (update)
>    - The compounded record is transmitted immediately. TO_EX(a).
>    - Transmission time and each transmission counter are planned.
>      Timer: T2
>      Filter mode: Exclude : [RV]-2 time (It is deleted if it is RV=2.)
>      Source a   : Block   : [RV]-1 time
> 
> 3. Before (T1->)T2 expires, call IPMulticastListen(s, i, G, INCLUDE, {a})
> 
>    - The status of an interface changes from EXCLUDE(a) to INCLUDE(a).
>    - This status change record is TO_IN(a).
>    - Transmission record is merged with the contents of the pending record.
>      Filter mode: INCLUDE : [RV] time (update)
>      Source a   : Allow   : [RV] time (update)
>    - The compounded record is transmitted immediately. TO_IN(a).
>    - Transmission time and each transmission counter are planned.
>      Timer: T3
>      Filter mode: Exclude : [RV]-1 time
>      Source a   : Block   : [RV]-1 time

     Timer: T3
     Filter mode: Include : [RV]-1 time
     Source a   : Allow   : [RV]-1 time


Best Regards
--
Kiyoaki Kawaguchi



> ---
> RFC3810 6.1
> 
>    If more changes to the same per-interface state entry occur before
>    all the retransmissions of the State Change Report for the first
>    change have been completed, each such additional change triggers the
>    immediate transmission of a new State Change Report.
> 
>    The contents of the new Report are calculated as follows:
> 
>    o  As for the first Report, the per-interface state for the affected
>       multicast address before and after the latest change is compared.
> 
>    o  The records that express the difference are built according to the
>       table above.  Nevertheless, these records are not transmitted in a
>       separate message, but they are instead merged with the contents of
>       the pending report, to create the new State Change Report.  The
>       rules for calculating this merged report are described below.
> 
>    The transmission of the merged State Change Report terminates
>    retransmissions of the earlier State Change Reports for the same
>    multicast address, and becomes the first of [Robustness Variable]
>    transmissions of the new State Change Reports.  These transmissions
>    are necessary in order to ensure that each instance of state change
>    is transmitted at least [Robustness Variable] times.
> 
>    Each time a source is included in the difference report calculated
>    above, retransmission state for that source needs to be maintained
>    until [Robustness Variable] State Change Reports have been sent by
>    the node.  This is done in order to ensure that a series of
>    successive state changes do not break the protocol robustness.
>    Sources in retransmission state can be kept in a per multicast
>    address Retransmission List, with a Source Retransmission Counter
>    associated to each source in the list.  When a source is included in
>    the list, its counter is set to [Robustness Variable].  Each time a
>    State Change Report is sent the counter is decreased by one unit.
>    When the counter reaches zero, the source is deleted from the
>    Retransmission List for that multicast address.
> 
>    If the per-interface listening change that triggers the new report is
>    a filter mode change, then the next n[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.  The node has to maintain retransmission state for the
>    multicast address until the [Robustness Variable] State Change
>    Reports have been sent. This can be done through a per multicast
>    address Filter Mode Retransmission Counter.  When the filter mode
>    changes, the counter is set to [Robustness Variable].  Each time a
>    State Change Report is sent the counter is decreased by one unit.
>    When the counter reaches zero, i.e., [Robustness Variable] State
>    Change Reports with Filter Mode Change Records have been transmitted
>    after the last filter mode change, and if source list changes have
>    resulted in additional reports being scheduled, then the next State
>    Change Report will include Source List Change Records.
> ---
> 
> 
> Best Regards
> --
> Kiyoaki Kawaguchi
> 
> 
> 
> "Indranil Bhattacharya <[e-mail]>" wrote:
> 
> > 
> > 
> > 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 <[e-mail]> 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/magma
> > >
> > 
> > 
> > 
> > 
> > _______________________________________________
> > magma mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/magma
> > 
> > 
> > 
> > 
> > 
> 
> 
> 
>