RFC 2236 (RFC2236)
Internet RFC/STD/FYI/BCP Archives
[ RFC Index | RFC Search | Usenet FAQs | Web FAQs | Documents | Cities ]
Alternate Formats: rfc2236.txt | rfc2236.txt.pdf
HYPERLINK "http://www.faqs.org/rfccomment.php?rfcnum=2236" \t "_blank"
Comment on RFC 2236
RFC 2236 - Internet Group Management Protocol, Version 2
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
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
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.
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
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.
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.
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.
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.
- "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
本文档为【IGMP协议V2版本(RFC2236)】,请使用软件OFFICE或WPS软件打开。作品中的文字与图均可以修改和编辑,
图片更改请在作品中右键图片并更换,文字修改请直接点击文字进行修改,也可以新增和删除文档中的内容。
该文档来自用户分享,如有侵权行为请发邮件ishare@vip.sina.com联系网站客服,我们会及时删除。
[版权声明] 本站所有资料为用户分享产生,若发现您的权利被侵害,请联系客服邮件isharekefu@iask.cn,我们尽快处理。
本作品所展示的图片、画像、字体、音乐的版权可能需版权方额外授权,请谨慎使用。
网站提供的党政主题相关内容(国旗、国徽、党徽..)目的在于配合国家政策宣传,仅限个人学习分享使用,禁止用于任何广告和商用目的。