Re: IGMP v3 - Generation of Interface State Report

Hi,

If you are still interested, the following examples show my interpretation.
If it is a mistake, someone teach me.

------------------------------------------------------------------------
Case-1 IN(A)->IN(B)

1.Call IPMulticastListen(Socket-1,IF-1,Multicast-1,'INCLUDE',{a,b})
  => IN() -> IN(a,b): ALLOW(a,b): a go 2, b go 2.
     Retrans counter: a=2, b=2
  Send a Report ALLOW(Multicast-1,a,b)
  => Retrans counter: a=1, b=1
2.(Before retrans)
  Call IPMulticastListen(Socket-1,IF-1,Multicast-1,'INCLUDE',{a,c})
  => IN(a,b) -> IN(a,c): ALLOW(c), BLOCK(b): c go 2, b go -2.
     Retrans counter: a=1, b=-2, c=2
  Send a Report ALLOW(Multicast-1,{a,c}) and BLOCK(Multicast-1,{b})
  => Retrans counter: b=-1, c=1
  Send a Report ALLOW(Multicast-1,{c}) and BLOCK(Multicast-1,{b})


------------------------------------------------------------------------
Case-2 EX(A)->EX(B)

1.Call IPMulticastListen(Socket-1,IF-1,Multicast-1,'EXCLUDE',{a,b})
  => IN() -> EX(a,b): TO_EX(a,b): Filter go -2, a go -2, b go -2
     Retrans counter: Filter=-2, a=-2, b=-2
  Send a Report TO_EX(Multicast-1,{a,b})
  => Retrans counter: Filter=-1, a=-1, b=-1
2.(Before retrans)
  Call IPMulticastListen(Socket-1,IF-1,Multicast-1,'EXCLUDE',{a,c})
  => EX(a,b) -> EX(a,c): ALLOW(b), BLOCK(c): b go 2, c go -2
     Retrans counter: Filter=-1, a=-1, b=2, c=-2
  Send a Report TO_EX(Multicast-1,{a,c})
  => Retrans counter: b=1, c=-1
  Send a Report ALLOW(Multicast-1,{b}) and BLOCK(Multicast-1,{c})


------------------------------------------------------------------------
Case-3 IN(A)->EX(B)

1.Call IPMulticastListen(Socket-1,IF-1,Multicast-1,'INCLUDE',{a,b})
  => IN() -> IN(a,b): ALLOW(a,b): a go -2, b go -2
     Retrans counter: a=2, b=2
  Send a Report ALLOW(Multicast-1,{a,b})
  => Retrans counter: a=1, b=1
2.(Before retrans)
  Call IPMulticastListen(Socket-1,IF-1,Multicast-1,'EXCLUDE',{b,c})
  => IN(a,b) -> EX(b,c): TO_EX(b,c): Filter go 2, b go 2, c go 2
     Retrans counter: Filter=-2, a=1, b=-2, c=-2
  Send a Report TO_EX(Multicast-1,{b,c})
  => Retrans counter: Filter=-1, b=-1, c=-1
  Send a Report TO_EX(Multicast-1,{b,c})


------------------------------------------------------------------------
Case-4 EX(A)-IN(B)

1.Call IPMulticastListen(Socket-1,IF-1,Multicast-1,'EXCLUDE',{a,b})
  => IN() -> EX(a,b): TO_EX(a,b): Filter go -2, a go -2, b go -2
     Retrans counter: Filter=-2, a=-2, b=-2
  Send a Report a TO_EX(Multicast-1,{a,b})
  => Retrans counter: Filter=-1, a=-1, b=-1
2.Call IPMulticastListen(Socket-1,IF-1,Multicast-1,'INCLUDE',{b,c})
  => EX(a,b) -> IN(b,c): TO_IN(b,c): Filter go 2, b go 2, c go 2
     Retrans counter: Filter=2, a=-1, b=2, c=2
  Send a Report TO_IN(Multicast-1,{b,c})
  => Retrans counter: Filter=1, b=1, c=1
  Send a Report TO_IN(Multicast-1,{b,c})


Best Regards
--
Kiyoaki Kawaguchi



> Hello All,
>  
> I see discussion of IGMP v3 in this group context. My advance apologies if this is not the right place. RFC 3376 s5.1 describes procedure to g> enerate State Change Reports. 
>  
> ----------------------------
>    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.  The host has to maintain retransmission state for the group
>    until the [Robustness Variable] State-Change reports have been sent.
>    When [Robustness Variable] State-Change reports with Filter-Mode-
>    Change records have been transmitted after the last filter-mode
>    change, and if source-list changes to the interface reception have
>    scheduled additional reports, then the next State-Change report will
>    include Source-List-Change records.
> ------------------------------
>  
> It seems this paragraph has different interpretations. A state machine would've been very helpful. 
>  
> (1) How would one treat the occurrence of source-list changes while Filter-Mode-Change record is in retransmission state? 
>  
>    (a) Send source-list changes (SLC) records as these events occur?
>    (b) If multiple events occur, perform the 'merge' operation and send the reports
>    (c) Keep the retransmission state, but do not retransmit as long as Filter-Mode-Change record state is active. On expiry of FMC state, and SLC records are retransmitted, if 'live'
>  
> (2) How would one treat the occurrence Filter-Mode-Change record of while source-list changes is in retransmission state?
>  
>       It seems we "clear" (/stop) source-list changes recrod retransmission on the occurrence of FMC event.
>  
> Any feedback is appreciated.
>  
> Thanks
> Venkat