Multicast networking II - IGMP

 Please be advised that this article is work-in-progress. The information here may be vague, incomplete, misleading or plainly wrong.  IGMP -> definition -> Internet Group Management Protocol -> layer 3 protocol -> uses IPv4 as transport protocol and works only with IPv4 -> uses IP protocol number 2 -> used to manage the multicast group membership between clients and routers -> the multicast interested clients send IGMP messages to signal the routers that they want to receive multicast traffic -> a multicast router on the network segment listens for all IGMP messages and once it receives a relevant IGMP message on an interface, the interface is added to the Outgoing Interface List for this group -> once a receiver knows which multicast group to receive, it must inform a local, multicast enabled router -> receiver acquires the information from the application layer -> the router is called the last hop router LHR -> reachable at layer 2 -> this is the step that separates multicast from broadcast -> makes joining the group explicit vs implicit -> operates between the clients of a network and the local routers (immediately-neighboring multicast routers). -> notes -> throughout this document, the following nomenclatures are used -> client / multicast client / multicast receiver / receiver -> all of these are equal and describe a host which wants to receive multicast traffic from the router. -> 'to update the state of a group' -> to check wheter or not there are receivers interested in the multicast traffic sent to the said group. -> 'to join a multicast group' -> to receive multicast traffic sent to the said group -> none of the IGMP mechanics apply to 224.0.0.1 (such as reporting, expiring, etc.). All multicast enabled hosts listen for and process the traffic sent to that address. -> IGMP functions apply only to the interface that received the IGMP message. For example, a PC has 3 NICs connected to three different networks, each interface might be subscribed to different multicast groups, and each interface will send Membership Reports only for the multicast groups it is subscribed to. -> versions -> v1 -> introduced in RFC 1112 -> it is the very first ratified IGMP version -> uses two types of messages-> format: +IGMPv1 message format (64 bits)-+ |						          |										   ||-Layer II framing-||-IPv4 header-||--Type--|-Reserved-|-Checksum-|-Multicast-Address-||--Layer II FCS--|| |-8 bits-|--8 bits--|-16 bits--|--32 bits--|

