draft-ietf-pim-explicit-tracking-00.txt   draft-ietf-pim-explicit-tracking-01.txt 
PIM Working Group H. Asaeda PIM Working Group H. Asaeda
Internet-Draft Keio University Internet-Draft Keio University
Intended status: Informational N. Leymann Intended status: Informational N. Leymann
Expires: April 12, 2012 Deutsche Telekom AG Expires: October 12, 2012 Deutsche Telekom AG
October 10, 2011 April 10, 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-00 draft-ietf-pim-explicit-tracking-01
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 is useful for accounting and contributes to saving network
resource and fast leaves (i.e. shortened leave latency). resource and fast leaves (i.e. shortened leave latency).
Status of this Memo Status of this Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 12, 2012. This Internet-Draft will expire on October 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Explicit Tracking Function . . . . . . . . . . . . . . . . . . 4
3. Explicit Tracking Function . . . . . . . . . . . . . . . . . . 6 2.1. Reducing the Number of Specific Queries . . . . . . . . . . 4
3.1. Reducing the Number of Specific Queries . . . . . . . . . 6 2.2. Shortening Leave Latencies . . . . . . . . . . . . . . . . 5
3.2. Shortening Leave Latencies . . . . . . . . . . . . . . . . 6 2.3. Considerations . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Considerations . . . . . . . . . . . . . . . . . . . . . . 7 3. Membership State Information . . . . . . . . . . . . . . . . . 6
4. Membership State Information . . . . . . . . . . . . . . . . . 9 4. Multicast Router Behavior . . . . . . . . . . . . . . . . . . . 7
5. Multicast Router Behavior . . . . . . . . . . . . . . . . . . 10 5. Interoperability and Compatibility . . . . . . . . . . . . . . 8
6. Interoperability and Compatibility . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
The Internet Group Management Protocol (IGMP) [2] for IPv4 and the The Internet Group Management Protocol (IGMP) [1] for IPv4 and the
Multicast Listener Discovery Protocol (MLD) [3] 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 listener hosts and multicast routers.
When a host starts listening particular multicast channels, it sends When a host starts listening particular multicast channels, it sends
IGMP/MLD State-Change Report messages specifying the corresponding IGMP/MLD State-Change Report messages specifying the corresponding
channel information as the join/leave request to its upstream router channel information as the join/leave request to its upstream router
(i.e., an adjacent multicast router or IGMP/MLD proxy [8]). This (i.e., an adjacent multicast router or IGMP/MLD proxy [4]). This
"unsolicited" Report is sent only once upon reception. "unsolicited" Report is sent only once upon reception.
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 not be reached to upstream routers. To recover the
problem, the routers need to update membership information by sending problem, the routers need to update membership information by sending
IGMP/MLD General Query messages periodically. Member hosts then IGMP/MLD General Query messages periodically. Member hosts then
reply with "solicited" Report messages whenever they receive the 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 able to periodically maintain the multicast
listener (or membership) state of downstream hosts attached on the listener (or membership) state of downstream hosts attached on the
same link by getting unsolicited Report messages and synchronize the same link by getting unsolicited Report messages and synchronize 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 [2][3].) 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 the
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 would increase the
number of transmitted solicited Report messages and induce network number of transmitted solicited Report messages and induce network
congestion. And the more the network congestion is occured, the more congestion. And the more the network congestion is occured, the more
IGMP/MLD Report messages may be lost and the membership state IGMP/MLD Report messages may be lost and the membership state
information may be outdated in the router. information may be outdated in the router.
The IGMPv3 [2] and MLDv2 [3] protocols can provide the capability of The IGMPv3 [1] and MLDv2 [2] protocols can provide the capability of
keeping track of downstream (adjacent) multicast listener state to keeping track of downstream (adjacent) multicast listener state to
multicast routers. This document describes the "IGMP/MLD-based multicast routers. This document describes the "IGMP/MLD-based
explicit member tracking function" for multicast routers and details explicit member tracking function" for multicast routers and details
the way for routers to implement the function. By enabling the the way for routers to implement the function. By enabling the
explicit tracking function, routers can keep track of the downstream explicit tracking function, routers can keep track of the downstream
multicast membership state. This function implements the following multicast membership state. This function implements the following
requirements: requirements:
o Per-host accounting o Per-host accounting
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 Maintaining multicast channel characteristics (or statistics) o Maintaining multicast channel characteristics (or statistics)
where this document mainly focuses on the above second and third where this document mainly focuses on the above second and third
bullets in the following sections. bullets in the following sections.
The explicit tracking function does not change message formats used The explicit tracking function does not change message formats used
by the standard IGMPv3 [2] and MLDv2 [3], and their lightweight by the standard IGMPv3 [1] and MLDv2 [2], and their lightweight
version protocols [4]. It does not change a multicast data sender's version protocols [3]. It does not change a multicast data sender's
and receiver's behavior as well. and receiver's behavior as well.
2. Terminology 2. Explicit Tracking Function
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 [1].
3. Explicit Tracking Function
3.1. Reducing the Number of Specific Queries 2.1. Reducing the Number of Specific Queries
The explicit tracking function reduces the number of Group-Specific The explicit tracking function reduces the number of Group-Specific
or Group-and-Source Specific Query messages transmitted from a or Group-and-Source Specific Query messages transmitted from a
router, and then the number of Current-State Report messages router, and then the number of Current-State Report messages
transmitted from member hosts. As the result, network resources used transmitted from member hosts. As the result, network resources used
for IGMP/MLD query-and-reply communications between a router and for IGMP/MLD query-and-reply communications between a router and
member hosts can be saved. member hosts can be saved.
According to [2] and [3], whenever a router receives the State-Change According to [1] and [2], whenever a router receives the State-Change
Report, it sends the corresponding Group-Specific or Group-and-Source Report, it sends the corresponding Group-Specific or Group-and-Source
Specific Query messages to confirm whether the Report sender is the Specific Query messages to confirm whether the Report sender is the
last member host or not. After getting these Query messages, all last member host or not. After getting these Query messages, all
member hosts joining the corresponding channel reply with own member hosts joining the corresponding channel reply with own
Current-State Report messages. This condition requires transmitting Current-State Report messages. This condition requires transmitting
a number of Current-State Report messages and consumes network a number of Current-State Report messages and consumes network
resources especially when many hosts have been joining the same resources especially when many hosts have been joining the same
channel. channel.
On the other hand, if a router enables the explicit tracking On the other hand, if a router enables the explicit tracking
function, it does not need to always ask Current-State Report message function, it does not need to always ask Current-State Report message
transmission to the member hosts whenever it receives the State- transmission to the member hosts whenever it receives the State-
Change Report. This is because the explicit tracking function works Change Report. This is because the explicit tracking function works
with the expectation that the State-Change Report sender is the last with the expectation that the State-Change Report sender is the last
remaining member of the channel. Even if this expectation is wrong remaining member of the channel. Even if this expectation is wrong
(i.e., the State-Change Report sender was not the sole member), other (i.e., the State-Change Report sender was not the sole member), other
members remaining in the same channel will reply with identical members remaining in the same channel will reply with identical
Report messages, so the end result is the same and no problem occurs. Report messages, so the end result is the same and no problem occurs.
(Section 4 details the point.) (Section 3 details the point.)
In addition, the processing of IGMP membership or MLD listener In addition, the processing of IGMP membership or MLD listener
reports consumes CPU ressources on the IGMP/MLD querier devices reports consumes CPU ressources on the IGMP/MLD querier devices
itself. Therefore, the explicit tracking function reduces not only itself. Therefore, the explicit tracking function reduces not only
the network load but also the CPU load on the querier devices as the network load but also the CPU load on the querier devices as
well. well.
3.2. Shortening Leave Latencies snooping switch [5]. If the timer to refresh membership record on
snooping switch is shorter than the General Query timer interval
(i.e. [Query Interval]),
2.2. Shortening Leave Latencies
The explicit tracking function works with the expectation that the The explicit tracking function works with the expectation that the
State-Change Report sender is the last remaining member of the State-Change Report sender is the last remaining member of the
channel. Thanks to this functionality, a router can tune timers and channel. Thanks to this functionality, a router can tune timers and
values related to decide that the State-Change Report sender was the values related to decide that the State-Change Report sender was the
sole 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 values for LMQI/LLQI defined in the standard
specifications [2][3] are 1 second. For the router enabling the specifications [1][2] are 1 second. For the router enabling the
explicit tracking function, LMQI/LLQI would be set to 1 second or explicit tracking function, LMQI/LLQI would be set to 1 second or
shorter. The LMQC/LLQC may be set to "1" for the router, whereas shorter. The LMQC/LLQC may be set to "1" for the router, whereas
their default values are the [Robustness Variable] value whose their default values are the [Robustness Variable] value whose
default value is "2". Smaller LMQC/LLQC give smaller LMQT/LLQT; this default value is "2". Smaller LMQC/LLQC give smaller LMQT/LLQT; this
condition shortens the leave latencies. condition shortens the leave latencies.
3.3. Considerations 2.3. Considerations
As with the basic concepts of IGMP and MLD, the explicit tracking As with the basic concepts of IGMP and MLD, the explicit tracking
function does not guarantee the membership state is always perfectly function does not guarantee the membership state is always perfectly
synchronized; routers enabling the explicit tracking function still synchronized; routers enabling the explicit tracking function still
need to send IGMPv3/MLDv2 Query messages and inquire solicited need to send IGMPv3/MLDv2 Query messages and inquire solicited
IGMPv3/MLDv2 Report messages from downstream members to maintain IGMPv3/MLDv2 Report messages from downstream members to maintain
downstream membership state. downstream membership state.
o IGMP/MLD messages are non-reliable and may be lost in the o IGMP/MLD messages are non-reliable and may be lost in the
transmission, therefore routers need to confirm the membership by transmission, therefore routers need to confirm the membership by
sending Query messages. sending Query messages.
o To preserve compatibility with older versions of IGMP/MLD, routers o To preserve compatibility with older versions of IGMP/MLD, routers
need to support downstream hosts that are not upgraded to the need to support downstream hosts that are not upgraded to the
latest versions of IGMP/MLD and run the report suppression latest versions of IGMP/MLD and run the report suppression
mechanism. mechanism.
o It is impossible to identify hosts when hosts send IGMP reports o It is impossible to identify hosts when hosts send IGMP reports
with a source address of 0.0.0.0. with a source address of 0.0.0.0.
Regarding the last bullet, the IGMPv3 specification [2] mentions that Regarding the last bullet, the IGMPv3 specification [1] mentions that
an IGMPv3 Report is usually sent with a valid IP source address, 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 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 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 routers MUST accept a report with a source address of 0.0.0.0. The
MLDv2 specification [3] mentions that an MLDv2 Report MUST be sent MLDv2 specification [2] mentions that an MLDv2 Report MUST be sent
with a valid IPv6 link-local source address, although an MLDv2 Report with a valid IPv6 link-local source address, although an MLDv2 Report
can be sent with the unspecified address (::), if the sending can be sent with the unspecified address (::), if the sending
interface has not acquired a valid link-local address yet. [3] also interface has not acquired a valid link-local address yet. [2] also
mentions that routers silently discard a message that is not sent mentions that routers silently discard a message that is not sent
with a valid link-local address or sent with the unspecified address, with a valid link-local address or sent with the unspecified address,
without taking any action, because of the security consideration. without taking any action, because of the security consideration.
Another concern is that the explicit tracking function requires Another concern is that the explicit tracking function requires
additional processing capability and a possibly large memory for additional processing capability and a possibly large memory for
routers to keep all membership states. Especially when a router routers to keep all membership states. Especially when a router
needs to maintain a large number of member hosts, this resource needs to maintain a large number of member hosts, this resource
requirement may be potentially-impacted. Operators may decide to requirement may be potentially-impacted. Operators may decide to
disable this function when their routers do not have enough memory disable this function when their routers do not have enough memory
resources. resources.
4. Membership State Information 3. Membership State Information
The explicit tracking function is implemented with the following The explicit tracking function is implemented with the following
membership state information: membership state information:
(S, G, number of receivers, (receiver records)) (S, G, number of receivers, (receiver records))
where each receiver record is of the form: where each receiver record is of the form:
(IGMP/MLD Membership/Listener Report sender's address) (IGMP/MLD Membership/Listener Report sender's address)
skipping to change at page 10, line 5 skipping to change at page 7, line 8
implementation, the explicit tracking function does not keep the implementation, the explicit tracking function does not keep the
state of (S,G) join with EXCLUDE filter mode. If a router receives state of (S,G) join with EXCLUDE filter mode. If a router receives
(S,G) join/leave request with EXCLUDE filter mode from the downstream (S,G) join/leave request with EXCLUDE filter mode from the downstream
hosts, it translates the join/leave request to (*,G) join state/leave hosts, it translates the join/leave request to (*,G) join state/leave
requst and records the state and the receivers' addresses into the requst and records the state and the receivers' addresses into the
maintained membership state information. Note that this membership maintained membership state information. Note that this membership
state translation does not change the routing protocol behavior; the state translation does not change the routing protocol behavior; the
routing protocol must deal with the original join/leave request and routing protocol must deal with the original join/leave request and
translate the request only for the membership state information. translate the request only for the membership state information.
5. Multicast Router Behavior 4. Multicast Router Behavior
The explicit tracking function makes routers expect whether the The explicit tracking function makes routers expect whether the
State-Change Report sender is the last remaining member of the State-Change Report sender is the last remaining member of the
channel. Therefore the router transmits a corresponding Current- channel. Therefore the router transmits a corresponding Current-
State Report message only when the router thinks that the State- State Report message only when the router thinks that the State-
Change Report sender is the last remaining member of the channel. Change Report sender is the last remaining member of the channel.
This contributes to saving the network resources and also shortening This contributes to saving the network resources and also shortening
leave latency. leave latency.
To synchronize the membership state information, when a multicast To synchronize the membership state information, when a multicast
skipping to change at page 10, line 27 skipping to change at page 7, line 30
adds the receiver IP address to or delete from the receiver records adds the receiver IP address to or delete from the receiver records
or creates the corresponding membership state information. If there or creates the corresponding membership state information. If there
are no more receiver records left, the membership state information are no more receiver records left, the membership state information
is deleted from the router. is deleted from the router.
However, the membership state information may be still outdated in However, the membership state information may be still outdated in
the router. It may be happened especially in a mobile multicast the router. It may be happened especially in a mobile multicast
environment that some member hosts have joined to or left from the environment that some member hosts have joined to or left from the
network without sending State-Change Report messages. Or, some network without sending State-Change Report messages. Or, some
State-Change Report messages are lost due to network congestion. State-Change Report messages are lost due to network congestion.
Therefore, the router enabling the explicit tracking function MUST Therefore, the router enabling the explicit tracking function ought
send the periodic General Query regularly. to send the periodic General Query regularly.
Regarding the leave latency, as specified in Section 3.2, the Regarding the leave latency, as specified in Section 2.2, the
explicit tracking function contributes to the fast leave by setting explicit tracking function contributes to the fast leave by setting
LMQI/LLQI to "1" second or shorter and LMQC/LLQC to "1". However, if LMQI/LLQI to "1" second or shorter and LMQC/LLQC to "1". However, if
LMQC/LLQC is configured "2" or bigger value, then the router's LMQC/LLQC is configured "2" or bigger value, then the router's
behavior MAY be changed from the standard specification. According behavior may be changed from the standard specification. According
to [2] and [3], a router sends a Group- (and-Source) Specific Query to [1] and [2], a router sends a Group- (and-Source) Specific Query
[LMQC - 1] or [LLQC - 1] times when it receives State Change Report [LMQC - 1] or [LLQC - 1] times when it receives State Change Report
message (e.g. leave request) from a member host, in order to confirm message (e.g. leave request) from a member host, in order to confirm
whether or not the host is the only remaining member. However, this whether or not the host is the only remaining member. However, this
document RECOMMENDS that if the router enabling the explicit tracking document RECOMMENDS that if the router enabling the explicit tracking
function receives the corresponding Current State Report before the function receives the corresponding Current State Report before the
Specific Query retransmission, it cancels sending the same Specific Specific Query retransmission, it cancels sending the same Specific
Query for other [LMQC - 1] or [LLQC - 1] times. Query for other [LMQC - 1] or [LLQC - 1] times.
Note that there is some risk that a router misses or looses Report Note that there is some risk that a router misses or looses Report
messages sent from remaining members if the router adopts small LMQC/ messages sent from remaining members if the router adopts small LMQC/
LLQC; however the wrong expectation would be lower happened for the LLQC; however the wrong expectation would be lower happened for the
router enabling the explicit tracking function. And to avoid the router enabling the explicit tracking function. And to avoid the
problem, a router can start sending a Group- (and-Source) Specific problem, a router can start sending a Group- (and-Source) Specific
Query message when it expects the number of the remaining members is Query message when it expects the number of the remaining members is
small, such as 5, but not 0. small, such as 5, but not 0.
6. Interoperability and Compatibility 5. Interoperability and Compatibility
The explicit tracking function does not work with the older versions The explicit tracking function does not work with the older versions
of IGMP or MLD, IGMPv1 [5], IGMPv2 [6] or MLDv1 [7], because a member of 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 adopts a report suppression mechanism by
which a host would cancel sending a pending membership Reports if a which a host would cancel sending a pending membership Reports if a
similar Report was observed from another member on the network. similar Report was observed from another member on the network.
If a multicast router enabling the explicit tracking function changes If a multicast router enabling the explicit tracking function changes
its compatibility mode to the older versions of IGMP or MLD, the its compatibility mode to the older versions of IGMP or MLD, the
router should turn off the explicit tracking function but should not router should turn off the explicit tracking function but should not
flush the maintained membership state information (i.e., keep the flush the maintained membership state information (i.e., keep the
current membership state information as is). When the router changes current membership state information as is). When the router changes
back to IGMPv3 or MLDv2 mode, it would resume the function with the back to IGMPv3 or MLDv2 mode, it would resume the function with the
skipping to change at page 12, line 5 skipping to change at page 8, line 37
There are several points TBD in the further discussions regarding the There are several points TBD in the further discussions regarding the
interoperability and compatibility issues. At first, it is necessary interoperability and compatibility issues. At first, it is necessary
whether a multicast router enabling the explicit tracking function whether a multicast router enabling the explicit tracking function
needs to detect adjacent routers that do not support the explicit needs to detect adjacent routers that do not support the explicit
tracking function on the link or not. After the clarification, this tracking function on the link or not. After the clarification, this
document will describe the method how to detect them. It would be document will describe the method how to detect them. It would be
done by a new signaling message, but the new message leads done by a new signaling message, but the new message leads
compatibility problems for older routers or other routing protocols compatibility problems for older routers or other routing protocols
such as PIM-DM. All of these discussions are TBD. such as PIM-DM. All of these discussions are TBD.
7. Security Considerations 6. Security Considerations
There is no additional security considerations. There is no additional security considerations.
8. Acknowledgements 7. Acknowledgements
Toerless Eckert, Stig Venaas, and others provided many constructive Toerless Eckert, Stig Venaas, and others provided many constructive
and insightful comments. and insightful comments.
9. References 8. References
8.1. Normative References
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", RFC 2119, March 1997.
[2] 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.
[3] 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.
[4] 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 8.2. Informative References
[5] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, [4] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet
Group Management Protocol (IGMP) / Multicast Listener Discovery
(MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")",
RFC 4605, August 2006.
[5] Christensen, M., Kimball, K., and F. Solensky, "Considerations
for Internet Group Management Protocol (IGMP) and Multicast
Listener Discovery (MLD) Snooping Switches", RFC 4541, May 2006.
[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.
[8] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet
Group Management Protocol (IGMP) / Multicast Listener Discovery
(MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")",
RFC 4605, August 2006.
Authors' Addresses Authors' Addresses
Hitoshi Asaeda Hitoshi Asaeda
Keio University Keio University
Graduate School of Media and Governance Graduate School of Media and Governance
5322 Endo 5322 Endo
Fujisawa, Kanagawa 252-0882 Fujisawa, Kanagawa 252-0882
Japan Japan
Email: asaeda@wide.ad.jp Email: asaeda@wide.ad.jp
 End of changes. 39 change blocks. 
84 lines changed or deleted 69 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/