One document matched: draft-ietf-multimob-igmp-mld-tuning-05.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<!--<?rfc strict="yes" ?>-->
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="no"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-ietf-multimob-igmp-mld-tuning-05"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)"
RFC3978 -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Tuning the Behavior of IGMP and MLD">Tuning the Behavior of
IGMP and MLD for Routers in Mobile and Wireless Networks</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Hitoshi Asaeda" initials="H" surname="Asaeda">
<organization>Keio University</organization>
<address>
<postal>
<street>Graduate School of Media and Governance</street>
<street>5322 Endo</street>
<city>Fujisawa</city>
<region>Kanagawa</region>
<code>252-0882</code>
<country>Japan</country>
</postal>
<email>asaeda@wide.ad.jp</email>
<uri>http://www.sfc.wide.ad.jp/~asaeda/</uri>
</address>
</author>
<author fullname="Hui Liu" initials="H" surname="Liu">
<organization abbrev="Huawei">Huawei Technologies Co.,
Ltd.</organization>
<address>
<postal>
<street>Huawei Bld., No.3 Xinxi Rd.</street>
<street>Shang-Di Information Industry Base</street>
<city>Hai-Dian Distinct</city>
<region>Beijing</region>
<code>100085</code>
<country>China</country>
</postal>
<email>helen.liu@huawei.com</email>
</address>
</author>
<author fullname="Qin Wu" initials="Q" surname="Wu">
<organization abbrev="Huawei">Huawei Technologies Co.,
Ltd.</organization>
<address>
<postal>
<street>Site B, Floor 12F, Huihong Mansion</street>
<street>No.91 Baixia Rd.</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>21001</code>
<country>China</country>
</postal>
<email>bill.wu@huawei.com</email>
</address>
</author>
<date year="2012" />
<area>Internet</area>
<workgroup>MULTIMOB Working Group</workgroup>
<abstract>
<t>IGMP and MLD are the protocols used by hosts and multicast routers to
exchange their IP multicast group memberships with each other. This
document describes the ways of IGMPv3 and MLDv2 protocol optimization
for mobility, and aims to become a guideline for tuning of IGMPv3/MLDv2
Queries and timer and counter values.</t>
</abstract>
</front>
<middle>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<section anchor="sec.intro" title="Introduction">
<t>The Internet Group Management Protocol <xref
target="refs.IGMPv3">(IGMP)</xref> for IPv4 and the Multicast Listener
Discovery Protocol <xref target="refs.MLDv2">(MLD)</xref> for IPv6 are
the standard protocols for hosts to initiate joining or leaving of
multicast sessions. These protocols must be also supported by multicast
routers or <xref target="refs.Proxy">IGMP/MLD proxies</xref> that
maintain multicast membership information on their downstream
interfaces. Conceptually, IGMP and MLD work on both wireless and mobile
networks. However, wireless access technologies operate on a shared
medium or a point-to-point link with limited spectrum and bandwidth. In
many wireless regimes, it is desirable to minimize multicast-related
signaling to preserve the limited resources of battery powered mobile
devices and the constrained transmission capacities of the networks. The
motion of a host may cause disruption of a multicast service initiation
and termination in the new or previous network upon its movement. Slow
multicast service activation following a join may incur additional delay
in receiving multicast packets and degrade reception quality. Slow
service termination triggered by a rapid departure of the mobile host
without leaving the group in the previous network may waste network
resources.</t>
<t>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 <xref
target="refs.PMIPv6"></xref><xref target="refs.MIPv6"></xref>, 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.</t>
<t>This document describes the ways of tuning the IGMPv3 and MLDv2
protocol behavior on multicast router and proxy side for wireless and
mobile networks, including query and related timers tuning. The
selective optimization that provides tangible benefits to the mobile
hosts and routers is given by keeping track of downstream hosts'
membership status and varying IGMP/MLD Query types and values to tune
the number of responses. The proposed behavior interoperates with the
IGMPv3 and MLDv2 protocols.</t>
</section>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<section title="Terminology">
<t>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 <xref
target="refs.KEYWORDS">RFC 2119</xref>.</t>
<t>In this document, "router" means both multicast router and IGMP/MLD
proxy.</t>
</section>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<section anchor="sec.track" title="Explicit Tracking of Membership Status">
<t>Mobile hosts use IGMP and MLD to request to join or leave multicast
sessions. When an adjacent upstream router receives the IGMP/MLD Report
messages, it recognizes the membership status on the link. To update the
membership status reliably, the router sends IGMP/MLD Query messages
periodically, and sends Group-Specific and/or Group-and-Source Specific
Queries when a member host reports its leave. IGMP/MLD Query is
therefore necessary to obtain the up-to-date membership information, but
a large number of the reply messages sent from all member hosts MAY
cause network congestion or consume network bandwidth.</t>
<t>The "explicit tracking function" <xref target="refs.explicit"></xref>
is the possible approach to reduce the transmitted number of IGMP/MLD
messages and contribute to the efficiency of mobile communications. It
enables the router to keep track of the membership status of the
downstream IGMPv3 or MLDv2 member hosts. That is, if a router enables
the explicit tracking function, it does not always need to ask
Current-State Report message's transmission from the receiver hosts
since the router implicitly recognizes the (potential) last member host
when it receives the State-Change Report reporting a leave. The router
can therefore send IGMP/MLD Group-Specific and Group-and-Source Specific
Queries LMQC/LLQC times (see <xref target="sec.llqt"></xref> 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.</t>
<t>Enabling the explicit tracking function is advantageous for mobile
multicast, but the function requires additional processing capability
and possibly a large memory for routers to keep all membership status.
Especially when a router needs to maintain a large number of receiver
hosts, this resource requirement is potentially impacted. Therefore, in
this document it is recommended that adjacent upstream multicast routers
enable the explicit tracking function for IP multicast communications on
wireless and mobile networks, if they have enough resources. If
operators think that their routers do not have enough resources, they
MAY disable this function on their routers. Note that whether routers
enable the explicit tracking function or not, they need to maintain
downstream membership status by sending IGMPv3/MLDv2 General Query
messages as some IGMPv3/MLDv2 messages MAY be lost during
transmission.</t>
</section>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<section anchor="sec.query" title="Tuning IGMP/MLD Timers and Values">
<!-- ============================================================ -->
<section anchor="sec.genquery"
title="Tuning IGMP/MLD General Query Interval">
<t>IGMP and MLD are non-reliable protocols; to cover the possibility
of a State-Change Report being missed by one or more multicast
routers, "hosts retransmit the same State-Change Report messages
[Robustness Variable] - 1 more times", at intervals chosen at random
from the range (0, [Unsolicited Report Interval]) <xref
target="refs.IGMPv3"></xref><xref target="refs.MLDv2"></xref>.
Although this behavior increases the protocol robustness, it does not
guarantee that the State-Change Report reaches the routers. Therefore,
routers still need to refresh the downstream membership information by
receiving Current-State Report periodically solicited by IGMP/MLD
General Query sent in the [Query Interval] period, in order to enhance
robustness of the host in case of link failures and packet loss. It
also supports the situation that mobile hosts turn off or move from a
network to other network managed by a different router without any
notification (e.g., leave request).</t>
<t>The [Query Interval] is the interval between General Queries sent
by the regular IGMPv3/MLDv2 querier, and the default value is 125
seconds <xref target="refs.IGMPv3"></xref><xref
target="refs.MLDv2"></xref>. By varying the [Query Interval],
multicast routers can tune the number of IGMP/MLD messages on the
network; larger values cause IGMP/MLD Queries to be sent less
often.</t>
<t>This document proposes 150 seconds for the [Query Interval] value
by changing the Querier's Query Interval Code (QQIC) field specified
in the IGMP/MLD Query message, for the case that a router enabling the
explicit tracking function potentially
operates a large number of member hosts such as more than 200 hosts on
the wireless link. This longer interval value contributes to
minimizing traffic of Report messages and battery power consumption
for mobile hosts.</t>
<t>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
explicit tracking function attaches to a wireless link with higher
capacity. This shorter interval contributes to quick
synchronization of the membership information tracked by the router
but MAY consume battery power of mobile hosts.</t>
<t>If a router does not enable the explicit tracking function, the
[Query Interval] value would be its default value, 125 seconds.</t>
<t>In situations where <xref target="refs.MIPv6">Mobile IPv6</xref> 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. It happens, for example, when the home agent detects network congestion. In this case, the home agent starts forwarding queries with the default [Query Interval] value and increases the value in a gradual manner.</t>
</section>
<!-- ============================================================ -->
<section anchor="sec.queryresp"
title="Tuning IGMP/MLD Query Response Interval">
<t>The [Query Response Interval] is the Max Response Time (or Max
Response Delay) used to calculate the Max Resp Code inserted into the
periodic General Queries. Its default value is 10 seconds expressed by
"Max Resp Code=100" for IGMPv3 <xref target="refs.IGMPv3"></xref> and
"Maximum Response Code=10000" for MLDv2 <xref
target="refs.MLDv2"></xref>. By varying the [Query Response Interval],
multicast routers can tune the burstiness of IGMP/MLD messages on the
network; larger values make the traffic less bursty as host's
responses are spread out over a larger interval, but will increase
join latency when State-Change Report (i.e., join request) is
missing.</t>
<t>According to our experimental analysis, this document proposes two
tuning scenarios for tuning the [Query Response Interval] value in
different wireless link conditions; one scenario is for a wireless
link with a lower capacity of network resource or a lossy link, and
the other scenario is for a wireless link with enough capacity or
reliable condition for IGMP/MLD message transmission.</t>
<t>Regarding the first scenario, for instance, when a multicast router
attaches to a bursty IEEE 802.11b link, the router configures the
longer [Query Response Interval] value, such as 10 to 20 (sec). This
configuration will reduce congestion of the Current-State Report
messages on a link but MAY increase join latency and leave latency
when the unsolicited messages (State-Change Record) are lost on the
router.</t>
<t>The second scenario MAY happen for a multicast router attaching to
a wireless link having higher capacity of the resource or a
point-to-(multi-)point link such as an IEEE 802.16e link, because
IGMP/MLD messages do not seriously affect the link condition. The
router can seek Current-State Report messages with the shorter [Query
Response Interval] value, such as 5 to 10 (sec). This configuration
will contribute to quickly (at some level) discovering non-tracked
member hosts and synchronizing the membership information.</t>
</section>
<!-- ============================================================ -->
<section anchor="sec.llqt"
title="Tuning Last Member Query Timer (LMQT) and Last Listener Query Timer (LLQT)">
<t>Shortening the Last Member Query Timer (LMQT) for IGMPv3 and the
Last Listener Query Timer (LLQT) for MLDv2 contributes to minimizing
leave latency. LMQT is represented by the Last Member Query Interval
(LMQI), multiplied by the Last Member Query Count (LMQC), and LLQT is
represented by the Last Listener Query Interval (LLQI), multiplied by
the Last Listener Query Count (LLQC).</t>
<t>While LMQI and LLQI are changeable, it is reasonable to use the
default values (i.e., 1 second) for LMQI and LLQI in a wireless
network. LMQC and LLQC, whose default value is the [Robustness
Variable] value, are also tunable. Therefore, LMQC and LLQC MAY be set
to "1" for routers enabling the explicit tracking function, and then
LMQT and LLQT are set to 1 second. However, setting LMQC and LLQC to 1
increases the risk of missing the last member; LMQC and LLQC SHOULD be
set to 1 only when network operators think that their wireless link is
stable enough.</t>
<!-- XXX by Clair: whose values defer by the [Robustness Variable] value -->
<t>On the other hand, if network operators think that their wireless
link is lossy (e.g., due to a large number of attached hosts or
limited resources), they MAY set LMQC and LLQC to "2" for their
routers enabling the explicit tracking function. Although bigger LMQC
and LLQC values MAY cause longer leave latency, the risk of missing
the last member will be reduced.</t>
</section>
<!-- ============================================================ -->
<section anchor="sec.startup" title="Tuning Startup Query Interval">
<t>The [Startup Query Interval] is the interval between General
Queries sent by a Querier on startup. The default value is 1/4 of
[Query Interval]; however, in this document it is RECOMMENDED that the
use of its shortened value such as 1 second since the shorter value
would contribute to shortening handover delay for mobile hosts in,
e.g., the base solution with PMIPv6 <xref target="refs.base"></xref>.
Note that the [Startup Query Interval] is a static value and cannot be
changed by any external signal. Therefore operators who maintain
routers and wireless links MUST properly configure this value.</t>
</section>
<!-- ============================================================ -->
<section anchor="sec.robvar" title="Tuning Robustness Variable">
<t>To cover the possibility of unsolicited reports being missed by
multicast routers, unsolicited reports are retransmitted [Robustness
Variable] - 1 more times, at intervals chosen at random from the
defined range <xref target="refs.IGMPv3"></xref><xref
target="refs.MLDv2"></xref>. The QRV (Querier's Robustness Variable)
field in IGMP/MLD Query contains the [Robustness Variable] value used
by the querier. The default [Robustness Variable] value defined in
<xref target="refs.IGMPv3">IGMPv3</xref> and <xref
target="refs.MLDv2">MLDv2</xref> is "2".</t>
<t>This document proposes "2" for the [Robustness Variable] value for
mobility, when a router attaches to a wireless link having lower
capacity of the resource or a large number of hosts. For a router that
attaches to a wireless link having higher capacity or is known to be
reliable, it is not required to retransmit the same
State-Change Report message; hence the router sets the [Robustness
Variable] to "1".</t>
</section>
<!-- ============================================================ -->
<section anchor="sec.mobility"
title="Tuning Scenarios for Various Mobile IP Networks">
<t>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.</t>
<t>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 in <xref target="refs.PMIPv6">Proxy Mobile IPv6 (PMIPv6)</xref>, the mobile access gateway, whose
role is similar to a foreign router, acts as a multicast router or proxy.</t>
<t>The second scenario occurs when bi-directional tunnel established
between host and home router is used to exchange IGMP/MLD messages
such as in <xref target="refs.MIPv6"></xref><xref
target="refs.MIP"></xref>. 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.</t>
<t>The third scenario occurs in <xref target="refs.base"></xref>, in
which the mobile access gateway (i.e., foreign router) acts as the
IGMP/MLD Proxy <xref target="refs.Proxy"></xref> in PMIPv6 <xref
target="refs.PMIPv6"></xref>. 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 a smaller value because
the number of the mobile access gateways is much smaller compared to
that of the host and the chances of packet burst is low for the same
reason. And the power consumption due to a lower query interval is not
an issue for the moble access gateways because the mobile access
gateways are usually not battery-powered.</t>
<t>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.</t>
</section>
</section>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<section anchor="sec.specificquery"
title="Destination Address of Specific Query">
<t>IGMP/MLD Group-Specific and Group-and-Source Specific Queries defined
in <xref target="refs.IGMPv3"></xref><xref target="refs.MLDv2"></xref>
are sent to verify whether there are hosts that desire 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 sources. These specific Queries
build and refresh multicast membership state of hosts on an attached
network. These specific Queries SHOULD be sent to all desired hosts with
specific multicast address (not the all-hosts/all-nodes multicast
address) as their IP destination addresses, because hosts that do not
join the multicast session do not pay attention to these specific
Queries, and only active member hosts that have been receiving multicast
contents with the specified address reply IGMP/MLD reports.</t>
</section>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<section anchor="sec.interop" title="Interoperability">
<t>IGMPv3 <xref target="refs.IGMPv3"></xref> and MLDv2 <xref
target="refs.MLDv2"></xref> provide the ability for hosts to report
source-specific subscriptions. With IGMPv3/MLDv2, a mobile host can
specify a channel of interest, using multicast group and source
addresses in its join request. Upon its reception, the upstream router
that supports IGMPv3/MLDv2 establishes the shortest path tree toward the
source without coordinating a shared tree. This function is called the
source filtering function and is required to support <xref
target="refs.SSM">Source-Specific Multicast (SSM)</xref>.</t>
<t>Recently, the Lightweight-IGMPv3 (LW-IGMPv3) and Lightweight-MLDv2
(LW-MLDv2) <xref target="refs.LW"></xref> protocols have been defined as
the proposed standard protocols in the IETF. These protocols provide
protocol simplicity for mobile hosts and routers, as they eliminate a
complex state machine from the full versions of IGMPv3 and MLDv2, and
promote the opportunity to implement SSM in mobile communications.</t>
<t>This document assumes that both multicast routers and mobile hosts
MUST be IGMPv3/MLDv2 capable, regardless whether the protocols are the
full or lightweight version. And this document does not consider
interoperability with older version protocols. One of the reasons not being
interoperable with older IGMP/MLD protocols is that the explicit
tracking function does not work properly with older IGMP/MLD
protocols because of a report suppression mechanism; a host would not send a pending IGMP/MLD report if a similar report was sent by another listener on the link.</t>
</section>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<section title="IANA Considerations">
<t>This document has no actions for IANA.</t>
</section>
<section title="Security Considerations">
<t>This document neither provides new functions or modifies the standard
functions defined in <xref target="refs.IGMPv3"></xref><xref
target="refs.MLDv2"></xref><xref target="refs.LW"></xref>. Therefore
there is no additional security consideration provided.</t>
</section>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<section title="Acknowledgements">
<t>Luis M. Contreras, Marshall Eubanks, Gorry Fairhurst, Dirk von Hugo,
Imed Romdhani, Behcet Sarikaya, Stig Venaas, Jinwei Xia, and others
provided many constructive and insightful comments.</t>
</section>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
</middle>
<back>
<references title="Normative References">
<reference anchor="refs.KEYWORDS">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997" />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to
signify the requirements in the specification. These words are
often capitalized. This document defines these words as they
should be interpreted in IETF documents. Authors who follow these
guidelines should incorporate this phrase near the beginning of
their document: <list>
<t>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.</t>
</list></t>
<t>Note that the force of these words is modified by the
requirement level of the document in which they are used.</t>
</abstract>
</front>
</reference>
<reference anchor="refs.IGMPv3">
<front>
<title>Internet Group Management Protocol, Version 3</title>
<author initials="B" surname="Cain"></author>
<author initials="S" surname="Deering"></author>
<author initials="I" surname="Kouvelas"></author>
<author initials="B" surname="Fenner"></author>
<author initials="A" surname="Thyagarajan"></author>
<date month="October" year="2002" />
</front>
<seriesInfo name="RFC" value="3376" />
</reference>
<reference anchor="refs.MLDv2">
<front>
<title>Multicast Listener Discovery Version 2 (MLDv2) for
IPv6</title>
<author initials="R" surname="Vida"></author>
<author initials="L" surname="Costa"></author>
<date month="June" year="2004" />
</front>
<seriesInfo name="RFC" value="3810" />
</reference>
<reference anchor="refs.LW">
<front>
<title>Lightweight Internet Group Management Protocol Version 3
(IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2)
Protocols</title>
<author initials="H" surname="Liu"></author>
<author initials="W" surname="Cao"></author>
<author initials="H" surname="Asaeda"></author>
<date month="February" year="2010" />
</front>
<seriesInfo name="RFC" value="5790" />
</reference>
<reference anchor="refs.SSM">
<front>
<title>Source-Specific Multicast for IP</title>
<author initials="H" surname="Holbrook"></author>
<author initials="B" surname="Cain"></author>
<date month="August" year="2006" />
</front>
<seriesInfo name="RFC" value="4607" />
</reference>
</references>
<references title="Informative References">
<reference anchor="refs.explicit">
<front>
<title>IGMP/MLD-Based Explicit Membership Tracking Function for
Multicast Routers</title>
<author initials="H" surname="Asaeda"></author>
<author initials="N" surname="Leymann"></author>
<date month="October" year="2011" />
</front>
<seriesInfo name="draft-ietf-pim-explicit-tracking-00.txt"
value="(work in progress)" />
</reference>
<reference anchor="refs.Proxy">
<front>
<title>Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD
Proxying")</title>
<author initials="B" surname="Fenner"></author>
<author initials="H" surname="He"></author>
<author initials="B" surname="Haberman"></author>
<author initials="H" surname="Sandick"></author>
<date month="August" year="2006" />
</front>
<seriesInfo name="RFC" value="4605" />
</reference>
<reference anchor="refs.PMIPv6">
<front>
<title>Proxy Mobile IPv6</title>
<author initials="S, Ed." surname="Gundavelli"></author>
<author initials="K" surname="Leung"></author>
<author initials="V" surname="Devarapalli"></author>
<author initials="K" surname="Chowdhury"></author>
<author initials="B" surname="Patil"></author>
<date month="August" year="2008" />
</front>
<seriesInfo name="RFC" value="5213" />
</reference>
<reference anchor="refs.base">
<front>
<title>Base Deployment for Multicast Listener Support in Proxy
Mobile IPv6 (PMIPv6) Domains</title>
<author initials="T" surname="Schmidt"></author>
<author initials="M" surname="Waehlisch"></author>
<author initials="S" surname="Krishnan"></author>
<date month="April" year="2011" />
</front>
<seriesInfo name="RFC" value="6224" />
</reference>
<reference anchor="refs.MIPv6">
<front>
<title>Mobility Support in IPv6</title>
<author initials="D" surname="Johnson"></author>
<author initials="C" surname="Perkins"></author>
<author initials="J" surname="Arkko"></author>
<date month="July" year="2011" />
</front>
<seriesInfo name="RFC" value="6275" />
</reference>
<reference anchor="refs.MIP">
<front>
<title>IP Mobility Support for IPv4, Revised</title>
<author initials="C" surname="Perkins, Ed."></author>
<date month="November" year="2010" />
</front>
<seriesInfo name="RFC" value="5944" />
</reference>
</references>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<section anchor="sec.uniquery" title="Unicasting General Query">
<t>IGMPv3 and MLDv2 specifications <xref
target="refs.IGMPv3"></xref><xref target="refs.MLDv2"></xref> describe
that a host MUST accept and process any Query whose IP Destination
Address field contains any of the addresses (unicast or multicast)
assigned to the interface on which the Query arrives. In general, the
all-hosts 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 General Query. On the other hand, according to <xref
target="refs.IGMPv3"></xref><xref target="refs.MLDv2"></xref>, a router
MAY be able to unicast General Query to the tracked member hosts in
[Query Interval], if the router keeps track of membership information
(<xref target="sec.track"></xref>).</t>
<t>Unicasting IGMP/MLD General Query would reduce the drain on battery
power of mobile hosts as only the active hosts that have been receiving
multicast contents respond the unicast IGMP/MLD General Query messages
and non-active hosts do not need to pay attention to the IGMP/MLD Query
messages. This also allows the upstream router to proceed fast leaves
(or shorten leave latency) by setting LMQC/LLQC smaller, because the
router can immediately converge and update the membership information,
ideally.</t>
<t>However, there is a concern in unicast General Query. If a multicast
router sends General Query "only" by unicast, it cannot discover
potential member hosts whose join requests were lost. Since the hosts do
not retransmit the same join requests (i.e., unsolicited Report
messages), they lose the chance to join the channels unless the upstream
router asks the membership information by sending General Query by
multicast. It will be solved by using both unicast and multicast General
Queries and configuring the [Query Interval] timer value for multicast
General Query and the [Unicast Query Interval] timer value for unicast
General Query. However, using two different timers for General Queries
would require the protocol extension this document does not focus on. If
a router does not distinguish the multicast and unicast General Query
Intervals, the router SHOULD only use and enable multicast General
Query.</t>
<t>Also, unicasting General Query does not remove multicasting General
Query. Multicast General Query is necessary to update membership
information if it is not correctly synchronized due to missing Reports.
Therefore, enabling unicast General Query SHOULD NOT be used for the
implementation that does not allow to configure different query interval
timers as [Query Interval] and [Unicast Query Interval]. If a router
does not distinguish these multicast and unicast General Query
Intervals, the router SHOULD only use and enable multicast General
Query.</t>
</section>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:40:32 |