< draft-ietf-multimob-igmp-mld-tuning-00.txt   draft-ietf-multimob-igmp-mld-tuning-01.txt >
MULTIMOB Working Group H. Asaeda MULTIMOB Working Group H. Asaeda
Internet-Draft Keio University Internet-Draft Keio University
Expires: November 28, 2011 H. Liu Expires: January 12, 2012 H. Liu
Q. Wu Q. Wu
Huawei Technologies Huawei Technologies
May 27, 2011 July 11, 2011
Tuning the Behavior of IGMP and MLD for Mobile Hosts and Routers Tuning the Behavior of IGMP and MLD for Routers in Mobile and Wireless
draft-ietf-multimob-igmp-mld-tuning-00 Networks
draft-ietf-multimob-igmp-mld-tuning-01
Abstract Abstract
IGMP and MLD are the protocols used by hosts to report their IP IGMP and MLD are the protocols used by hosts and multicast routers to
multicast group memberships to neighboring multicast routers. This exchange their IP multicast group memberships with each other. This
document describes the ways of IGMPv3 and MLDv2 protocol optimization document describes the ways of IGMPv3 and MLDv2 protocol optimization
for mobility, and aims to become a guideline for query and other for mobility, and aims to become a guideline for query and other
timers tuning. timers and values tuning.
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 November 28, 2011. This Internet-Draft will expire on January 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 2, line 26 skipping to change at page 2, line 27
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Explicit Tracking of Membership Status . . . . . . . . . . . . 5 3. Explicit Tracking of Membership Status . . . . . . . . . . . . 5
4. Tuning IGMP/MLD Timers and Values . . . . . . . . . . . . . . 6 4. Tuning IGMP/MLD Timers and Values . . . . . . . . . . . . . . 6
4.1. Tuning IGMP/MLD General Query Interval . . . . . . . . . . 6 4.1. Tuning IGMP/MLD General Query Interval . . . . . . . . . . 6
4.2. Tuning IGMP/MLD Query Response Interval . . . . . . . . . 6 4.2. Tuning IGMP/MLD Query Response Interval . . . . . . . . . 7
4.3. Tuning Last Member Query Timer (LMQT) and Last 4.3. Tuning Last Member Query Timer (LMQT) and Last
Listener Query Timer (LLQT) . . . . . . . . . . . . . . . 7 Listener Query Timer (LLQT) . . . . . . . . . . . . . . . 7
4.4. Tuning Startup Query Interval . . . . . . . . . . . . . . 8 4.4. Tuning Startup Query Interval . . . . . . . . . . . . . . 8
4.5. Tuning Robustness Variable . . . . . . . . . . . . . . . . 8 4.5. Tuning Robustness Variable . . . . . . . . . . . . . . . . 8
5. Destination Address of Specific Query . . . . . . . . . . . . 9 4.6. Tuning Scenarios for Various Mobile IP Networks . . . . . 9
6. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 10 5. Destination Address of Specific Query . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
Appendix A. Unicasting General Query . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Appendix A. Unicasting General Query . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
The Internet Group Management Protocol (IGMP) [2] for IPv4 and the The Internet Group Management Protocol (IGMP) [2] for IPv4 and the
Multicast Listener Discovery Protocol (MLD) [3] for IPv6 are the Multicast Listener Discovery Protocol (MLD) [3] for IPv6 are the
standard protocols for hosts to initiate joining or leaving multicast standard protocols for hosts to initiate joining or leaving multicast
sessions. These protocols must be also supported by multicast sessions. These protocols must be also supported by multicast
routers or IGMP/MLD proxies [10] that maintain multicast membership routers or IGMP/MLD proxies [10] that maintain multicast membership
information on their downstream interfaces. Conceptually, IGMP and information on their downstream interfaces. Conceptually, IGMP and
MLD work on wireless networks. However, wireless access technologies MLD work on both wireless and mobile networks. However, wireless
operate on a shared medium or a point-to-point link with limited access technologies operate on a shared medium or a point-to-point
frequency and bandwidth. In many wireless regimes, it is desirable link with limited frequency and bandwidth. In many wireless regimes,
to minimize multicast-related signaling to preserve the limited it is desirable to minimize multicast-related signaling to preserve
resources of battery powered mobile devices and the constrained the limited resources of battery powered mobile devices and the
transmission capacities of the networks. A mobile host may cause constrained transmission capacities of the networks. A mobile host
initiation and termination of a multicast service in the new or the may cause disruption of a multicast service initiation and
previous network upon its movement. Slow multicast service termination in the new or previous network upon its movement. Slow
activation following a join may degrade reception quality. Slow multicast service activation following a join may incur additional
service termination triggered by IGMP/MLD querying or by a rapid delay in receiving multicast packets and degrade reception quality.
Slow service termination triggered by IGMP/MLD querying or by a rapid
departure of the mobile host without leaving the group in the departure of the mobile host without leaving the group in the
previous network may waste network resources. previous network may waste network resources.
When IGMP and MLD are used with mobile IP protocols, the proximity of
network entities should be considered. For example, when bi-
directional tunnel is used with the mobility entities described in
[14][11] in place, the mobile host experiences additional latency,
because the round-trip time using bi-directional tunnel between
mobility entities is larger comparing to the case that a host and an
upstream router attach to a LAN.
To create the optimal multicast membership management condition, IGMP To create the optimal multicast membership management condition, IGMP
and MLD protocols could be tuned to "ease a mobile host's processing and MLD protocols could be tuned to "ease a mobile host's processing
cost or battery power consumption by IGMP/MLD Query transmission cost or battery power consumption by IGMP/MLD Query transmission
timing coordination by routers" and "realize fast state convergence timing coordination by routers" and "realize fast state convergence
by successive monitoring whether downstream members exist or not". by successive monitoring whether downstream members exist or not".
This document describes the ways of tuning the IGMPv3 and MLDv2 This document describes the ways of tuning the IGMPv3 and MLDv2
protocol behavior for mobility, including query and other timers protocol behavior on the router side for wireless and mobile
tuning. The selective optimization that provides tangible benefits networks, including query and other timers tuning. The selective
to the mobile hosts and routers is given by keeping track of optimization that provides tangible benefits to the mobile hosts and
downstream hosts' membership status and varying IGMP/MLD Query types routers is given by keeping track of downstream hosts' membership
and values to tune the number of responses. The proposed behavior status and varying IGMP/MLD Query types and values to tune the number
interoperates with the IGMPv3 and MLDv2 protocols. of responses. The proposed behavior interoperates with the IGMPv3
and MLDv2 protocols.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 [1]. this document are to be interpreted as described in RFC 2119 [1].
3. Explicit Tracking of Membership Status 3. Explicit Tracking of Membership Status
Mobile hosts use IGMP and MLD to request to join or leave multicast Mobile hosts use IGMP and MLD to request to join or leave multicast
sessions. When the adjacent upstream routers receive the IGMP/MLD sessions. When an adjacent upstream router receives the IGMP/MLD
Report messages, they recognize the membership status on the link. Report messages, it recognizes the membership status on the link. To
To update the membership status, the routers send IGMP/MLD Query update the membership status reliably, the router sends IGMP/MLD
messages periodically as a soft-state approach does, and the member Query messages periodically, and sends Group-Specific and/or Group-
hosts reply IGMP/MLD Report messages upon reception. IGMP/MLD Query and-Source Specific Queries when a member host reports its leave.
is therefore necessary to obtain the up-to-date membership Then the other member hosts reply IGMP/MLD Report messages to notify
information, but a large number of the reply messages sent from all their memberships. IGMP/MLD Query is therefore necessary to obtain
member hosts may cause network congestion or consume network the up-to-date membership information, but a large number of the
bandwidth. reply messages sent from all member hosts may cause network
congestion or consume network bandwidth cunsumption.
The "explicit tracking function" [9] is the possible approach to The "explicit tracking function" [9] is the possible approach to
reduce the transmitted number of IGMP/MLD messages and contribute to reduce the transmitted number of IGMP/MLD messages and contribute to
mobile communications. It enables the router to keep track of the the efficiency of mobile communications. It enables the router to
membership status of the downstream IGMPv3 or MLDv2 member hosts. keep track of the membership status of the downstream IGMPv3 or MLDv2
member hosts. That is, if a router enables the explicit tracking
The explicit tracking function reduces the chance of Group-Specific function, it does not always need to ask Current-State Report message
or Group-and-Source Specific Query transmission. Whenever a router transmission from the receiver hosts since the router implicitly
that does not enable the explicit tracking function receives the recognizes the (potential) last member host when it receives the
State-Change Report and the router's membership state is changed to State-Change Report. The router can therefore send IGMP/MLD Group-
block some source or group, it sends the corresponding Group-Specific Specific and Group-and-Source Specific Queries LMQC/LLQC times (see
or Group-and-Source Specific Query messages to confirm whether the Section 4.3 for LMQC/LLQC) only when it recognizes the last member
Report sender is the last member host or not. However, if a router has left from the network. This reduces the transmitted number of
enables the explicit tracking function, it does not always need to Current-State Report messages.
ask Current-State Report message transmission to the receiver hosts
since the router recognizes the (potential) last member host when it
receives the State-Change Report. The router can therefore send
IGMP/MLD Group-Specific and Group-and-Source Specific Queries LMQC/
LLQC times (see Section 4.3 for LMQC/LLQC) only when it recognizes
the last member has left from the network. This reduces the
transmitted number of Current-State Report messages.
Enabling the explicit tracking function is advantageous for mobile Enabling the explicit tracking function is advantageous for mobile
multicast, but the function requires additional processing capability multicast, but the function requires additional processing capability
and a possibly large memory for routers to keep all membership and a possibly large memory for routers to keep all membership
status. Especially when a router needs to maintain a large number of status. Especially when a router needs to maintain a large number of
receiver hosts, this resource requirement may be potentially- receiver hosts, this resource requirement is potentially impacted.
impacted. Therefore, in this document, we propose that adjacent Therefore, in this document, we propose that adjacent upstream
upstream multicast routers SHOULD enable the explicit tracking multicast routers SHOULD enable the explicit tracking function for IP
function for IP multicast communications on wireless networks, if multicast communications on wireless networks, if they have enough
they have enough resources. If operators think that their routers do resources. If operators think that their routers do not have enough
not have enough resources, they MAY decide to disable this function resources, they MAY decide to disable this function on their routers.
on their routers. Note that whether routers enable the explicit Note that whether routers enable the explicit tracking function or
tracking function or not, they need to maintain downstream membership not, they need to maintain downstream membership status by sending
status by sending IGMPv3/MLDv2 General Query messages as some IGMPv3/ IGMPv3/MLDv2 General Query messages as some IGMPv3/MLDv2 messages may
MLDv2 messages may be lost during transmission. be lost during transmission.
4. Tuning IGMP/MLD Timers and Values 4. Tuning IGMP/MLD Timers and Values
4.1. Tuning IGMP/MLD General Query Interval 4.1. Tuning IGMP/MLD General Query Interval
IGMP and MLD are non-reliable protocols; to cover the possibility of IGMP and MLD are non-reliable protocols; to cover the possibility of
a State-Change Report being missed by one or more multicast routers, a State-Change Report being missed by one or more multicast routers,
"hosts retransmit the same State-Change Report messages [Robustness "hosts retransmit the same State-Change Report messages [Robustness
Variable] - 1 more times", at intervals chosen at random from the Variable] - 1 more times", at intervals chosen at random from the
range (0, [Unsolicited Report Interval]) [2][3]. Although this range (0, [Unsolicited Report Interval]) [2][3]. Although this
behavior increases the protocol robustness, it does not guarantee behavior increases the protocol robustness, it does not guarantee
that the State-Change Report is reached to the routers. Therefore, that the State-Change Report reaches the routers. Therefore, routers
routers still need to refresh the downstream membership information still need to refresh the downstream membership information by
by receiving Current-State Report periodically solicited by IGMP/MLD receiving Current-State Report periodically solicited by IGMP/MLD
General Query sent in the [Query Interval] period, in order to be General Query sent in the [Query Interval] period, in order to
robust in front of host or link failures and packet loss. It also enhance robustness of the host in case of link failures and packet
supports the situation that mobile hosts turn off or move from the loss. It also supports the situation that mobile hosts turn off or
wireless network to other wireless network managed by the different move from a network to other network managed by a different router
router without any notification (e.g., leave request). without any notification (e.g., leave request).
The [Query Interval] is the interval between General Queries sent by The [Query Interval] is the interval between General Queries sent by
the regular IGMPv3/MLDv2 querier, and the default value is 125 the regular IGMPv3/MLDv2 querier, and the default value is 125
seconds [2][3]. By varying the [Query Interval], multicast routers seconds [2][3]. By varying the [Query Interval], multicast routers
can tune the number of IGMP/MLD messages on the network; larger can tune the number of IGMP/MLD messages on the network; larger
values cause IGMP/MLD Queries to be sent less often. values cause IGMP/MLD Queries to be sent less often.
This document proposes 150 seconds for the [Query Interval] value by This document proposes 150 seconds for the [Query Interval] value by
changing the Querier's Query Interval Code (QQIC) field specified in changing the Querier's Query Interval Code (QQIC) field specified in
the IGMP/MLD Query message, for the case that a router enabling the the IGMP/MLD Query message, for the case that a router enabling the
skipping to change at page 6, line 49 skipping to change at page 6, line 49
On the other hand, this document also proposes 60 to 90 seconds for On the other hand, this document also proposes 60 to 90 seconds for
the [Query Interval] value for the case that a router enabling the the [Query Interval] value for the case that a router enabling the
explicit tracking function attaches to a wireless link having higher explicit tracking function attaches to a wireless link having higher
capacity of the resource. This shorter interval contributes to quick capacity of the resource. This shorter interval contributes to quick
synchronization of the membership information tracked by the router synchronization of the membership information tracked by the router
but may consume battery power of mobile hosts. but may consume battery power of mobile hosts.
If a router does not enable the explicit tracking function, the If a router does not enable the explicit tracking function, the
[Query Interval] value would be its default value, 125 seconds. [Query Interval] value would be its default value, 125 seconds.
In situations where Mobile IPv6 [14] is used, when the home agent
implements multicast router functionality and multicast data packets
are tunneled to and from the home agent, the home agent may want to
slow down Query periodicity, especially when network congestion is
detected. This can be done by the home agent starting forwarding
queries with the default [Query Interval] value and increasing it in
a gradual manner until it exceeds the mobile host's lifetime.
4.2. Tuning IGMP/MLD Query Response Interval 4.2. Tuning IGMP/MLD Query Response Interval
The [Query Response Interval] is the Max Response Time (or Max The [Query Response Interval] is the Max Response Time (or Max
Response Delay) used to calculate the Max Resp Code inserted into the Response Delay) used to calculate the Max Resp Code inserted into the
periodic General Queries. Its default value is 10 seconds expressed periodic General Queries. Its default value is 10 seconds expressed
by "Max Resp Code=100" for IGMPv3 [2] and "Maximum Response by "Max Resp Code=100" for IGMPv3 [2] and "Maximum Response
Code=10000" for MLDv2 [3]. By varying the [Query Response Interval], Code=10000" for MLDv2 [3]. By varying the [Query Response Interval],
multicast routers can tune the burstiness of IGMP/MLD messages on the multicast routers can tune the burstiness of IGMP/MLD messages on the
network; larger values make the traffic less bursty as host responses network; larger values make the traffic less bursty as host responses
are spread out over a larger interval, but will increase join latency are spread out over a larger interval, but will increase join latency
skipping to change at page 8, line 21 skipping to change at page 8, line 29
routers enabling the explicit tracking function. Although bigger routers enabling the explicit tracking function. Although bigger
LMQC and LLQC values may cause longer leave latency, the risk of LMQC and LLQC values may cause longer leave latency, the risk of
missing the last member will be reduced. missing the last member will be reduced.
4.4. Tuning Startup Query Interval 4.4. Tuning Startup Query Interval
The [Startup Query Interval] is the interval between General Queries The [Startup Query Interval] is the interval between General Queries
sent by a Querier on startup. The default value is 1/4 of [Query sent by a Querier on startup. The default value is 1/4 of [Query
Interval]; however, this document recommends the use of its shortened Interval]; however, this document recommends the use of its shortened
value such as 1 second since the shorter value would contribute to value such as 1 second since the shorter value would contribute to
smooth handover for mobile hosts using, e.g., PMIPv6 [11]. Note that shortening handover delay for mobile hosts in, e.g., the base
the [Startup Query Interval] is a static value and cannot be changed solution with PMIPv6 [12]. Note that the [Startup Query Interval] is
by any external signal. Therefore operators who maintain routers and a static value and cannot be changed by any external signal.
wireless links must properly configure this value. Therefore operators who maintain routers and wireless links must
properly configure this value.
4.5. Tuning Robustness Variable 4.5. Tuning Robustness Variable
To cover the possibility of unsolicited reports being missed by To cover the possibility of unsolicited reports being missed by
multicast routers, unsolicited reports are retransmitted [Robustness multicast routers, unsolicited reports are retransmitted [Robustness
Variable] - 1 more times, at intervals chosen at random from the Variable] - 1 more times, at intervals chosen at random from the
defined range [2][3]. The QRV (Querier's Robustness Variable) field defined range [2][3]. The QRV (Querier's Robustness Variable) field
in IGMP/MLD Query contains the [Robustness Variable] value used by in IGMP/MLD Query contains the [Robustness Variable] value used by
the querier. The default [Robustness Variable] value defined in the querier. The default [Robustness Variable] value defined in
IGMPv3 [2] and MLDv2 [3] is "2". IGMPv3 [2] and MLDv2 [3] is "2".
skipping to change at page 9, line 5 skipping to change at page 9, line 7
This document proposes "2" for the [Robustness Variable] value for This document proposes "2" for the [Robustness Variable] value for
mobility, when a router attaches to a wireless link having lower mobility, when a router attaches to a wireless link having lower
capacity of the resource or a large number of hosts. For a router capacity of the resource or a large number of hosts. For a router
that attaches to a wireless link having higher capacity of the that attaches to a wireless link having higher capacity of the
resource or reliable condition, it is not required to retransmit the resource or reliable condition, it is not required to retransmit the
same State-Change Report message; hence the router sets the same State-Change Report message; hence the router sets the
[Robustness Variable] to "1". Note that whether the explicit [Robustness Variable] to "1". Note that whether the explicit
tracking function is enabled or not, the [Robustness Variable] value tracking function is enabled or not, the [Robustness Variable] value
SHOULD NOT be bigger than "2". SHOULD NOT be bigger than "2".
4.6. Tuning Scenarios for Various Mobile IP Networks
In mobile IP networks, IGMP and MLD are used either with three
deployment scenarios; (1) running directly between host and access
router on a wireless network, (2) running between host and home
router through a tunnel link, and (3) running between home router and
foreign router through a tunnel link.
When a receiver host connects directly through a wireless link to a
foreign access router or a home router, the tuning of the IGMP/MLD
protocol parameters should be the same as suggested in the previous
sections. The example of this scenario occurs when route
optimization is adopted in MIPv6 [14] or Mobile IP [15], or when in
Proxy Mobile IPv6 (PMIPv6) [11], the mobile access gateway, whose
role is similar to the one of a foreign router, acts as a multicast
router as proposed in [13].
The second scenario occurs when bi-directional tunnel established
between host and home router is used to exchange IGMP/MLD messages
such as [14][15]. There are difficulties in tuning the parameters in
this situation, because the tunnel link condition is diverse and
changeable. When a host is far away from the home router, the
transmission delay between the two entities may be longer and the
packet delivery may be more unreliable. Thus the effects of the
IGMP/MLD message transmission through a tunnel link should be
considered during the parameter setting. For example, the [Query
Interval] and [Query Response Interval] could be set shorter to
compensate the transmission delay, and the [Robustness Variable]
could be increased for possible packet loss.
The third scenario occurs in [12], in which the mobile access gateway
(i.e., foreign router) acts as the IGMP/MLD Proxy [10] in PMIPv6
[11]. Through the bi-directional tunnel established with the local
mobility anchor (i.e., home router), the mobile access gateway sends
summary reports of its downstream member hosts to the local mobility
anchor. Apart from the distance factor that influences the parameter
setting, the [Query Response Interval] on the local mobility anchor
could be set to the smaller value since the number of foreign router
is much smaller compared to the that of the host and the chances of
packet burst is low for the same reason.
Ideally, the IGMP/MLD querier router adjusts its parameter setting
according to the actual mobile IP network conditions to benefit
service performance and resource utilization. It would be desirable
that a home router determines aforementioned timers and values
according to the delay between the initiating IGMP/MLD Query and the
responding IGMP/MLD Report, while describing such mechanism
dynamically adjusting these timers and values is out of scope of this
document.
5. Destination Address of Specific Query 5. Destination Address of Specific Query
IGMP/MLD Group-Specific and Group-and-Source Specific Queries defined IGMP/MLD Group-Specific and Group-and-Source Specific Queries defined
in [2][3] are sent to verify whether there are hosts that desire in [2][3] are sent to verify whether there are hosts that desire
reception of the specified group or a set of sources or to rebuild reception of the specified group or a set of sources or to rebuild
the desired reception state for a particular group or a set of the desired reception state for a particular group or a set of
sources. These specific Queries build and refresh multicast sources. These specific Queries build and refresh multicast
membership state of hosts on an attached network. These specific membership state of hosts on an attached network. These specific
Queries should be sent to each desired hosts with specific multicast Queries should be sent to all desired hosts with specific multicast
address (not the all-hosts/all-nodes multicast address) as their IP address (not the all-hosts/all-nodes multicast address) as their IP
destination addresses, because hosts that do not join the multicast destination addresses, because hosts that do not join the multicast
session do not pay attention to these specific Queries, and only session do not pay attention to these specific Queries, and only
active member hosts that have been receiving multicast contents with active member hosts that have been receiving multicast contents with
the specified address reply IGMP/MLD reports. the specified address reply IGMP/MLD reports.
6. Interoperability 6. Interoperability
IGMPv3 [2] and MLDv2 [3] provide the ability for hosts to report IGMPv3 [2] and MLDv2 [3] provide the ability for hosts to report
source-specific subscriptions. With IGMPv3/MLDv2, a mobile host can source-specific subscriptions. With IGMPv3/MLDv2, a mobile host can
specify a channel of interest, using multicast group and source specify a channel of interest, using multicast group and source
addresses in its join request. Upon its reception, the upstream addresses in its join request. Upon its reception, the upstream
router that supports IGMPv3/MLDv2 establishes the shortest path tree router that supports IGMPv3/MLDv2 establishes the shortest path tree
toward the source without coordinating a shared tree. This function toward the source without coordinating a shared tree. This function
is called the source filtering function and required to support is called the source filtering function and is required to support
Source-Specific Multicast (SSM) [8]. Source-Specific Multicast (SSM) [8].
Recently, the Lightweight-IGMPv3 (LW-IGMPv3) and Lightweight-MLDv2 Recently, the Lightweight-IGMPv3 (LW-IGMPv3) and Lightweight-MLDv2
(LW-MLDv2) [4] protocols have been proposed in the IETF. These (LW-MLDv2) [4] protocols have been defined as the proposed standard
protocols provide protocol simplicity for mobile hosts and routers, protocols in the IETF. These protocols provide protocol simplicity
as they eliminate a complex state machine from the full versions of for mobile hosts and routers, as they eliminate a complex state
IGMPv3 and MLDv2, and promote the opportunity to implement SSM in machine from the full versions of IGMPv3 and MLDv2, and promote the
mobile communications. opportunity to implement SSM in mobile communications.
This document assumes that both multicast routers and mobile hosts This document assumes that both multicast routers and mobile hosts
MUST be IGMPv3/MLDv2 capable, regardless whether the protocols are MUST be IGMPv3/MLDv2 capable, regardless whether the protocols are
the full or lightweight version. And this document does not consider the full or lightweight version. And this document does not consider
interoperability with older version protocols. The main reason not interoperability with older version protocols. The main reason not
being interoperate with older IGMP/MLD protocols is that the explicit being interoperable with older IGMP/MLD protocols is that the
tracking function does not work properly with older IGMP/MLD explicit tracking function does not work properly with older IGMP/MLD
protocols. protocols.
7. Security Considerations 7. Security Considerations
This document neither provides new functions or modifies the standard This document neither provides new functions or modifies the standard
functions defined in [2][3][4]. Therefore there is no additional functions defined in [2][3][4]. Therefore there is no additional
security consideration provided. security consideration provided.
8. Acknowledgements 8. Acknowledgements
Marshall Eubanks, Gorry Fairhurst, Behcet Sarikaya, Yogo Uchida, Stig Marshall Eubanks, Gorry Fairhurst, Dirk von Hugo, Imed Romdhani,
Venaas, Jinwei Xia, and others provided many constructive and Behcet Sarikaya, Yogo Uchida, Stig Venaas, Jinwei Xia, and others
insightful comments. provided many constructive and insightful comments.
9. References 9. References
9.1. Normative References 9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to indicate requirement [1] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", RFC 2119, March 1997. levels", RFC 2119, March 1997.
[2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [2] 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 [3] 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 IGMPv3 and MLDv2 [4] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet Group
Protocols", RFC 5790, February 2010. Management Protocol Version 3 (IGMPv3) and Multicast Listener
Discovery Version 2 (MLDv2) Protocols", RFC 5790,
February 2010.
[5] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, [5] Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
August 1989. August 1989.
[6] Fenner, W., "Internet Group Management Protocol, Version 2", [6] Fenner, W., "Internet Group Management Protocol, Version 2",
RFC 2236, July 1997. RFC 2236, July 1997.
[7] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener [7] 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] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", [8] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP",
RFC 4607, August 2006. RFC 4607, August 2006.
[9] Asaeda, H. and Y. Uchida, "IGMP/MLD-Based Explicit Membership [9] Asaeda, H. and Y. Uchida, "IGMP/MLD-Based Explicit Membership
Tracking Function for Multicast Routers", Tracking Function for Multicast Routers",
draft-asaeda-mboned-explicit-tracking-01.txt (work in draft-asaeda-mboned-explicit-tracking-02.txt (work in
progress), October 2010. progress), March 2011.
9.2. Informative References 9.2. Informative References
[10] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet [10] 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.
[11] Gundavelli, S, Ed., Leung, K., Devarapalli, V., Chowdhury, K., [11] Gundavelli, S, Ed., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[12] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base Deployment
for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6)
Domains", RFC 6224, April 2011.
[13] Asaeda, H., Seite, P., and J. Xia, "PMIPv6 Extensions for
Multicast", draft-asaeda-multimob-pmip6-extension-06 (work in
progress), July 2011.
[14] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[15] Perkins, Ed., C., "IP Mobility Support for IPv4, Revised",
RFC 5944, November 2010.
Appendix A. Unicasting General Query Appendix A. Unicasting General Query
IGMPv3 and MLDv2 specifications [2][3] describe that a host MUST IGMPv3 and MLDv2 specifications [2][3] describe that a host MUST
accept and process any Query whose IP Destination Address field accept and process any Query whose IP Destination Address field
contains any of the addresses (unicast or multicast) assigned to the contains any of the addresses (unicast or multicast) assigned to the
interface on which the Query arrives. In general, the all-hosts interface on which the Query arrives. In general, the all-hosts
multicast address (224.0.0.1) or link-scope all-nodes multicast multicast address (224.0.0.1) or link-scope all-nodes multicast
address (FF02::1) is used as the IP destination address of IGMP/MLD address (FF02::1) is used as the IP destination address of IGMP/MLD
General Query. On the other hand, according to [2][3], a router MAY General Query. On the other hand, according to [2][3], a router MAY
be able to unicast General Query to tracked member hosts in [Query be able to unicast General Query to tracked member hosts in [Query
skipping to change at page 15, line 33 skipping to change at page 18, line 33
Email: helen.liu@huawei.com Email: helen.liu@huawei.com
Qin Wu Qin Wu
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
Site B, Floor 12F, Huihong Mansion Site B, Floor 12F, Huihong Mansion
No.91 Baixia Rd. No.91 Baixia Rd.
Nanjing, Jiangsu 21001 Nanjing, Jiangsu 21001
China China
Email: Sunseawq@huawei.com Email: bill.wu@huawei.com
 End of changes. 27 change blocks. 
99 lines changed or deleted 180 lines changed or added

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