-> MEMBERSHIP QUERY -> message used by the routers to update the statuses of the multicast groups -> details -> IP header -> source address: IP address of router's interface -> destination address: 224.0.0.1 (All-hosts Link-local multicast address) -> TTL: set to 1. The message is meant for the local network only. -> IGMP message -> TYPE -> 0x11 (17) -> 'Membership Query' -> RESERVED -> 0 bits -> not in use in IGMPv1 -> in IGMPv2 this field is used (max-response-time field). -> since IGMPv1 doesn't use it, this field differentiate between protocol versions 1 and 2. -> CHECKSUM -> it is a checksum of the IGMP payload (not the whole packet). -> when this value is calculated, the CHECKSUM field is all 0 bits. -> after the value was calculated, it is inserted into the CHECKSUM field. -> MULTICAST ADDRESS -> 0.0.0.0 (any group) -> indicates a General Query (the only type of query in IGMPv1) -> IGMPv1 has no mechanism for group-specific queries. -> necessity -> multicast routers use this message to find out if there still are interested members in multicast so the router would know to keep forwarding traffic or stop -> MEMBERSHIP REPORT -> message used by a multicast receiver to signal its interest in a multicast group, to multicast routers -> message informally called 'IGMP JOIN' -> details -> IP header -> source address: address of the host requesting multicast traffic -> destination address: the multicast address of the group that the receiver wishes to join -> IP options: Router Alert is set. This option forces the router to process the message. -> TTL: set to 1. The message is meant for the local network only. -> IGMP message -> TYPE -> 0x12 (18) -> 'IGMPv1 Membership Report' -> RESERVED -> same as for Membership Query -> CHECKSUM -> same process as for Membership Query -> MULTICAST ADDRESS -> the multicast address of the group that the client wishes to join -> same as destination IP address in the IP header -> exactly one group address per message -> necessity -> the message is used to either inform a multicast router that -> there is a client that needs traffic for a particular group (join situation). Particularly needed in scenarios where the said client is the first for that multicast group in the network. -> respond to a router's Membership Query so it will keep sending multicast traffic for that group. -> mechanics -> I. Routers refresh their information about the multicast groups -> multicast routers need to refresh their group information periodically, so they will send Membership Queries (no more than once a minute) -> the Membership Queries which are received by all multicast-enabled hosts. -> when hosts receive these Queries -> for each group they have joined, they start a random timer (called 'report delay timer') with a maximum value of 10 seconds (it should have a different value for each group). -> when the timer for a group expires they will respond to the router's Query with a Membership Report for that group -> however, if the host receives a Membership Report for a group before its timer for that same group expired, it will cancel the timer and won't send its own Membership Report anymore. -> this mechanism exists because a multicast router doesn't keep a list of all members of a group. All it needs to know is that at least one receiver for a group exists. If one receiver out of many sends a Membership Report for a group, all the other Membership Reports for the same group are not needed. -> routers examine the received Membership Reports and if none are received for a particular group after some number of Queries (usually 3), they assume that the group has no members and will stop forwarding multicast traffic for that group. -> the routers listen to all multicast traffic (class D) and since the 'Membership Reports' have the 'Router Alert' flag set, all multicast routers will process these messages. -> II.A client wants to join a group and sends 'Membership Reports' -> a separate one for each multicast group that it wants to join. -> in this scenario, these messages are UNSOLICITED, which means, that they are not sent in response to another message -> this is to reduce join latency -> otherwise, the first receiver of a particular group would have to wait until the router sends a 'Multicast Query' to send a 'Membership Report' -> the multicast routers listen to all multicast IP traffic so they receive the reports. Also the reports have Router Alert flag set so the routers are forced to process the message. -> the multicast routers learn that there are interested receivers for that particular multicast group in the network and -> if no other client asked for traffic for that particular group before -> the multicast router creates a new forwarding state (*,G) for the group -> the multicast router adds the receiving (of the 'Membership Report') interface to the OIL -> the OIL is added to the multicast routing protocol. -> if the group already existed, the multicast router refreshes its information about the state of the multicast group. -> if there are any other receivers in the network for that particular group -> they also receive the 'Membership Report' from the new client because they are actively listening for traffic sent to the particular group -> if a router issued a 'Membership Query', it is enough for one receiver to respond with a 'Membership Report' for that group -> if a receiver responds, all the other receivers will cancel their responses for that group as they are unneeded (same mechanism explained at point I) -> III. A client leaves a particular multicast group -> IGMPv1 is based on silent leaves, which means that there is no 'leave' mechanism. The client will just discard the traffic if it no longer needs it. -> if a group no longer has clients, the router(s) will detect that using Membership Queries (process described at point I)		      -> shortcomings -> 1 -> if there are muliple IGMPv1 configured routers in a network, all of them will send IGMP queries but only one will actually forward multicast traffic -> the clients will reply to all queries received. -> some vendors solved this shortcoming by placing the querying responsibility on the Designated Router chosen by the multicast routing protocol, while the other IGMP configured routers will stay silent. However, note that this is NOT a standardized functionality. -> 2 -> if a client that receives multicast disconnects from the network, it has no way to signal this to the router. -> As a result, the router will keep forwarding multicast in the LAN although there are no listeners, until the router detects that a group has no members using 'Membership Queries' -> v2 -> introduced in RFC 2236 -> improves the process by -> faster detection of inactive multicast groups using the 'Leave Group' and 'Specific Membership Query' messages. -> specifies a Querier Router election process -> there is only one router who will query the clients. -> All the other IGMP configured routers will just listen. -> uses four types of messages -> format: +--IGMPv2 message format (64 bits)+ |						               |										   ||-Layer II framing-||-IPv4 header-||--Type--|-Max-Resp-Time-|-Checksum-|-Multicast-Address-||--Layer II FCS--|| |-8 bits-|-8 bits|-16 bits--|--32 bits--|

