draft-ietf-pim-explicit-tracking-02.txt   draft-ietf-pim-explicit-tracking-03.txt 
PIM Working Group H. Asaeda PIM Working Group H. Asaeda
Internet-Draft NICT Internet-Draft NICT
Intended status: Informational N. Leymann Intended status: Informational December 11, 2012
Expires: April 19, 2013 Deutsche Telekom AG Expires: June 14, 2013
October 16, 2012
IGMP/MLD-Based Explicit Membership Tracking Function for Multicast IGMP/MLD-Based Explicit Membership Tracking Function for Multicast
Routers Routers
draft-ietf-pim-explicit-tracking-02 draft-ietf-pim-explicit-tracking-03
Abstract Abstract
This document describes the IGMP/MLD-based explicit membership This document describes the IGMP/MLD-based explicit membership
tracking function for multicast routers. The explicit tracking tracking function for multicast routers. The explicit tracking
function is useful for accounting and contributes to saving network function contributes to saving network resources and fast leaves
resource and fast leaves (i.e. shortened leave latency). (i.e. shortening leave latency).
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 19, 2013. This Internet-Draft will expire on June 14, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Explicit Tracking Function . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Specific Query Surpression Mechanism . . . . . . . . . . . 4 3. Explicit Tracking Function . . . . . . . . . . . . . . . . . . 4
2.2. Shortening Leave Latencies . . . . . . . . . . . . . . . . 5 3.1. Membership State Information . . . . . . . . . . . . . . . 4
2.3. Considerations . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Specific Query Suppression . . . . . . . . . . . . . . . . 5
3. Membership State Information . . . . . . . . . . . . . . . . . 6 3.3. Shortening Leave Latency . . . . . . . . . . . . . . . . . 6
4. Multicast Router Behavior . . . . . . . . . . . . . . . . . . . 7 4. Lowering the Possibility of Outdated Membership State . . . . . 7
5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. All-Zero and Unspecified Source Addresses . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 6. Compatibility with Older Version Protocols . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The Internet Group Management Protocol (IGMP) [1] for IPv4 and the The Internet Group Management Protocol (IGMP) [1] for IPv4 and the
Multicast Listener Discovery Protocol (MLD) [2] for IPv6 are the Multicast Listener Discovery Protocol (MLD) [2] for IPv6 are the
standard protocols used by listener hosts and multicast routers. standard protocols used by member hosts and multicast routers. When
When a host starts listening particular multicast channels, it sends a host starts/finishes listening to particular multicast channels, it
IGMP/MLD State-Change Report messages specifying the corresponding sends IGMP/MLD State-Change Report messages specifying the
channel information as the join/leave request to its upstream router corresponding channel information as the join/leave request to its
(i.e., an adjacent multicast router or IGMP/MLD proxy [4]). This upstream router (i.e., an adjacent multicast router or IGMP/MLD proxy
"unsolicited" Report is sent only once upon reception. device [5]). The "unsolicited" report messages are sent only once
upon reception/departure.
IGMP/MLD are non-reliable protocols; the unsolicited Report messages IGMP/MLD are non-reliable protocols; the unsolicited report messages
may be lost or not be reached to upstream routers. To recover the may be lost or may not reached upstream routers. To resolve the
problem, the routers need to update membership information by sending problem, routers need to update membership information by
IGMP/MLD General Query messages periodically. Member hosts then periodically sending IGMP/MLD General Query messages. Member hosts
reply with "solicited" Report messages whenever they receive the then reply with "solicited" report messages whenever they receive the
Query messages. query messages.
Multicast routers are able to periodically maintain the multicast Multicast routers are capable of periodically maintaining the
listener (or membership) state of downstream hosts attached on the multicast membership state of downstream hosts attached to the same
same link by getting unsolicited Report messages and synchronize the link by acquiring unsolicited report messages and synchronizing the
actual membership state within the General Query timer interval actual membership state within the General Query timer interval
(i.e., [Query Interval] value defined in [1][2].) However, this (i.e., [Query Interval] value defined in [1][2].) However, this
approach does not guarantee that the membership state is always approach does not guarantee that the membership state is always
perfectly synchronized. To minimize the possibility of having the perfectly synchronized. To minimize the possibility of having
outdated membership information, routers may shorten the periodic outdated membership information, routers may shorten the periodic
General Query timer interval. Unfortunately, this would increase the General Query timer interval. Unfortunately, this increases the
number of transmitted solicited Report messages and induce network number of transmitted solicited report messages and induces network
congestion. And the more the network congestion is occurred, the congestion. And the greater the amount of network congestion, the
more IGMP/MLD Report messages may be lost and the membership state greater the potential for IGMP/MLD report messages being lost and the
information may be outdated in the router. membership state information being outdated in the router.
The IGMPv3 [1] and MLDv2 [2] protocols can provide the capability of
keeping track of downstream (adjacent) multicast listener state to
multicast routers. This document describes the "IGMP/MLD-based
explicit member tracking function" for multicast routers and details
the way for routers to implement the function. By enabling the
explicit tracking function, routers can keep track of the downstream
multicast membership state. This function implements the following
requirements:
o Per-host accounting The IGMPv3 [1] and MLDv2 [2] protocols can provide the ability to
keep track of the downstream (adjacent) multicast membership state to
multicast routers, yet the specifications are not clearly given.
This document describes the "IGMP/MLD-based explicit member tracking
function" for multicast routers and details a way for routers to
implement the function. By enabling this explicit tracking function,
routers can keep track of the downstream multicast membership state.
This function enables the following:
o Reducing the number of transmitted Query and Report messages o Reducing the number of transmitted query and report messages
o Shortening leave latencies o Shortening leave latencies
o Per-host accounting
o Maintaining multicast channel characteristics (or statistics) o Maintaining multicast channel characteristics (or statistics)
where this document mainly focuses on the above second and third In addition, the processing of IGMP membership or MLD listener
bullets in the following sections. messages consumes CPU resources on individual IGMP/MLD querier and
report sender devices. The explicit tracking function therefore
reduces not only the network load but also the CPU load on these
devices.
The explicit tracking function does not guarantee that the membership
state will always be perfectly synchronized; the list of tracked
member hosts may be outdated in the router because of host departure
from the network without sending State-Change Report messages or loss
of such messages due to network congestion. Therefore, a router
enabling the function ought to send periodic IGMPv3/MLDv2 General
Query messages and inquire about solicited IGMPv3/MLDv2 report
messages from downstream member hosts to maintain an up-to-date
membership state.
The explicit tracking function potentially requires a large amount of
memory so that routers keep all membership states. Particularly when
a router needs to maintain a large number of member hosts, this
resource requirement could have an impact. Operators may decide to
disable this function when their routers have insufficient memory
resources, despite the benefits mentioned above.
The explicit tracking function does not change message formats used The explicit tracking function does not change message formats used
by the standard IGMPv3 [1] and MLDv2 [2], and their lightweight by the standard IGMPv3 [1] and MLDv2 [2], and their lightweight
version protocols [3]. It does not change a multicast data sender's version protocols [3]; nor does it change a multicast data sender's
and receiver's behavior as well. and receiver's behavior.
2. Explicit Tracking Function 2. Terminology
2.1. Specific Query Surpression Mechanism 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 [4].
The explicit tracking function can reduce the number of Group- 3. Explicit Tracking Function
Specific or Group-and-Source Specific Query messages transmitted from
a router, and then the number of Current-State Report messages
transmitted from member hosts. As the result, network resources used
for IGMP/MLD query-and-reply communications between a router and
member hosts can be saved. This mechanism is called "specific query
surpression mechanism".
According to [1] and [2], whenever a router receives the State-Change 3.1. Membership State Information
Report, it sends the corresponding Group-Specific or Group-and-Source
Specific Query messages to confirm whether the Report sender is the
last member host or not. After getting these Query messages, all
member hosts joining the corresponding channel reply with own
Current-State Report messages. This condition requires transmitting
a number of Current-State Report messages and consumes network
resources especially when many hosts have been joining the same
channel.
On the other hand, if a router enables the explicit tracking A router enabling the explicit tracking function maintains the
function, it does not need to always ask Current-State Report message "membership state information". When a multicast router receives a
transmission to the member hosts whenever it receives the State- Current-State or State-Change Report message, it creates this
Change Report. This is because the explicit tracking function works membership state information or adds or deletes the receiver IP
with the expectation that the State-Change Report sender is the last address to or from it. If there are no more receivers maintained,
remaining member of the channel. Even if this expectation is wrong the router may keep the membership state information with an empty
(i.e., the State-Change Report sender was not the sole member), other receiver list.
members remaining in the same channel will reply with identical
Report messages, so the end result is the same and no problem occurs.
(Section 3 details the point.)
In addition, the processing of IGMP membership or MLD listener The membership state information consists of the following
messages consumes CPU resources on each IGMP/MLD querier and report information:
sender devices themselves. Therefore, the explicit tracking function
reduces not only the network load but also the CPU load on these (S, G, number of receivers, (receiver records))
devices as well.
where each receiver record is of the form:
(IGMP/MLD membership/listener report sender's address)
This state information must work properly when a receiver (i.e.,
report sender) sends the identical report messages multiple times.
In the state information, each S and G indicates a single IPv4/IPv6
address. S is set to "Null" for Any-Source Multicast (ASM)
communication (i.e., (*,G) join reception). In order to simplify the
implementation, the explicit tracking function does not keep the
state of (S,G) joined with EXCLUDE filter mode. If a router receives
an (S,G) join/leave request with EXCLUDE filter mode from the
downstream hosts, it translates it to a (*,G) join state/leave
request and records the state and the receivers' addresses in the
maintained membership state information. Note that this membership
state translation does not change the routing protocol behavior. The
routing protocol must deal with the original join/leave request and
translate the request only for the membership state information.
3.2. Specific Query Suppression
In accordance with [1] and [2], whenever a router receives the State-
Change Report, it sends the corresponding Group-Specific or Group-
and-Source Specific Query messages to confirm whether or not the
report sender is the sole member host. All member hosts joining the
identical channel send their own Current-State Report messages after
acquiring these query messages. Transmitting a large number of
Current-State Report messages consumes network resources, and this
may pose a particular problem when many hosts joining the identical
channel send these reports simultaneously.
The explicit tracking function can reduce the number of Group-
Specific or Group-and-Source Specific Query messages transmitted from
a router, and reduce the number of Current-State Report messages
transmitted from member hosts. If a router enables the explicit
tracking function with "specific query suppression", it suppresses
specific query transmission and transmits specific query messages
only when the router expects that the State-Change Report sender is
the sole member of the channel, based on its membership state
information (expressed in Section 3.1).
As standard behavior for [1] and [2], a router also sends a Group-
Specific or Group-and-Source Specific Query multiple times when it
receives a State Change Report message (e.g., leave request) from a
member host. This is in order to confirm whether or not the host is
the sole member. However, if the router enabling the explicit
tracking function runs specific query suppression and receives one or
more replies for the specific query retransmission from the
downstream member(s), the router can cancel resending of the
identical specific query message(s).
Note that the default behavior of the router that supports the Note that the default behavior of the router that supports the
explicit tracking function disables this specific query surpression explicit tracking function SHOULD disable this specific query
mechanism, in order to avoid the risk caused by the situation in suppression in order to avoid the risk caused by the situation in
which multiple multicast routers exist on a LAN and the querier which multiple multicast routers exist on a LAN and the querier
router is not the forwarder router. When the querier surpresses the router is not the forwarder router. When the querier suppresses the
specific query message transmission, if it recognizes that the State- specific query message transmission, and expects that the State-
Change Report sender is not the sole member of the channel, it does Change Report sender is not the sole member of the channel, it does
not send the specific query and all routers on the same LAN do not not send the specific query and none of the routers on the same LAN
receive Current-State Report message from the member hosts. The receive a Current-State Report message from the corresponding member
forwarder in this case may prune the routing path, although there are hosts. The forwarder in this case may prune the routing path though
other member hosts subscribing the channel on the LAN. there are other member hosts subscribing to the channel on the LAN.
2.2. Shortening Leave Latencies 3.3. Shortening Leave Latency
The explicit tracking function works with the expectation that the A router enabling the explicit tracking function can shorten leave
State-Change Report sender is the last remaining member of the latencies by tuning several timers and values to what it expects
channel. Thanks to this functionality, a router can tune timers and whether or not the State-Change Report sender is the channel's sole
values related to decide that the State-Change Report sender was the member.
sole member.
The [Last Member Query Interval] (LMQI) and [Last Listener Query The [Last Member Query Interval] (LMQI) and [Last Listener Query
Interval] (LLQI) values specify the maximum time allowed before Interval] (LLQI) values specify the maximum time allowed before
sending a responding Report. The [Last Member Query Count] (LMQC) sending a responding Report. The [Last Member Query Count] (LMQC)
and [Last Listener Query Count] (LLQC) are the number of Group- and [Last Listener Query Count] (LLQC) are the number of Group-
Specific Queries or Group-and-Source Specific Queries sent before the Specific Queries or Group-and-Source Specific Queries sent before the
router assumes there are no local members. The [Last Member Query router assumes there are no local members. The [Last Member Query
Time] (LMQT) and [Last Listener Query Time] (LLQT) values are the Time] (LMQT) and [Last Listener Query Time] (LLQT) values are the
total time the router should wait for a report, after the Querier has total time the router should wait for a report after the Querier has
sent the first query. sent the first query.
The default values for LMQI/LLQI defined in the standard The default value for LMQI/LLQI defined in the standard
specifications [1][2] are 1 second. For the router enabling the specifications [1][2] is 1 second. For a router enabling the
explicit tracking function, LMQI/LLQI would be set to 1 second or explicit tracking function, the LMQI/LLQI MAY be set to 1 second or
shorter. The LMQC/LLQC may be set to "1" for the router, whereas shorter. The LMQC/LLQC values MAY be set to 1 for the router,
their default values are the [Robustness Variable] value whose whereas their default values are the [Robustness Variable] value
default value is "2". Smaller LMQC/LLQC give smaller LMQT/LLQT; this whose default value is 2. Smaller LMQC/LLQC values give smaller
condition shortens the leave latencies. LMQT/LLQT, which shortens the leave latencies. On the other hand,
setting smaller LMQC/LLQC values poses the risk described in
2.3. Considerations Section 4. Operators setting smaller LMQC/LLQC values must recognize
this tradeoff.
As with the basic concepts of IGMP and MLD, the explicit tracking
function does not guarantee the membership state is always perfectly
synchronized; routers enabling the explicit tracking function still
need to send IGMPv3/MLDv2 Query messages and inquire solicited
IGMPv3/MLDv2 Report messages from downstream members to maintain
downstream membership state.
o IGMP/MLD messages are non-reliable and may be lost in the
transmission, therefore routers need to confirm the membership by
sending Query messages.
o To preserve compatibility with older versions of IGMP/MLD, routers
need to support downstream hosts that are not upgraded to the
latest versions of IGMP/MLD and run the report suppression
mechanism.
o It is impossible to identify hosts when hosts send IGMP reports
with a source address of 0.0.0.0.
Regarding the last bullet, the IGMPv3 specification [1] mentions that
an IGMPv3 Report is usually sent with a valid IP source address,
although it permits that a host uses the 0.0.0.0 source address (as
it happens that the host has not yet acquired an IP address), and
routers MUST accept a report with a source address of 0.0.0.0. The
MLDv2 specification [2] mentions that an MLDv2 Report MUST be sent
with a valid IPv6 link-local source address, although an MLDv2 Report
can be sent with the unspecified address (::), if the sending
interface has not acquired a valid link-local address yet. [2] also
mentions that routers silently discard a message that is not sent
with a valid link-local address or sent with the unspecified address,
without taking any action, because of the security consideration.
Another concern is that the explicit tracking function requires
additional processing capability and a possibly large memory for
routers to keep all membership states. Especially when a router
needs to maintain a large number of member hosts, this resource
requirement may be potentially-impacted. Operators may decide to
disable this function when their routers do not have enough memory
resources.
3. Membership State Information
The explicit tracking function is implemented with the following
membership state information:
(S, G, number of receivers, (receiver records))
where each receiver record is of the form:
(IGMP/MLD Membership/Listener Report sender's address)
This state information must work properly when a receiver (i.e., 4. Lowering the Possibility of Outdated Membership State
Report sender) sends the same Report messages multiple times.
In the state information, each "S" and "G" indicates a single IPv4/ There are possibilities that the membership expectation performed by
IPv6 address. "S" is set to "Null" for an Any-Source Multicast (ASM) a router enabling the explicit tracking function will be inconsistent
communication (i.e., (*,G) join reception). In order to simplify the due to an outdated membership state. For example, (1) a router
implementation, the explicit tracking function does not keep the expects that more than one corresponding member host exists on its
state of (S,G) join with EXCLUDE filter mode. If a router receives LAN, but in fact no member host exists for that multicast channel, or
(S,G) join/leave request with EXCLUDE filter mode from the downstream (2) a router expects that no corresponding member host exists on its
hosts, it translates the join/leave request to (*,G) join state/leave LAN, but in fact more than one member host exists for that multicast
request and records the state and the receivers' addresses into the channel. These cases are particularly likely for a router that
maintained membership state information. Note that this membership enables specific query suppression (as in Section 3.2) and configures
state translation does not change the routing protocol behavior; the small LMQC/LLQC for shortening leave latency (as in Section 3.3).
routing protocol must deal with the original join/leave request and
translate the request only for the membership state information.
4. Multicast Router Behavior The first of these cases may occur in an environment where the sole
member host departs the network without sending a State-Change Report
message. This is because a router enabling specific query
suppression does not send a specific query if it believes the report
sender is not the sole member host. The router later detects that
there is no member host for the corresponding channels when it does
not receive a Current-State Report within the timeout of the response
for the periodic General Query. However, this situation prolongs
leave latency and wastes network resources since the router forwards
unneeded traffic until that point.
The explicit tracking function makes routers expect whether the The second case occurs when a router sends a specific query but does
State-Change Report sender is the last remaining member of the not receive a State-Change Report from a downstream host within an
channel. Therefore the router transmits a corresponding Current- LMQT or LLQT period. It recognizes that no member host exists on the
State Report message only when the router thinks that the State- LAN and might prune the routing path. The router reestablishes the
Change Report sender is the last remaining member of the channel. routing path when it receives the solicited report message for the
This contributes to saving the network resources and also shortening channels. However, the downstream hosts may loose the data packets
leave latency. until the routing path is reestablished and the data forwarding is
restarted.
To synchronize the membership state information, when a multicast In order to reduce the possibility of the incorrect membership
router receives a Current-State or State-Change Report message, it expectation and keep the up-to-date membership state information,
adds the receiver IP address to or delete from the receiver records when a router enabling the explicit tracking function enables
or creates the corresponding membership state information. If there specific query suppression, the router SHOULD configure the LMQC/LLQC
are no more receiver records left, the membership state information value to 2 (the default value of the [Robustness Variable] value) or
is deleted from the router. higher; or, when a router enabling the explicit tracking function
configures a small LMQC/LLQC, the router SHOULD NOT enable specific
query suppression.
However, the membership state information may be still outdated in 5. All-Zero and Unspecified Source Addresses
the router. It may be happened especially in a mobile multicast
environment that some member hosts have joined to or left from the
network without sending State-Change Report messages. Or, some
State-Change Report messages are lost due to network congestion.
Therefore, the router enabling the explicit tracking function ought
to send the periodic General Query regularly.
Regarding the leave latency, as specified in Section 2.2, the The IGMPv3 specification [1] mentions that an IGMPv3 report is
explicit tracking function contributes to the fast leave by setting usually sent with a valid IP source address, yet it permits a host to
LMQI/LLQI to "1" second or shorter and LMQC/LLQC to "1". However, if use the 0.0.0.0 source address (since the host has not yet acquired
LMQC/LLQC is configured "2" or bigger value, then the router's an IP address), and routers must accept a report with this source
behavior may be changed from the standard specification. According address. The MLDv2 specification [2] mentions that an MLDv2 report
to [1] and [2], a router sends a Group- (and-Source) Specific Query must be sent with a valid IPv6 link-local source address, yet an
[LMQC - 1] or [LLQC - 1] times when it receives State Change Report MLDv2 report may be sent with the unspecified address (::) if the
message (e.g. leave request) from a member host, in order to confirm sending interface has not acquired a valid link-local address. [2]
whether or not the host is the only remaining member. However, this also mentions that routers silently discard a message that is not
document RECOMMENDS that if the router enabling the explicit tracking sent with a valid link-local address or sent with the unspecified
function receives the corresponding Current State Report before the address, without taking any action, because of security
Specific Query retransmission, it cancels sending the same Specific considerations.
Query for other [LMQC - 1] or [LLQC - 1] times.
Note that there is some risk that a router misses or looses Report When a router enabling the explicit tracking function receives IGMP/
messages sent from remaining members if the router adopts small LMQC/ MLD report messages with an all-zero or unspecified source address,
LLQC; however the wrong expectation would be lower happened for the it deals with the IGMP/MLD report messages correctly as defined in
router enabling the explicit tracking function. And to avoid the [1][2] and continuously keeps track of the membership state, but
problem, a router can start sending a Group- (and-Source) Specific SHOULD NOT maintain the host specifying all-zero or an unspecified
Query message when it expects the number of the remaining members is source address in its membership state information.
small, such as 5, but not 0.
5. Compatibility 6. Compatibility with Older Version Protocols
The explicit tracking function does not work with the older versions The explicit tracking function does not work with older versions of
of IGMP or MLD, IGMPv1 [5], IGMPv2 [6] or MLDv1 [7], because a member IGMP or MLD, IGMPv1 [6], IGMPv2 [7], or MLDv1 [8], because a member
host using these protocols adopts a report suppression mechanism by host using these protocols enables "membership report suppression" by
which a host would cancel sending a pending membership Reports if a which the host will cancel sending pending membership reports if a
similar Report was observed from another member on the network. similar report is observed from another member on the network.
If a multicast router enabling the explicit tracking function changes To preserve compatibility with older versions of IGMP/MLD, routers
its compatibility mode to the older versions of IGMP or MLD, the need to support downstream hosts that are not upgraded to the latest
router should turn off the explicit tracking function but should not versions and run membership report suppression. Therefore, if a
flush the maintained membership state information (i.e., keep the multicast router enabling the explicit tracking function changes its
current membership state information as is). When the router changes compatibility mode to the older versions, the router SHOULD disable
back to IGMPv3 or MLDv2 mode, it would resume the function with the the explicit tracking function. On the other hand, the router MAY
kept membership state information, even if the state information is NOT flush the maintained membership state information. When the
outdated. This manner would give "smooth state transition" that does router changes back to IGMPv3 or MLDv2 mode, it resumes the function
not initiate the membership state from scratch and synchronizes the with the old membership state information even if the state
actual membership state smoothly. information is outdated. This provides "smooth state transition"
that does not initiate the membership state information from scratch
and synchronizes the actual membership state smoothly.
6. IANA Considerations 7. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
7. Security Considerations 8. Security Considerations
There is no additional security considerations. There is no additional security consideration for [1][2][3] provided.
8. Acknowledgements 9. Acknowledgements
Toerless Eckert, Stig Venaas, and others provided many constructive Toerless Eckert, Sergio Figueiredo, Nicolai Leymann, Stig Venaas, and
and insightful comments. others provided many constructive and insightful comments.
9. References 10. References
9.1. Normative References 10.1. Normative References
[1] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [1] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version 3", Thyagarajan, "Internet Group Management Protocol, Version 3",
RFC 3376, October 2002. RFC 3376, October 2002.
[2] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 [2] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004. (MLDv2) for IPv6", RFC 3810, June 2004.
[3] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet Group [3] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet Group
Management Protocol Version 3 (IGMPv3) and Multicast Listener Management Protocol Version 3 (IGMPv3) and Multicast Listener
Discovery Version 2 (MLDv2) Protocols", RFC 5790, February 2010. Discovery Version 2 (MLDv2) Protocols", RFC 5790, February 2010.
9.2. Informative References [4] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", RFC 2119, March 1997.
[4] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet 10.2. Informative References
[5] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet
Group Management Protocol (IGMP) / Multicast Listener Discovery Group Management Protocol (IGMP) / Multicast Listener Discovery
(MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")",
RFC 4605, August 2006. RFC 4605, August 2006.
[5] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, [6] Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
August 1989. August 1989.
[6] Fenner, W., "Internet Group Management Protocol, Version 2", [7] Fenner, W., "Internet Group Management Protocol, Version 2",
RFC 2373, July 1997. RFC 2373, July 1997.
[7] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener [8] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999. Discovery (MLD) for IPv6", RFC 2710, October 1999.
Authors' Addresses Author's Address
Hitoshi Asaeda Hitoshi Asaeda
National Institute of Information and Communications Technology National Institute of Information and Communications Technology (NICT)
Network Architecture Laboratory
4-2-1 Nukui-Kitamachi 4-2-1 Nukui-Kitamachi
Koganei, Tokyo 184-8795 Koganei, Tokyo 184-8795
Japan Japan
Email: asaeda@nict.go.jp Email: asaeda@nict.go.jp
Nicolai Leymann
Deutsche Telekom AG
Winterfeldtstrasse 21-27
Berlin 10781
Germany
Email: n.leymann@telekom.de
 End of changes. 54 change blocks. 
251 lines changed or deleted 264 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/