Re: IGMPV3 Report scheduling

Hi,

When there is a state change record to be sent, the record type(3,4,5,6)
will be different than what you send in response to a query(1,2). So state
change group record types can be sent robustness number of times. The timers
used for responding to General Query will be different from the one used for
sending state change record or response to a group specific query. So even
if there is a general query received in between robustness times you can set
both the timers and according to the timer expired a proper group record
would be sent. i think your option (b) is similar to this one if not
exactly.

Regards,
Sandeep


Princy Elizabeth wrote:
> 
> Hi,
>    
>   I had a question on the scheduling of reports by an IGMPV3 hosts. The
> RFC requires an IGMP host to retransmit its State Change Records for a
> group "robustness variable" number of times. In case of further state
> change occuring prior to all the retransmissions being complete, the state
> changes are merged and transmitted immediately. This terminates
> retransmission of the first state change record and becomes the first of
> "robustness variable" retransmissions for the combined state change
> record. However, I am not clear on what happens if a general query is
> received before the "robustness variable" retransmissions are complete?
> Which of the following happens:
>    
>   a) The timer for the state change record retransmission for the group is
> cancelled and all pending retransmissions for the state change record are
> also cancelled. Response to the general query is sent instead after a
> random interval between 0 to MRT?
>    
>   OR
>    
>   b) The timer for the state change record retransmission for the group
> cancelled but pending retransmissions for the state change record are not
> cancelled. Number of pending retransmissions for the state change record
> is decremented by 1. Response to the general query is sent after a random
> interval between 0 to MRT? If the number of pending retransmissions is not
> 0, the timer is restarted to resend the state change record after some
> random  between 0 to "unsolicited report interval"
>    
>   I think (a) is the correct approach but I'd be grateful if someone could
> confirm the same.
>    
>   Thanks and regards,
>   Princy
> 
>  __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> _______________________________________________
> magma mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/magma
> 
> 

-- 
View this message in context: http://www.nabble.com/IGMPV3-Report-scheduling-tf2819288.html#a11061643
Sent from the IETF - magma mailing list archive at Nabble.com.