-> GENERAL MEMBERSHIP QUERY -> messages used by multicast routers to periodically update the status of all multicast groups. -> the message is received by all multicast receivers in the local network. -> at least one host per group must respond for the group to remain active. -> details -> IP header -> source address: IP address of the querier router's interface -> destination address: 224.0.0.1 (All-Systems Multicast Address) -> IP options: Router Alert is set. -> IGMP message -> TYPE -> 0x11 (17) -> 'Membership Query' -> MAX RESPONSE TIME -> the maximum interval of time that the router waits for a response from the clients (membership report) -> replaces the RESERVED field from IGMPv1 -> usually 2.5 seconds and the value in the field represents tenths of seconds -> the presence of this field instead of 0x00 (RESERVED) indicates that the protocol version is v2. -> MULTICAST ADDRESS -> 0.0.0.0 (any group) -> indicates that this is a General Query -> necessity -> it has the same purpose and function as the 'Membership Query' used in IGMPv1. -> they also act as a backup to the 'Leave Group' mechanism (situations such as the last receiver for a group dies before it can send a 'Leave Group') -> MEMBERSHIP REPORT -> details -> IP header -> source address: IP address of the client -> destination address: the address of the group that the client wishes to join -> IGMP message -> TYPE -> 0x16 (22) -> 'IGMPv2 Membership Report'/'Join' -> since IGMPv2 is meant to be backwards compatible with IGMPv1, TYPE=0x12 might be used in a IGMPv2 configuration (probably when the host is configured with IGMPv2, router configured with IGMPv1). -> MAX RESPONSE TIME -> this field is used in all IGMPv2 messages to keep the format of the messages consistant -> outside of 'QUERIES' messages, it is set to all bits 0 and serves no purpose -> MULTICAST ADDRESS -> the multicast address of the group that the client wishes to join -> same as destination IP address in the IP header -> exactly one group address per message -> LEAVE GROUP -> message used by receivers to inform the multicast routers when they are no longer interested in a group -> details -> IP header -> source address: IP address of the client -> destination address: 224.0.0.2 (All-Routers Multicast Link-Local group address) -> IP options: Router Alert is set. Therefore the message will be processed by the routers. -> IGMP message -> TYPE -> 0x17 (23) -> 'Leave Group' -> MAX RESPONSE TIME -> set to all bits 0 and has no purpose -> MULTICAST ADDRESS -> the address of the multicast group that the client wants to leave (no longer wants to receive multicast traffic sent to that group multicast address) -> SPECIFIC MEMBERSHIP QUERY -> message used by multicast routers to confirm that there still are multicast receivers interested in a particular group (the word 'specific' refers to a particular multicast group, NOT client) -> the message is received by all receivers listening for the specific multicast group. -> at least one receiver must respond to it with a 'Membership Report' for the group to remain active. -> details -> IP header -> source address: IP address of the querier router's interface -> destination address: the multicast address of the group whose membership is checked -> IP options: Router Alert is set. -> IGMP message -> TYPE -> 0x11 -> 'Membership Query' -> MAX RESPONSE TIME -> 1 second -> multicast clients have to respond to this message with a 'Membership Report' within this timeframe -> it is usually much shorter than the max-response-time used by General Membership Queries -> MULTICAST ADDRESS -> the multicast address of the group whose membership is checked -> same as destination IP address in the IP header -> since a specific multicast address is used in this field (rather than 0.0.0.0 which is used for General Query), this field also differentiates a Specific Query from a General Query -> necessity -> this type of 'Query' is event-driven. It is sent to update the status of a particular group after a receiver sent a 'Leave Group' for that group. -> this happens because the router needs to know if there are any receivers interested in that group or not. -> this way, the router can detect much faster (than when using General Membership Queries) if it should keep forwarding multicast traffic for that group or not (max-resp-time is much smaller than that used for a General Query) -> mechanics -> I. Routers refresh their information about the multicast groups -> for each IGMP group, the multicast routers have a timer -> must be refreshed periodically to keep the state of the group active (to keep forwarding multicast traffic for that group) -> if it expires, the router will no longer forward multicast traffic for that group -> the timers are refreshed when 'Membership Reports' are received from multicast clients. -> in order to refresh these timers, the Querier Router sends General Membership Queries which are received by all multicast-enabled hosts. -> when hosts receive these Queries -> for each group they have joined, they start a random timer with a value lower than the Max-Resp-Time value from the General Query. -> when the timer for a group expires they will respond to the router's Query with a Membership Report for that group -> however, if the host receives a Membership Report for a group before its timer for that same group expired, it will cancel the timer and won't send its own Membership Report anymore. -> this mechanism exists because a multicast router doesn't keep a list of all members of a group. All it needs to know is that at least one receiver for a group exists. If one receiver out of many sends a Membership Report for a group, all the other Membership Reports for the same group are not needed. -> when routers receive these Queries -> implicit Querier election is performed -> the multicast router with the lowest IP gets the Querier role. -> as long as it keeps sending queries, all the other multicast routers will not. -> they refresh their timers when Membership Reports are received from multicast clients -> the Querier Router is NOT necessarily the router that will actually forward the multicast traffic -> in case that they receive the multicast stream, they must be able to forward it -> so all the multicast routers, Queriers or not, must keep the IGMP groups information updated. -> the routers listen to all multicast traffic (class D) and since the 'Membership Reports' have the 'Router Alert' flag set, all multicast routers will process these messages. -> the client whose Membership Report for a group was received, becomes the 'Last Reporter' client for that group. This happens regardless of the situation which caused a Membership Report to be sent (General Membership Query, Specific Membership Query or a join process). -> II A client wants to join a group and sends 'Membership Reports' -> a separate one for each multicast group that it wants to join. -> in this scenario, these messages are UNSOLICITED, which means, that they are not sent in response to another message -> this is to reduce join latency -> otherwise, the first receiver of a particular group would have to wait until the router sends a 'Multicast Query' to send a 'Membership Report' -> the multicast routers listen to all multicast IP traffic so they receive the reports. Also the reports have Router Alert flag set so the routers are forced to process the message. -> the multicast routers learn that there are interested receivers for that particular multicast group in the network and -> if no other client asked for traffic for that particular group before -> the multicast router creates a new forwarding state (*,G) for the group -> the multicast router adds the receiving (of the 'Membership Report') interface to the OIL -> the OIL is added to the multicast routing protocol. -> if the group already existed, the multicast router refreshes its timer on the state of the multicast group. -> if there are any other receivers in the network for that particular group -> they also receive the 'Membership Report' from the new client because they are actively listening for traffic sent to the particular group -> if a router issued a 'Membership Query', it is enough for one receiver to respond with a 'Membership Report' for that group -> if a receiver responds, all the other receivers will cancel their responses for that group as they are unneeded. -> III. A client wants to leave a particular multicast group and sends a Leave Group message -> the Leave Group message is also UNSOLICITED. -> all multicast routers will receive this message (destination IP All-Routers and Router Alert is set) -> if the client that sent the 'Leave Group' is the 'Last Reporter' client, the Querier Router replies with a 'Specific Membership Query' -> message to check wheter there are or not any other multicast receivers for that group. -> if any other client (per group) than the Last Reporter sends a leave group message, the routers do nothing, because they knows that at least the 'Last Reporter' is still interested in receiving traffic -> if the Last Reporter sends a Leave Group, the routers need to know if there is any other host that wants traffic for that group, so a Specific Membership Query is used. -> if there are any other clients who still want multicast for that group -> they must send their 'Membership Reports' for that group within the Max-Resp-Time interval (the cancel membership-report-timer mechanism also applies here) -> the multicast client whose Membership Report is received by the Querier is the new 'Last Reporter' for that group -> if there are not, the router will stop forwarding traffic for that group. -> all the other multicast routers that receive a Specific Membership Query will perform no action at all (maybe update their state on the Last Reporter??). -> v3 -> the latest implementation of the protocol -> introduced in RFC 3376 and updated (along with MLDv2 in RFC 4604) -> updates from IGMPv2 -> allows for signaling (multicast) source information along with the group -> clients can signal from which specific source(s) they want (or they don't want) to receive a multicast traffic stream -> this means that the receiver is basically signaling an (S,G) forwarding state -> this allows the multicast router to signal a shortest based tree in the multicast core, which in turn allows PIM to build shortest path trees. -> this enhancement of the IGMP protocol allows for the use of Source-Specific Multicast (SSM) -> 'Leave Group' messages are no longer in use -> the receivers can now send a single 'Membership Report' message for all groups they subscribed. -> 224.0.0.22 address is now used as destination address for 'Membership Reports'. -> IGMPv3 is also backwards compatible with IGMPv1 and v2 -> the IGMP information needed for the protocol to function can be encapsulated either in IGMPv1/v2 or IGMPv3 packets. Thus, IGMP v1/2 messages are processed by IGMPv3 routers. -> IGMPv3 also provides mechanisms to replicate IGMPv1/2 functions natively. -> messages -> MEMBERSHIP REPORT -> used by receivers to join groups, leave groups, update the state of the groups they are part of to the routers, and refresh the router's information about the groups by responding to its Queries. -> format: +---IGMPv3 Membership Report format-+ |														     |										   ||-Layer II framing-||-IPv4 header-||--Type--|-Reserved-|-Checksum-|-Reserved-|-Number-of-Group-Records-(M)-|-Group-Record-(1)-|-Group-Record-(M)-||--Layer II FCS--|| |-8 bits-|--8 bits--|-16 bits--|--| |																											 V																	+---Group Record format-+

