Network Working Group W. Fenner
`Request for Comments: 2236 Xerox PARC
`Updates: 1112 November 1997
`Category: Standards Track
`
` Internet Group Management Protocol, Version 2
`
`Status of this Memo
`
` This document specifies an Internet standards track protocol for the
` Internet community, and requests discussion and suggestions for
` improvements. Please refer to the current edition of the "Internet
` Official Protocol Standards" (STD 1) for the standardization state
` and status of this protocol. Distribution of this memo is unlimited.
`
`Copyright Notice
`
` Copyright (C) The Internet Society (1997). All Rights Reserved.
`
`Abstract
`
` This memo documents IGMPv2, used by IP hosts to report their
` multicast group memberships to routers. It updates STD 5, RFC 1112.
`
` IGMPv2 allows group membership termination to be quickly reported to
` the routing protocol, which is important for high-bandwidth multicast
` groups and/or subnets with highly volatile group membership.
`
` This document is a product of the Inter-Domain Multicast Routing
` working group within the Internet Engineering Task Force. Comments
` are solicited and should be addressed to the working group’s mailing
` list at idmr@cs.ucl.ac.uk and/or the author(s).
`
`1. Definitions
`
` The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
` "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
` document are to be interpreted as described in RFC 2119 [RFC 2119].
`
`2. Introduction
`
` The Internet Group Management Protocol (IGMP) is used by IP hosts to
` report their multicast group memberships to any immediately-
` neighboring multicast routers. This memo describes only the use of
` IGMP between hosts and routers to determine group membership.
` Routers that are members of multicast groups are expected to behave
`
`Fenner Standards Track [Page 1]
`
`APPENDIX I
`
`Microsoft et al. Exhibit 1019
`
`

`

`RFC 2236 Internet Group Management Protocol November 1997
`
` as hosts as well as routers, and may even respond to their own
` queries. IGMP may also be used between routers, but such use is not
` specified here.
`
` Like ICMP, IGMP is a integral part of IP. It is required to be
` implemented by all hosts wishing to receive IP multicasts. IGMP
` messages are encapsulated in IP datagrams, with an IP protocol number
` of 2. All IGMP messages described in this document are sent with IP
` TTL 1, and contain the IP Router Alert option [RFC 2113] in their IP
` header. All IGMP messages of concern to hosts have the following
` format:
`
` 0 1 2 3
` 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Type | Max Resp Time | Checksum |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Group Address |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`
`2.1. Type
`
` There are three types of IGMP messages of concern to the host-
` router interaction:
`
` 0x11 = Membership Query
` There are two sub-types of Membership Query messages:
` - General Query, used to learn which groups have members on an
` attached network.
` - Group-Specific Query, used to learn if a particular group
` has any members on an attached network.
`
` These two messages are differentiated by the Group Address, as
` described in section 1.4 . Membership Query messages are
` referred to simply as "Query" messages.
`
` 0x16 = Version 2 Membership Report
`
` 0x17 = Leave Group
`
` There is an additional type of message, for backwards-compatibility
` with IGMPv1:
`
` 0x12 = Version 1 Membership Report
`
`Fenner Standards Track [Page 2]
`
`APPENDIX I
`
`Microsoft et al. Exhibit 1019
`
`

`

