Re: IGMPv3 merging of pending SLC records

Hello Kawaguchi,

                         This is to clarify two of my doubts:

1)  In Step 3: You have mentioned:

OLD State       New State
========      ========
EXCLUDE(A)   INCLUDE(A)  ------> TO_IN(A) and ALLOW(A)
but the pending record from Step 2 is a BLOCK(A). What happens to BLOCK(A)?
Do we send it as part of the merged report? Also, why do we send ALLOW(A) in
this case?

I have seen the highlighted line from the excerpt you sent. Is it correct to
interpret it like:

EXCLUDE(A)   INCLUDE(A) --------> INCLUDE(NULL)   INCLUDE(A) ------>
ALLOW(A)
                                                      ( Send
TO_IN(A))                            (Send ALLOW(A))


2. It is not against the rule to have both Filter-mode-change record type
and Source-list-change record type for the same group in a group report.

  Is the above statement correct?

Thanks,
Indranil


On Fri, Jul 17, 2009 at 7:12 AM, K.Kawaguchi <[email protected]> wrote:

> 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
>
> ---
> 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 <[email protected]>" 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 <[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
> >
> >
> >
> >
> >
>
>

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