|-Record-Type-|-Aux-Data-Len-|-Number-of-Sources-(N)-|-Multicast-Address-|-Source-Address-(1)-|-Source-Address-(N)-|-Auxiliary-Data-| -> details -> IP header -> source address: IP address of the multicast receiver sending the report -> destination address -> 224.0.0.22 -> since multiple groups can be included in a report, there was need for one single destination multicast address -> eliminates the 'one Membership Report per multicast group' mechanic from IGMPv1 and v2 -> the multicast routers are actively listening to this address. -> IP options: Router Alert is set -> IGMP message -> TYPE -> 0x22 -> 'IGMPv3 Membership Report' -> RESERVED -> both fields are set to all bits 0 and ignored -> CHECKSUM -> hash value of the whole IGMP packet -> calculated with CHECKSUM field set to all bits 0 -> the CHECKSUM field is then populated with all bits 0 -> NUMBER OF GROUP RECORDS -> number that specifies how many Group Record fields the current Membership Report carries -> GROUP RECORD -> block of fields -> contains information about the clients membership for a single multicast group -> one Group Record exists for each multicast group the client is subscribed to												  -> fields -> RECORD TYPE -> provides greater flexibility to IGMPv3 including the ability to signal Source-Specific Multicast and Any-Source Multicast -> allows the Membership Report to carry the 'Leave Group' message -> uses the concept of 'FILTER modes' for the multicast address specified in the MULTICAST-ADDRESS field: -> INCLUDE filter-mode -> the client requests that the multicast traffic comes only from the sources listed -> EXCLUDE filter-mode -> the client requests that the multicast traffic comes from any source EXCEPT those listed -> Record Types -> these record types are needed because a router needs to differentiate between Current-State Records and Change-State Records -> Current-State Record (steady state signaling) -> used in the Membership Reports sent as response to received Membership Queries -> allow the receivers to refresh their states to the routers by reporting the filter mode and set of SOURCE-ADDRESSES for a particular MULTICAST-ADDRESS -> MODE_IS_INCLUDE -> filter mode is set to INCLUDE -> used in Source-Specific Multicast -> MODE_IS_EXCLUDE -> filter is set to EXCLUDE -> Filter-Mode-Change Record (when the filter of a group changes) -> are used in Group Records which are sent by the client due to a change in filter in regards to a MULTICAST-ADDRESS -> not only the client changes its interface's filter in regards to a group, but the router will also perform computations which will result in a group state filter-mode change (see operations point I, 'Router Internals') -> CHANGE_TO_INCLUDE_MODE -> the receiver's interface filter changed to INCLUDE mode. The set of SOURCE-ADDRESS(es) is the new list -> CHANGE_TO_EXCLUDE_MODE -> the receiver's interface filter changed to EXCLUDE mode. The set of SOURCE-ADDRESS(es) is the new list -> Source-List-Change Record (when the sources for a group change) -> used when the SOURCE-ADDRESS(es) for a MULTICAST-ADDRESS change, without a change in the FILTER MODE -> the set of sources reported in these messages do NOT overwrite the already existing lists. -> if changes in the source list result in both allowing and blocking sources, separate Membership Records with both types of records will be sent. -> ALLOW_NEW_SOURCES -> used to indicate that the client wants to receive traffic to a multicast address from these sources. -> the list of sources does NOT overwrite the already existing one. -> if the interface is in INCLUDE mode: the client wants to receive traffic from the old sources and these new ones. -> if the interface is in EXCLUDE mode: the client wants to delete these sources from the EXCLUDE list, so it can receive traffic from them. -> BLOCK_OLD_SOURCES -> used to indicate that the client no longer wants to receive traffic to a multicast address from these sources. -> if the interface is in INCLUDE mode: the client wants to delete these sources from the list, so it will receive traffic from them. -> if the interface is in EXCLUDE modeL the client wants to add these addresses to the list, so it won't receive traffic from them. -> AUX-DATA-LEN -> value representing the length of the AUXILIARY-DATA field. -> it is set to all bits 0 because IGMPv3 does not define any usage for AUXILIARY-DATA field -> NUMBER-OF-SOURCES-(M) -> indicates how many SOURCE-ADDRESSes are present in the Group Record -> MULTICAST-ADDRESS -> multicast IP address of the group that the Record refers to													    -> SOURCE-ADDRESS -> IP source addresses that the record refers to															       -> as many of these fields as needed -> NUMBER-OF-SOURCES value refers to the number of these fields -> since multiple source addresses are possible in a single Group Record, a receiver is able to signal multiple (S,G) states for a single group -> AUXILIARY-DATA -> it is meant to hold additional info about the group record but has no usage in IGMPv3 -> it is usually missing, and if it not, it must be ignored -> reserved for use in future IGMP versions -> MEMBERSHIP QUERY -> messages used by the Querier Router to update the IGMP states -> format: +---IGMPv3 Membership Query format--+ |														                                     |										   ||-Layer II framing-||-IPv4 header-||--Type--|-Max-Resp-Code-|-Checksum-|-Group-Address-|-Resv-|-S-|-QRV-|-QQIC-|-Number-Of-Sources-(N)-|-Source-Address-(1)-|-Source-Address-(N)-||--Layer II FCS--|| -> details -> IP header -> source IP: Querier Router interface's IP address -> destination IP -> General Query: 224.0.0.1 (All-Systems Multicast Address, the same used in IGMPv1/v2) -> Group-Specific and Group-and-Source-Specific queries: multicast IP of the group being queried -> IP options: Router Alert flag is set -> IGMP message -> TYPE -> 0x11 -> 'Membership Query' -> MAX-RESP-CODE -> indicates the maximum time interval for a client to responds with a Membership Report -> CHECKSUM -> hash value of the whole IGMP packet -> calculated with CHECKSUM field set to all bits 0 -> the CHECKSUM field is then populated with all bits 0 -> GROUP ADDRESS -> General Query: set to all bits 0 -> Group-Specific and Group-and-Source-Specific queries: the multicast IP address of the group being queried -> RESV -> reserved -> set to 0 on transmission and ignored on reception -> S -> Suppress Router-Side Processing -> flag that when set, indicates that any router must supress the usual (router) timer updates performed when receiving a Query message. -> does not apply to 'host-side' timers, even in case of routers that are members of multicast groups (act as hosts) -> does not suppress the Querier election process -> QRV -> Querier's Robustness Variable -> number suggests how 'lossy' the network is (expected to be) -> defaults to 2 (packets are expected to be lost) -> some implementations allow for its tuning -> higher values mean IGMP messages are resent more frequently -> the purpose of this field is to fine tune the number of IGMP messages that are sent, so even in a lossy network you can be sure that there are enough IGMP messages sent for the protocol to work -> QQIC -> Querier's Query Interval Code -> specifies the Query interval used by the Querier -> Allows other multicast routers on the segment to tune their query intervals to the designated querier -> S flag would inform a router not to update -> NUMBER-OF-SOURCES -> specifies how many SOURCE-ADDRESS fields are present in the Query -> General Query: the number is 0 -> Group-Specific Query: the number is 0 -> Group-and-Source-Specific Query: non-zero -> SOURCE-ADDRESS -> IP source addresses that the record refers to												   -> as many of these fields as needed -> NUMBER-OF-SOURCES value refers to the number of these fields -> the only limit of the SOURCE-ADDRESS fields, also reflected in NUMBER-OF-SOURCES is the MTU value used in the network. -> types -> GENERAL QUERY -> GROUP-SPECIFIC QUERY -> GROUP-AND-SOURCE-SPECIFIC QUERY -> operation -> I. IGMPv3 router internals -> 1. -> In order to satisfy all network needs concurrently, a multicast router must maintain a complex IGMP state for each group (this is in contrast to the other versions where all a router needed to know if there was at least one receiver active per group) -> The state has the format (multicast address, group timer, filter-mode, (source records)) where each source record has the format (source address, source timer) -> details -> MULTICAST ADDRESS -> the multicast group address -> FILTER-MODE -> GROUP TIMER -> -> SOURCE ADDRESS -> SOURCE TIMER -> 2. Although not mandatory, a router may keep a per-host (multicast receiver) state.

-> REFERENCES -> RFC 1112 https://www.rfc-editor.org/rfc/rfc1112 -> qqqq -> what happens if there are no more subscribed groups. Will the router keeps sneding merbership queries??

-> need to clarify if non querier routers update Last Reporter when specific membership queries are received.