[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [magma] IGMPv3 merging of pending SLC records
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
>
>
>
>
>