`RFC 2236 Internet Group Management Protocol November 1997
`
` This document refers to Membership Reports simply as "Reports". When
` no version is specified, the statement applies equally to both
` versions.
`
` Unrecognized message types should be silently ignored. New message
` types may be used by newer versions of IGMP, by multicast routing
` protocols, or other uses.
`
`2.2. Max Response Time
`
` The Max Response Time field is meaningful only in Membership Query
` messages, and specifies the maximum allowed time before sending a
` responding report in units of 1/10 second. In all other messages, it
` is set to zero by the sender and ignored by receivers.
`
` Varying this setting allows IGMPv2 routers to tune the "leave
` latency" (the time between the moment the last host leaves a group
` and when the routing protocol is notified that there are no more
` members), as discussed in section 7.8. It also allows tuning of the
` burstiness of IGMP traffic on a subnet, as discussed in section 7.3.
`
`2.3. Checksum
`
` The checksum is the 16-bit one’s complement of the one’s complement
` sum of the whole IGMP message (the entire IP payload). For computing
` the checksum, the checksum field is set to zero. When transmitting
` packets, the checksum MUST be computed and inserted into this field.
` When receiving packets, the checksum MUST be verified before
` processing a packet.
`
`2.4. Group Address
`
` In a Membership Query message, the group address field is set to zero
` when sending a General Query, and set to the group address being
` queried when sending a Group-Specific Query.
`
` In a Membership Report or Leave Group message, the group address
` field holds the IP multicast group address of the group being
` reported or left.
`
`2.5. Other fields
`
` Note that IGMP messages may be longer than 8 octets, especially
` future backwards-compatible versions of IGMP. As long as the Type is
` one that is recognized, an IGMPv2 implementation MUST ignore anything
` past the first 8 octets while processing the packet. However, the
` IGMP checksum is always computed over the whole IP payload, not just
` over the first 8 octets.
`
`Fenner Standards Track [Page 3]
`
`APPENDIX I
`
`Microsoft et al. Exhibit 1019
`
`

`

`RFC 2236 Internet Group Management Protocol November 1997
`
`3. Protocol Description
`
` Note that defaults for timer values are described later in this
` document. Timer and counter names appear in square brackets.
`
` The term "interface" is sometimes used in this document to mean "the
` primary interface on an attached network"; if a router has multiple
` physical interfaces on a single network this protocol need only run
` on one of them. Hosts, on the other hand, need to perform their
` actions on all interfaces that have memberships associated with them.
`
` Multicast routers use IGMP to learn which groups have members on each
` of their attached physical networks. A multicast router keeps a list
` of multicast group memberships for each attached network, and a timer
` for each membership. "Multicast group memberships" means the
` presence of at least one member of a multicast group on a given
` attached network, not a list of all of the members. With respect to
` each of its attached networks, a multicast router may assume one of
` two roles: Querier or Non-Querier. There is normally only one
` Querier per physical network. All multicast routers start up as a
` Querier on each attached network. If a multicast router hears a
` Query message from a router with a lower IP address, it MUST become a
` Non-Querier on that network. If a router has not heard a Query
` message from another router for [Other Querier Present Interval], it
` resumes the role of Querier. Routers periodically [Query Interval]
` send a General Query on each attached network for which this router
` is the Querier, to solicit membership information. On startup, a
` router SHOULD send [Startup Query Count] General Queries spaced
` closely together [Startup Query Interval] in order to quickly and
` reliably determine membership information. A General Query is
` addressed to the all-systems multicast group (224.0.0.1), has a Group
` Address field of 0, and has a Max Response Time of [Query Response
` Interval].
`
` When a host receives a General Query, it sets delay timers for each
` group (excluding the all-systems group) of which it is a member on
` the interface from which it received the query. Each timer is set to
` a different random value, using the highest clock granularity
` available on the host, selected from the range (0, Max Response Time]
` with Max Response Time as specified in the Query packet. When a host
` receives a Group-Specific Query, it sets a delay timer to a random
` value selected from the range (0, Max Response Time] as above for the
` group being queried if it is a member on the interface from which it
` received the query. If a timer for the group is already running, it
` is reset to the random value only if the requested Max Response Time
` is less than the remaining value of the running timer. When a
` group’s timer expires, the host multicasts a Version 2 Membership
` Report to the group, with IP TTL of 1. If the host receives another
`
`Fenner Standards Track [Page 4]
`
`APPENDIX I
`
`Microsoft et al. Exhibit 1019
`
`

`

