Internet Engineering Task Force Inter-Domain Multicast Routing Working Group INTERNET-DRAFT W. Fenner draft-ietf-idmr-igmp-v2-01.txt Xerox PARC Obsoletes: Appendix I of RFC1112 September 25, 1995 Expires: 2/28/96 Internet Group Management Protocol, Version 2 Status of this Memo This document is an Internet Draft. Internet Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts). Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Inter- net Draft. Distribution of this document is unlimited. Abstract This draft documents IGMPv2, used by IP hosts to report their mul- ticast group memberships to routers. It replaces Appendix I of RFC1112. This document is a product of the Inter-Domain Multicast Routing working group within the Internet Engineering Task Force. Comments are soli- cited and should be addressed to the working group's mailing list at idmr@cs.ucl.ac.uk and/or the author(s). Expires February 1996 [Page 1]
Internet Draft draft-ietf-idmr-igmp-v2-01.txt September 1995 1. 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(*). 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 imple- mented 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. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1.1. Type There are three types of IGMP messages of concern to the host- router interaction: 0x11 = Membership Query 0x16 = Membership Report 0x17 = Leave Group There is an additional type of message, for backwards-compatibility with IGMPv1: 0x12 = Old Membership Report 1.2. Max Response Time The Max Response Time field is meaningful only in a Membership Query message, and specifies the maximum allowed report time in units of 1/10 second. In all other messages, it is set to zero by the sender and ignored by receivers. _________________________ * Routers that are members of multicast groups are expected to behave as hosts as well as routers, and may even respond to their own queries. Expires February 1996 [Page 2]
Internet Draft draft-ietf-idmr-igmp-v2-01.txt September 1995 1.3. Checksum The checksum is the 16-bit one's complement of the one's complement sum of the 8-octet IGMP message. For computing the checksum, the checksum field is set to zero. 1.4. Group Address In a Membership Query message, the group address field is set to zero when sending a General Query (used to learn which groups have members on an attached network), and set to the group address being queried when sending a Group-Specific Query (used to learn if a particular group has any members on an attached network). 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. Informal Protocol Description Note that defaults for timer values are described later in this docu- ment. Timer and counter names appear in square brackets. 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. There are two types of multicast routers: Queriers, and Non-Queriers. There is normally only one Querier per physical net- work. All multicast routers start up as a Querier on each attached net- work. If a multicast router hears a Query message from a router with a lower IP address, it becomes a Non-Querier on that network. Routers periodically [Query Interval] send a General Query on each attached net- work for which this router is the querier, to solicit membership infor- mation. 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). When a host receives a General Query, it sets delay timers for each group of which it is a member on the interface on which it received the query. Each timer is set to a different random value, up to the requested Max Response Time in the Query packet. When a host receives a Group-Specific Query, it sets a delay timer for the group being queried if it is a member on the interface on which it received the query. If a timer for a group is already running, it is reset if and only if the requested Max Response Time is less than the remaining value of the run- ning timer. When a group's timer expires, the host multicasts a Member- ship Report to the group, with IP TTL of 1. If the host receives Expires February 1996 [Page 3]
Internet Draft draft-ietf-idmr-igmp-v2-01.txt September 1995 another host's Report (old or new) while it has a timer running, it stops its timer for the specified group and does not send a Report, 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 Member- ship 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 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 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 sends 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 sends nothing as there must be another member on the subnet. When a Querier receives a Leave Group message, it sets its query inter- val for that group very short [Last Member Query Interval], setting the group membership timer to some multiple of the query interval [Last Member Query Repetition] plus the query interval, and starts sending out Group-Specific queries. If no Reports are received before the member- ship timer expires, the routers assume that the group has no local members, as above. 3. 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 _________________________ * Note that a router should also be prepared to ac- cept a Leave Group message sent to the group being left, as one widely spread IGMPv2 implementation does this. Expires February 1996 [Page 4]
Internet Draft draft-ietf-idmr-igmp-v2-01.txt September 1995 seconds). The IGMPv1 router expects Old Membership Reports in response to its Queries, and will not pay attention to IGMPv2 Membership Reports. Therefore, a state variable must be kept for each interface, describing whether the multicast Querier on that interface is run- ning IGMPv1 or IGMPv2. This variable must be based upon the last time an IGMPv1 Query was heard, *not* on the type of the last Query heard, as an IGMPv2 router may restart and send a Query before it realizes that it is not the Querier for the subnet. 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 optionally 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 require- ments apply: If any IGMPv1 routers are present, the querier must use IGMPv1. Since there was no querier election specification in RFC1112, the rules followed by the IGMPv1 router may not agree with those in this document. In this case, the IGMPv2 router must follow the rules established by the routing protocol for electing a querier. 4. 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 requirements apply: The host must allow its Membership Report to be suppressed by either an Old Membership Report or an IGMPv2 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 an Old Membership Report, it must set a timer to note that there are old hosts present which are members of the group for which it heard the report. This timer should be the same as the [Group Membership Timer]. If there are old hosts present for a particular group, a router must ignore any Leave Group messages that it receives. Expires February 1996 [Page 5]
Internet Draft draft-ietf-idmr-igmp-v2-01.txt September 1995 5. 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 inter- face and does not have a report delay timer running for that membership. 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 Gen- eral 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. 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 or a valid IGMP Old Membership Report message. 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. Expires February 1996 [Page 6]
Internet Draft draft-ietf-idmr-igmp-v2-01.txt September 1995 All other events, such as receiving invalid IGMP messages, or IGMP mes- sages 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. - "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 should be skipped. - "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 random delay value up to the Max Response Time in the Query. If this is an unsolicited Report, the timer is to use a random delay value up to 10 seconds. - "reset timer" for the group on the interface to a new value, using a random delay value up to the requested response time in the Query. - "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. Expires February 1996 [Page 7]
Internet Draft draft-ietf-idmr-igmp-v2-01.txt September 1995 ________________ | | | | | | | | --------->| Non-Member |<--------- | | | | | | | | | | | | | |________________| | | | | | leave group | join group | leave group | (stop timer, |(send report, | (send leave if | send leave if | set flag, | 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 [Old Router Present Timeout]. This is the ini- tial state. - IGMPv1 Router Present, when the host has heard an IGMPv1 style query within the [Old Router Present Timeout]. Expires February 1996 [Page 8]
Internet Draft draft-ietf-idmr-igmp-v2-01.txt September 1995 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 [Old 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) | --------------------------- 6. 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: Expires February 1996 [Page 9]
Internet Draft draft-ietf-idmr-igmp-v2-01.txt September 1995 - 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 transmis- sion 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 net- work 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 interface. - "start other querier present timer" for the interface. - "send general query" on the interface. Expires February 1996 [Page 10]
Internet Draft draft-ietf-idmr-igmp-v2-01.txt September 1995 -------------------------------- _______|________ 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 expired IP address | | (send general query, (set other querier | ________________ | set gen. q. timer) present 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 interfaces, and immediately move to Querier state. In addition, to keep track of which groups have members, a router may be in one of three possible states with respect to any single IP multicast group on any single network interface: - No Members Present state, when there are no hosts on the network which have sent reports for this multicast group. This is the ini- tial 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. Expires February 1996 [Page 11]
Internet Draft draft-ietf-idmr-igmp-v2-01.txt September 1995 - Old Members Present state, when there is an IGMPv1 host on the net- work which has sent an Old 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 transi- tions: - "report received" occurs when the router receives a 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. - "old report received" occurs when the router receives an Old Membership report for the group on the interface. The same vali- dity 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. - "old host timer expired" occurs when the timer set to note the presence of old 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 Timer] if the timer is currently running. - "start retransmit timer" for the group membership on the interface [Last Member Query Interval]. - "start old host timer" for the group membership on the interface - also resets the timer to its initial value [Group Membership Timer] if the timer is currently running. Expires February 1996 [Page 12]
Internet Draft draft-ietf-idmr-igmp-v2-01.txt September 1995 - "send group-specific query" for the group on the interface. - "allow forwarding" traffic received for this group onto this inter- face. - "prevent forwarding" traffic received for this group onto this interface. Expires February 1996 [Page 13]
Internet Draft draft-ietf-idmr-igmp-v2-01.txt September 1995 The state diagram for a router in Querier state follows: ________________ ----------------------------| |<----------------------------- | | | | | timer expired| |timer expired | | (prevent forwarding)| No Members |(prevent forwarding) | | ------->| Present |<--------- | | | | | | | |old report rec'd | | | | | |(allow forwarding, | | | | | | start timer, | |________________| | --------------- | | start old host | | | | rexmt timer | | | timer) | |report received | | expired | | | | |(allow forwarding,| | (send g-s | | | | | start timer) | | query, | | | __________|______ | ________|_|______ st rxmt | | | | |<--------- | | tmr) | | | | | | |<------- | | | | report received | | | | | | (start timer) | | | | | Members Present |<-------------------| Checking | | | ----->| | leave received | Membership | | | | | | (start timer*, | | | | | | | start rexmt timer,| | | | | | | send g-s query) | | | | | --->| |------------------->| | | | | | |_________________| |_________________| | | | |report received | | | | | | |(start timer) | |old report rec'd |old report rec'd | | | ---------------- |(start timer, |(start timer, | | |old host | start old host timer) | start old host timer) | | |tmr ______________V__ | | | |exp'd | |<---------------------- | | ------| | | | | |timer expired | | | Old |(prevent forwarding) | ------->| Members Present |------------------------------------------------- | | ------->| |<-------------------- | |_________________| old report rec'd | | report received | | (start timer, | | (start timer) | | start old host timer) | ----------------- -------------------------- _________________________ * When entering the Checking Membership state, the Expires February 1996 [Page 14]
Internet Draft draft-ietf-idmr-igmp-v2-01.txt September 1995 The state diagram for a router in Non-Querier state is similar, but non-Queriers do not send any messages and are only driven by message re- ception. ________________ | | | | timer expired| |timer expired (prevent forwarding)| No Members |(prevent forwarding) --------->| Present |<--------- | | | | | | | | | | | | | |________________| | | | | | |report received | | |(allow forwarding,| | | start timer) | ________|________ | ________|________ | |<--------- | | | | report received | | | | (allow forwarding,| | | | start timer) | | | Members Present |<-------------------| Checking | | | g-s query rec'd | Membership | | | (start timer*) | | ---->| |------------------->| | | |_________________| |_________________| | report received | | (start timer) | ----------------- 7. List of timers and default values _________________________ timer is set to [Last Member Query Interval] * [Last Membership Query Count], not [Group Membership Timer]. * When a non-querier router receives a Group Specific query in the Members Present state, it sets its group membership timer to a multiple [Last Member Query Count] of the Max Response Time in the Group Specific query. It ignores Group Specific queries received in the Checking Membership state. Expires February 1996 [Page 15]
Internet Draft draft-ietf-idmr-igmp-v2-01.txt September 1995 7.1. Query Interval The Query Interval is the interval between General Queries sent by the Querier. Default: 125 seconds. 7.2. Group Membership Timer The Group Membership Timer is the amount of time that must pass before a multicast router decides there are no more members of a group on a net- work. Default: twice the Query Interval plus one Query Response Inter- val. 7.3. Query Response Interval The Max Response Time inserted into the periodic General Queries. Default: 100 (10 seconds) 7.4. Startup Query Interval The Startup Query Interval is the interval between General Queries sent by a Querier on startup. Default: 1/4 the Query Interval. 7.5. Startup Query Count The Startup Query Count is the number of Queries sent out on startup, separated by the Startup Query Interval. Default: 2. 7.6. Unsolicited Report Interval The Unsolicited Report Interval is the time between repetitions of a host's initial report of membership in a group. Default: 10 seconds. 7.7. Last Member Query Interval The Last Member Query Interval is the Max Response Time inserted into Group-Specific Queries sent in response to Leave Group messages, and is also the amount of time between Group-Specific Query messages. Default: 10 (1 second) 7.8. Last Member Query Count The Last Member Query Count is the number of Group-Specific Queries sent before the router assumes there are no local members. Default: 2. 7.9. Old Router Present Timeout The Old Router Present Timeout is how long a host must wait after hear- ing an Old (IGMPv1) Query before it may send any IGMPv2 messages. Expires February 1996 [Page 16]
Internet Draft draft-ietf-idmr-igmp-v2-01.txt September 1995 Default: 400 seconds. 8. Security Considerations Security issues are not discussed in this memo. 9. Acknowledgments IGMPv2 was designed by Rosen Sharma and Steve Deering. Expires February 1996 [Page 17]
Internet Draft draft-ietf-idmr-igmp-v2-01.txt September 1995 10. Appendix I - Changes from IGMPv1 The IGMPv1 "Version" and "Type" fields were combined into a single "Type" field. A new IGMP Type was assigned to IGMPv2 Membership Report messages, so a router may tell the difference between an IGMPv1 and IGMPv2 host report. A new IGMP Type was created for the IGMPv2 Leave Group message. The Membership Query message was changed so that a previously unused field contains a new value, the Max Response Time. The IGMPv2 spec now specifies a querier election mechanism. In IGMPv1, the querier election was left up to the multicast routing protocol, and different protocols used different mechanisms. This could result in more than one querier per network, so the election mechanism has been standardized in IGMPv2. However, this means that care must be taken when an IGMPv2 router is trying to coexist with an IGMPv1 router that uses a different querier election mechanism. In particular, it means that an IGMPv2 router must be able to act as an IGMPv1 router on a par- ticular network if configured to do so. The actions required include: - Set the Max Response Time field to 0 in all queries. - Ignore Leave Group messages. The IGMPv2 spec relaxed the requirements on validity-checking for Membership Queries and Membership Reports. When upgrading an implemen- tation, be sure to remove any checks that do not belong. Expires February 1996 [Page 18]
Internet Draft draft-ietf-idmr-igmp-v2-01.txt September 1995 11. Author's Address William C. Fenner Xerox PARC 3333 Coyote Hill Road Palo Alto, CA 94304 Phone: +1 415 812 4816 Email: fenner@parc.xerox.com Expires February 1996 [Page 19]
