Subject: [magma] IGMPv3 merging of pending SLC records

From: Subrata Sa <[email-masked]>
Date: Thu, 16 Jul 2009 15:55:34 +0530

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

---

From: Indranil Bhattacharya <[email-masked]>
Date: Thu, 16 Jul 2009 21:43:50 +0530

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-masked]> wrote:

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

---

From: "K.Kawaguchi" <[email-masked]>
Date: Fri, 17 Jul 2009 10:42:21 +0900

Hi,

I am RFC 3376. 5.1 / RFC3810 6.1 is applied as follows.
(RFC3810 compared with RFC3376, description is added.)

   - 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

   - 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

---

From: "K.Kawaguchi" <[email-masked]>
Date: Fri, 17 Jul 2009 10:56:41 +0900

Hi,

Oops. I correct a clear description mistake.

>      Source a   : Block   : [RV]-1 time

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

Best Regards
--
Kiyoaki Kawaguchi

---

From: Subrata Sa <[email-masked]>
Date: Fri, 17 Jul 2009 12:40:31 +0530

> Source-List-Change (SLC) records.
My theoretical i.e. IPMulticastListen() calls (2, 3) given below are
misleading - please ignore them. I'm giving actual user API i.e.
setsockopt() calls below.

> 1. Call IPMulticastListen(s, i, G, EXCLUDE, {})
setsockopt(s, .., IP_ADD_MEMBERSHIP, {G, i}), ..)

> 2. Before T1 expires, call IPMulticastListen(s, i, G, EXCLUDE, {a})
setsockopt(s, .., IP_BLOCK_SOURCE, {G, a, i}, ..)

> 3. Before T1 expires, call IPMulticastListen(s, i, G, INCLUDE, {a})
setsockopt(s, .., IP_UNBLOCK_SOURCE, {G, a, i}, ..)

> -> R3 is retransmitted (R4)
Indranil, Kawaguchi, thanks for your response.

-Subrata Sa

---

From: Indranil Bhattacharya <[email-masked]>
Date: Fri, 17 Jul 2009 15:22:41 +0530

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

---

From: Subrata Sa <[email-masked]>
Date: Mon, 20 Jul 2009 16:22:02 +0530

On Sat, Jul 18, 2009 at 5:58 PM, Subrata Sa<[email-masked]> wrote:
> On Fri, Jul 17, 2009 at 12:40 PM, Subrata Sa<[email-masked]> wrote:
Seeing both ALLOW and BLOCK records for the same source in a single
report may be misleading to router. I'm going to delete the source (a)
from opposite source list (e.g. BLOCK) when a unblock (i.e. ALLOW)
request has come from user. But this would result in sending ALLOW(a)
record after TO_EX({}) record. I think this is less misleading than
the previous choice.

>>> retransmission is pending (see A below)
I would delete source a from block list for the the group (G).

>>> -> State-change timer (T3) is started
ALLOW(G, {a}) SLC record would be sent (R3)

>>> -> R3 is retransmitted (R4)
-Subrata

---

From: "K.Kawaguchi" <[email-masked]>
Date: Tue, 21 Jul 2009 10:33:19 +0900

Hi Indranil,

> 1)  In Step 3: You have mentioned:

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).)

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

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)

>   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