`RFC 2236 Internet Group Management Protocol November 1997
`
` host’s Report (version 1 or 2) while it has a timer running, it stops
` its timer for the specified group and does not send a Report, in
` order to suppress duplicate Reports.
`
` When a router receives a Report, it adds the group being reported to
` the list of multicast group memberships on the network on which it
` received the Report and sets the timer for the membership to the
` [Group Membership Interval]. Repeated Reports refresh the timer. If
` no Reports are received for a particular group before this timer has
` expired, the router assumes that the group has no local members and
` that it need not forward remotely-originated multicasts for that
` group onto the attached network.
`
` When a host joins a multicast group, it should immediately transmit
` an unsolicited Version 2 Membership Report for that group, in case it
` is the first member of that group on the network. To cover the
` possibility of the initial Membership Report being lost or damaged,
` it is recommended that it be repeated once or twice after short
` delays [Unsolicited Report Interval]. (A simple way to accomplish
` this is to send the initial Version 2 Membership Report and then act
` as if a Group-Specific Query was received for that group, and set a
` timer appropriately).
`
` When a host leaves a multicast group, if it was the last host to
` reply to a Query with a Membership Report for that group, it SHOULD
` send a Leave Group message to the all-routers multicast group
` (224.0.0.2). If it was not the last host to reply to a Query, it MAY
` send nothing as there must be another member on the subnet. This is
` an optimization to reduce traffic; a host without sufficient storage
` to remember whether or not it was the last host to reply MAY always
` send a Leave Group message when it leaves a group. Routers SHOULD
` accept a Leave Group message addressed to the group being left, in
` order to accommodate implementations of an earlier version of this
` standard. Leave Group messages are addressed to the all-routers
` group because other group members have no need to know that a host
` has left the group, but it does no harm to address the message to the
` group.
`
` When a Querier receives a Leave Group message for a group that has
` group members on the reception interface, it sends [Last Member Query
` Count] Group-Specific Queries every [Last Member Query Interval] to
` the group being left. These Group-Specific Queries have their Max
` Response time set to [Last Member Query Interval]. If no Reports are
` received after the response time of the last query expires, the
` routers assume that the group has no local members, as above. Any
` Querier to non-Querier transition is ignored during this time; the
` same router keeps sending the Group-Specific Queries.
`
`Fenner Standards Track [Page 5]
`
`APPENDIX I
`
`Microsoft et al. Exhibit 1019
`
`

`

`RFC 2236 Internet Group Management Protocol November 1997
`
` Non-Queriers MUST ignore Leave Group messages, and Queriers SHOULD
` ignore Leave Group messages for which there are no group members on
` the reception interface.
`
` When a non-Querier receives a Group-Specific Query message, if its
` existing group membership timer is greater than [Last Member Query
` Count] times the Max Response Time specified in the message, it sets
` its group membership timer to that value.
`
`4. Compatibility with IGMPv1 Routers
`
` An IGMPv2 host may be placed on a subnet where the Querier router has
` not yet been upgraded to IGMPv2. The following requirements apply:
`
` The IGMPv1 router will send General Queries with the Max
` Response Time set to 0. This MUST be interpreted as a value of
` 100 (10 seconds).
`
` The IGMPv1 router expects Version 1 Membership Reports in
` response to its Queries, and will not pay attention to Version 2
` Membership Reports. Therefore, a state variable MUST be kept
` for each interface, describing whether the multicast Querier on
` that interface is running IGMPv1 or IGMPv2. This variable MUST
` be based upon whether or not an IGMPv1 query was heard in the
` last [Version 1 Router Present Timeout] seconds, and MUST NOT be
` based upon the type of the last Query heard. This state
` variable MUST be used to decide what type of Membership Reports
` to send for unsolicited Membership Reports as well as Membership
` Reports in response to Queries.
`
` An IGMPv2 host MAY suppress Leave Group messages on a network
` where the Querier is using IGMPv1.
`
` An IGMPv2 router may be placed on a subnet where at least one router
` on the subnet has not yet been upgraded to IGMPv2. The following
` requirements apply:
`
` If any IGMPv1 routers are present, the querier MUST use IGMPv1.
` The use of IGMPv1 must be administratively configured, as there
` is no reliable way of dynamically determining whether IGMPv1
` routers are present on a network. Implementations MAY provide a
` way for system administrators to enable the use of IGMPv1 on
` their routers; in the absence of explicit configuration, the
` configuration MUST default to IGMPv2. When in IGMPv1 mode,
` routers MUST send Periodic Queries with a Max Response Time of
` 0, and MUST ignore Leave Group messages. They SHOULD also warn
` about receiving an IGMPv2 query, although such warnings MUST be
` rate-limited.
`
`Fenner Standards Track [Page 6]
`
`APPENDIX I
`
`Microsoft et al. Exhibit 1019
`
`

`

`RFC 2236 Internet Group Management Protocol November 1997
`
` If a router is not explicitly configured to use IGMPv1 and hears
` an IGMPv1 Query, it SHOULD log a warning. These warnings MUST
` be rate-limited.
`
`5. Compatibility with IGMPv1 Hosts
`
` An IGMPv2 host may be placed on a subnet where there are hosts that
` have not yet been upgraded to IGMPv2. The following requirement
` applies:
`
` The host MUST allow its Membership Report to be suppressed by
` either a Version 1 Membership Report or a Version 2 Membership
` Report.
`
` An IGMPv2 router may be placed on a subnet where there are hosts that
` have not yet been upgraded to IGMPv2. The following requirements
` apply:
`
` If a router receives a Version 1 Membership Report, it MUST set
` a timer to note that there are version 1 hosts present which are
` members of the group for which it heard the report. This timer
` should be the same as the [Group Membership Interval].
`
` If there are version 1 hosts present for a particular group, a
` router MUST ignore any Leave Group messages that it receives for
` that group.
`
`6. Host State Diagram
`
` Host behavior is more formally specified by the state transition
` diagram below. A host may be in one of three possible states with
` respect to any single IP multicast group on any single network
` interface:
`
` - "Non-Member" state, when the host does not belong to the group on
` the interface. This is the initial state for all memberships on
` all network interfaces; it requires no storage in the host.
`
` - "Delaying Member" state, when the host belongs to the group on the
` interface and has a report delay timer running for that membership.
`
` - "Idle Member" state, when the host belongs to the group on the
` interface and does not have a report delay timer running for that
` membership.
`
`Fenner Standards Track [Page 7]
`
`APPENDIX I
`
`Microsoft et al. Exhibit 1019
`
`

`

`RFC 2236 Internet Group Management Protocol November 1997
`
` There are five significant events that can cause IGMP state
` transitions:
`
` - "join group" occurs when the host decides to join the group on the
` interface. It may occur only in the Non-Member state.
`
` - "leave group" occurs when the host decides to leave the group on
` the interface. It may occur only in the Delaying Member and Idle
` Member states.
`
` - "query received" occurs when the host receives either a valid
` General Membership Query message, or a valid Group-Specific
` Membership Query message. To be valid, the Query message must be
` at least 8 octets long, and have a correct IGMP checksum. The
` group address in the IGMP header must either be zero (a General
` Query) or a valid multicast group address (a Group-Specific Query).
` A General Query applies to all memberships on the interface from
` which the Query is received. A Group-Specific Query applies to
` membership in a single group on the interface from which the Query
` is received. Queries are ignored for memberships in the Non-Member
` state.
`
` - "report received" occurs when the host receives a valid IGMP
` Membership Report message (Version 1 or Version 2). To be valid,
` the Report message must be at least 8 octets long and have a
` correct IGMP checksum. A Membership Report applies only to the
` membership in the group identified by the Membership Report, on the
` interface from which the Membership Report is received. It is
` ignored for memberships in the Non-Member or Idle Member state.
`
` - "timer expired" occurs when the report delay timer for the group on
` the interface expires. It may occur only in the Delaying Member
` state.
`
` All other events, such as receiving invalid IGMP messages, or IGMP
` messages other than Query or Report, are ignored in all states.
`
` There are seven possible actions that may be taken in response to the
` above events:
`
` - "send report" for the group on the interface. The type of report
` is determined by the state of the interface. The Report Message is
` sent to the group being reported.
`
`Fenner Standards Track [Page 8]
`
`APPENDIX I
`
`Microsoft et al. Exhibit 1019
`
`

`

`RFC 2236 Internet Group Management Protocol November 1997
`
` - "send leave" for the group on the interface. If the interface
` state says the Querier is running IGMPv1, this action SHOULD be
` skipped. If the flag saying we were the last host to report is
` cleared, this action MAY be skipped. The Leave Message is sent to
` the ALL-ROUTERS group (224.0.0.2).
`
` - "set flag" that we were the last host to send a report for this
` group.
`
` - "clear flag" since we were not the last host to send a report for
` this group.
`
` - "start timer" for the group on the interface, using a delay value
` chosen uniformly from the interval (0, Max Response Time], where
` Max Response time is specified in the Query. If this is an
` unsolicited Report, the timer is set to a delay value chosen
` uniformly from the interval (0, [Unsolicited Report Interval] ].
`
` - "reset timer" for the group on the interface to a new value, using
` a delay value chosen uniformly from the interval (0, Max Response
` Time], as described in "start timer".
`
` - "stop timer" for the group on the interface.
`
` In all of the following state diagrams, each state transition arc is
` labeled with the event that causes the transition, and, in
` parentheses, any actions taken during the transition. Note that the
` transition is always triggered by the event; even if the action is
` conditional, the transition still occurs.
`
`Fenner Standards Track [Page 9]
`
`APPENDIX I
`
`Microsoft et al. Exhibit 1019
`
`

`

`RFC 2236 Internet Group Management Protocol November 1997
`
` ________________
` | |
` | |
` | |
` | |
` --------->| Non-Member |<---------
` | | | |
` | | | |
` | | | |
` | |________________| |
` | | |
` | leave group | join group | leave group
` | (stop timer, |(send report, | (send leave
` | send leave if | set flag, | if flag set)
` | flag set) | start timer) |
` ________|________ | ________|________
` | |<--------- | |
` | | | |
` | |<-------------------| |
` | | query received | |
` | Delaying Member | (start timer) | Idle Member |
` ---->| |------------------->| |
` | | | report received | |
` | | | (stop timer, | |
` | | | clear flag) | |
` | |_________________|------------------->|_________________|
` | query received | timer expired
` | (reset timer if | (send report,
` | Max Resp Time | set flag)
` | < current timer) |
` -------------------
`
` The all-systems group (address 224.0.0.1) is handled as a special
` case. The host starts in Idle Member state for that group on every
` interface, never transitions to another state, and never sends a
` report for that group.
`
` In addition, a host may be in one of two possible states with respect
` to any single network interface:
`
` - "No IGMPv1 Router Present", when the host has not heard an IGMPv1
` style query for the [Version 1 Router Present Timeout]. This is
` the initial state.
`
` - "IGMPv1 Router Present", when the host has heard an IGMPv1 style
` query within the [Version 1 Router Present Timeout].
`
`Fenner Standards Track [Page 10]
`
`APPENDIX I
`
`Microsoft et al. Exhibit 1019
`
`

`

`RFC 2236 Internet Group Management Protocol November 1997
`
` There are two events that can cause state transitions:
`
` - "IGMPv1 query received", when the host receives a query with the
` Max Response Time field set to 0.
`
` - "timer expires", when the timer set to note the presence of an
` IGMPv1 router expires.
`
` And a single action that can be triggered by an event:
`
` - "set timer", setting the timer to its maximum value [Version 1
` Router Present Timeout] and (re)starting it.
`
` ________________
` | |
` | |
` | No IGMPv1 |
` | Router |
` | Present |
` | |
` ---->| |----
` | | | |
` | |________________| |
` timer expires | | IGMPv1 query
` | ________________ | received
` | | | | (set timer)
` | | | |
` | | | |
` -----| IGMPv1 |<---
` | Router |
` | Present |
` | |
` ---->| |----
` | |________________| |
` | |
` | IGMPv1 query received |
` | (set timer) |
` ---------------------------
`
`Fenner Standards Track [Page 11]
`
`APPENDIX I
`
`Microsoft et al. Exhibit 1019
`
`

`

`RFC 2236 Internet Group Management Protocol November 1997
`
`7. Router State Diagram
`
` Router behavior is more formally specified by the state transition
` diagrams below.
`
` A router may be in one of two possible states with respect to any
` single attached network:
`
` - "Querier", when this router is designated to transmit IGMP
` Membership Queries on this network.
`
` - "Non-Querier", when there is another router designated to transmit
` IGMP membership Queries on this network.
`
` The following three events can cause the router to change states:
`
` - "query timer expired" occurs when the timer set for query
` transmission expires.
`
` - "query received from a router with a lower IP address" occurs when
` an IGMP Membership Query is received from a router on the same
` network with a lower IP address.
`
` - "other querier present timer expired" occurs when the timer set to
` note the presence of another querier with a lower IP address on the
` network expires.
`
` There are three actions that may be taken in response to the above
` events:
`
` - "start general query timer" for the attached network.
`
` - "start other querier present timer" for the attached network [Other
` Querier Present Interval].
`
` - "send general query" on the attached network. The General Query is
` sent to the all-systems group (224.0.0.1), and has a Max Response
` Time of [Query Response Interval].
`
`Fenner Standards Track [Page 12]
`
`APPENDIX I
`
`Microsoft et al. Exhibit 1019
`
`

`

`RFC 2236 Internet Group Management Protocol November 1997
`
` --------------------------------
` _______|________ gen. query timer |
` --------- | | expired |
` | Initial |---------------->| | (send general query, |
` --------- (send gen. q., | | set gen. q. timer) |
` set initial gen. q. | |<----------------------
` timer) | Querier |
` | |
` -----| |<---
` | | | |
` | |________________| |
` query received from a | | other querier
` router with a lower | | present timer
` IP address | | expired
` (set other querier | ________________ | (send general
` present timer) | | | | query,set gen.
` | | | | q. timer)
` | | | |
` ---->| Non |----
` | Querier |
` | |
` | |
` ---->| |----
` | |________________| |
` | query received from a |
` | router with a lower IP |
` | address |
` | (set other querier |
` | present timer) |
` ---------------------------
`
` A router should start in the Initial state on all attached networks,
` and immediately move to Querier state.
`
` In addition, to keep track of which groups have members, a router may
` be in one of four possible states with respect to any single IP
` multicast group on any single attached network:
`
` - "No Members Present" state, when there are no hosts on the network
` which have sent reports for this multicast group. This is the
` initial state for all groups on the router; it requires no storage
` in the router.
`
` - "Members Present" state, when there is a host on the network which
` has sent a Membership Report for this multicast group.
`
`Fenner Standards Track [Page 13]
`
`APPENDIX I
`
`Microsoft et al. Exhibit 1019
`
`

`

`RFC 2236 Internet Group Management Protocol November 1997
`
` - "Version 1 Members Present" state, when there is an IGMPv1 host on
` the network which has sent a Version 1 Membership Report for this
` multicast group.
`
` - "Checking Membership" state, when the router has received a
` Leave Group message but has not yet heard a Membership Report for
` the multicast group.
`
` There are six significant events that can cause router state
` transitions:
`
` - "v2 report received" occurs when the router receives a Version 2
` Membership Report for the group on the interface. To be valid, the
` Report message must be at least 8 octets long and must have a
` correct IGMP checksum.
`
` - "v1 report received" occurs when the router receives a Version 1
` Membership report for the group on the interface. The same
` validity requirements apply.
`
` - "leave received" occurs when the router receives an IGMP Group
` Leave message for the group on the interface. To be valid, the
` Leave message must be at least 8 octets long and must have a
` correct IGMP checksum.
`
` - "timer expired" occurs when the timer set for a group membership
` expires.
`
` - "retransmit timer expired" occurs when the timer set to retransmit
` a group-specific Membership Query expires.
`
` - "v1 host timer expired" occurs when the timer set to note the
` presence of version 1 hosts as group members expires.
`
` There are six possible actions that may be taken in response to the
` above events:
`
` - "start timer" for the group membership on the interface - also
` resets the timer to its initial value [Group Membership Interval]
` if the timer is currently running.
`
` - "start timer*" for the group membership on the interface - this
` alternate action sets the timer to [Last Member Query Interval] *
` [Last Member Query Count] if this router is a Querier, or the [Max
` Response Time] in the packet * [Last Member Query Count] if this
` router is a non-Querier.
`
`Fenner Standards Track [Page 14]
`
`APPENDIX I
`
`Microsoft et al. Exhibit 1019
`
`

`

`RFC 2236 Internet Group Management Protocol November 1997
`
` - "start retransmit timer" for the group membership on the interface
` [Last Member Query Interval].
`
` - "start v1 host timer" for the group membership on the interface,
` also resets the timer to its initial value [Group Membership
` Interval] if the timer is currently running.
`
` - "send group-spe