[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [magma] IGMPv3 merging of pending SLC records
Hi Indranil,
> 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?
A host records the change filter mode for a multicast, and
ALLOW/BLOCK for every source. It is only one at each element.
In this case, the change status of Source A is overwritten by
Allow(A).
(The report record which transmits is TO_IN(A).)
>
> 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))
The sentence which received had broken.
Probably, the meaning of the following will be right.
EX(A) to IN(A) ----> TO_IN(A)
IN(null) to IN(A) ----> 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?
No, one report record must be rebuilt based on each element of
change status. (Multiple records cause redundant processing and
query in a router.)
# Of course, the group of ALLOW(A) + BLOCK(B) is satisfactory.
A report message is rebuilt according to each element which
should transmit, and the following rules.
---
RFC3810 6.1
Each time a per-interface listening state change triggers the
Immediate transmission of a new State Change Report, its contents are
determined as follows. If the report should contain a Filter Mode
Change Record, i.e., the Filter Mode Retransmission Counter for that
multicast address has a value higher than zero, then, if the current
filter mode of the interface is INCLUDE, a TO_IN record is included
in the report; otherwise a TO_EX record is included. If instead the
report should contain Source List Change Records, i.e., the Filter
Mode Retransmission Counter for that multicast address is zero, an
ALLOW and a BLOCK record is included. The contents of these records
are built according to the table below.
Record Sources included
------ ----------------
TO_IN All in the current per-interface state that must be
forwarded
TO_EX All in the current per-interface state that must be
blocked
ALLOW All with retransmission state (i.e., all sources from the
Retransmission List) that must be forwarded
BLOCK All with retransmission state that must be blocked
---
Best Regards
--
Kiyoaki Kawaguchi
"Indranil Bhattacharya <myselfindranil at gmail.com>" wrote:
>
> 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 <kawaguti at ysknet.co.jp> 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 <myselfindranil at gmail.com>" 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 <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
> > > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > magma mailing list
> > > magma at ietf.org
> > > https://www.ietf.org/mailman/listinfo/magma
> > >
> > >
> > >
> > >
> > >
> >
> >
>
>
>
>
>