One document matched: draft-liu-multimob-igmp-mld-wireless-mobile-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-liu-multimob-igmp-mld-wireless-mobile-03"
ipr="trust200902">
<front>
<title abbrev="IGMP/MLD in wireless/mobile network">IGMP/MLD Optimizations
in Wireless and Mobile Networks</title>
<author fullname="Hui Liu" initials="H." surname="Liu">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<country></country>
</postal>
<email>liu_helen@126.com</email>
</address>
</author>
<author fullname="Mike McBride" initials="M." surname="McBride">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>2330 Central Expressway</street>
<city>Santa Clara</city>
<code>CA 95050</code>
<country>USA</country>
</postal>
<email>michael.mcbride@huawei.com</email>
</address>
</author>
<author fullname="Hitoshi Asaeda" initials="H" surname="Asaeda">
<organization abbrev="NICT">National Institute of Information and Communications Technology (NICT)</organization>
<address>
<postal>
<street>Network Architecture Laboratory</street>
<street>4-2-1 Nukui-Kitamachi</street>
<city>Koganei</city> <region>Tokyo</region>
<code>184-8795</code>
<country>Japan</country>
</postal>
<email>asaeda@nict.go.jp</email>
</address>
</author>
<date day="22" month="February" year="2013"/>
<area>Internet Area</area>
<workgroup>Multimob Working Group</workgroup>
<abstract>
<t>This document proposes a variety of optimization approaches for IGMP
and MLD in wireless and mobile networks. It aims to provide useful
guidelines to allow efficient multicast communication in these networks
using IGMP or MLD protocols.</t>
</abstract>
<note title="Requirements Language">
<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 [RFC2119].</t>
</note>
</front>
<middle>
<section anchor="Intro" title="Introduction">
<t>The deployments of various wireless access techniques are being combined with
the use of video and other applications which rely upon IP Multicast. Wireless and mobile
multicast are attracting increasing interest from content and service providers. Multicast faces
challenges with dynamic group membership management being under the constant update of
delivery paths introduced by node movement. There is a high probability of loss
and congestion due to limited reliability and capacity of wireless links.</t>
<t>Multicast networks are generally constructed by the IGMP and MLD group
management protocols (respectively for IPv4 and IPv6 networks) to track
valid receivers and by multicast routing protocol building multicast
delivery paths. This document focuses only on IGMP and MLD, the
protocols used by a host to subscribe to a multicast group and the protocols that are most likely to
be exposed to wireless links when supporting terminal mobility. As IGMP and
MLD were designed for fixed users on a wired link, they do not
necessarily work well for different wireless link types and mobile
scenarios. IGMP/MLD should be enhanced to be more
applicable in these mobile/wireless environments.</t>
<t>This memo proposes a variety of optimizations for IGMP and MLD, in
wireless and mobile networks, to improve network performance, with
minimum changes on the protocol behavior and without introducing
interoperability issues. These solutions can also be applied in wired
networks when efficiency or reliability is required.</t>
<t>For generality, this memo does not put limitations on the type of
wireless techniques running below IGMP or MLD. They could be cellular,
WiMAX, WiFi and etc, and are modeled as different abstract link models
as described in section 2.2. Even though some of them (such as WiFi)
have multicast limitations, it is probable that IGMP/MLD is enabled on
the wireless terminal and multicast is supported across the network. The
mobile IP protocol adopted on the core side, upstream from the access
router, could be PMIP, MIPv4, or MIPv6.</t>
</section>
<section title="Requirements">
<section title="Characteristics of Wireless and Mobile Multicast">
<t>Several limitations should be considered when supporting IP
multicast in wireless and mobile networks, including:</t>
<t>O Limited link bandwidth: wireless links usually have limited
bandwidth, and the situation will be made even worse if a high volume of
video multicast data has to be carried. Additionally, the bandwidth available
in the upstream and downstream directions may be asymmetrical.</t>
<t>O High loss rate: wireless links usually have packet loss ranging
from 1% to 30% according to different links types and conditions. Also
when packets have to travel between home and access networks (e.g.
through a tunnel), they are prone to loss if the two networks are
distant from each other.</t>
<t>O Frequent membership change: in fixed multicast, membership change
only happens when a user leaves or joins a group, while in mobile
scenario membership may also change when a user changes its
location.</t>
<t>O Prone to performance degradation: the possible increased
interaction of protocols across layers for mobility management, and
the limitation of link capacity, may lead to network performance
degradation and even to complete connection loss.</t>
<t>O Increased Leave Latency: the leave latency in mobile multicast
might be increased due to user movement, especially if the traffic has
to be transmitted between access and home networks, or if there is a
handshake between networks.</t>
</section>
<section title="Wireless Link Model">
<t>Wireless links can typically be categorized into three models: point-to-point (PTP), point-to-
multipoint (PTMP), and broadcast link models.</t>
<t>In the PTP model, one link is dedicated for two communication
facilities. For multicast transmission, each PTP link normally has
only one receiver and the bandwidth is dedicated for that receiver.
Such link model may be implemented by running PPP on the link or
having separate VLAN assignment for each receiver. In a mobile network,
a tunnel between entities of home and foreign networks should be
recognized as a PTP link.</t>
<t>PTMP is the model for multipoint transmission wherein there is one
centralized transmitter and multiple distributed receivers. PTMP
provides common downlink channels for all receivers and dedicated
uplink channel for each receiver. Bandwidth downstream is shared by
all receivers on the same link.</t>
<t>Broadcast links can connect two or more nodes and support broadcast
transmissions. It is quite similar to fixed Ethernet link model and its
link resource is shared in both uplink and downlink directions.</t>
</section>
<section title="Requirements on IGMP and MLD">
<t>IGMP and MLD are usually run between mobile or wireless terminals
and their first-hop access routers (i.e. home or foreign routers) to
subscribe to a IP multicast channel. Currently the version in-use
includes IGMPv2 [RFC2236] and its IPv6 counterpart MLDv1 [RFC2710],
IGMPv3 [RFC3376] and its IPv6 counterpart MLDv2 [RFC3810], and LW-
IGMPv3/MLDv2 [RFC5790]. All these versions have basic group management
capability required by a multicast subscription. The differences lie
in that IGMPv2 and MLDv1 can only join and leave a non-source-specific
group, while IGMPv3 and MLDv2 can select including and excluding
specific sources for their join and leave operation, and
LW-IGMPv3/MLDv2 simplifies IGMPv3/MLDv2 procedures by discarding
excluding-source function. Among these versions, (LW-) IGMPv3/MLDv2
has the capability of explicitly tracking each host member.</t>
<t>From the illustration given in section 2.1 and 2.2, it is desirable
for IGMP and MLD to have the following characteristics when used in
wireless and mobile networks:</t>
<t>o Adaptive to link conditions: wireless networks have various link
types, each with different bandwidth and performance features. IGMP or
MLD should be able to be adaptive to different link models and link
conditions to optimize its protocol operation.</t>
<t>o Minimal group join/leave latency: because mobility and handover
may cause a user to join and leave a multicast group frequently, fast
join and leave by the user helps to accelerate service activation and
to release unnecessary resources quickly to optimize resource
utilization.</t>
<t>o Robust to packet loss: the unreliable packet transmission due to
instable wireless link conditions and limited bandwidth, or long
distance transmission in mobile network put more strict robustness
requirement on delivery of IGMP and MLD protocol messages.</t>
<t>o Reducing packet exchange: wireless link resources are usually
more limited, precious, and congested compared to their wired
counterpart. This requires packet exchange be minimized without
degrading protocol performance.</t>
<t>o Packet burst avoidance: large number of packets generated in a
short time interval may have the tendency to deteriorate wireless
network conditions. IGMP and MLD should be optimized to reduce the
probability of packet burst.</t>
</section>
</section>
<section title="IGMP/MLD Optimization for Wireless and Mobile Networks">
<t>This section introduces several optimizations for IGMP and MLD
in wireless or mobile environment. The aim is to meet the requirements
described in section 2.3. It should be noted that because an enhancement
in one direction might result in weakening effect in another, balances
should be taken cautiously to realize overall performance elevation.</t>
<section title="Switching Between Unicast and Multicast Queries">
<t>IGMP/MLD protocols use multicast Queries whose destinations are
multicast addresses and also allows use of unicast Query with unicast
destination to be sent only to one host. Unicast Query has the
advantage of not affecting other hosts on the same link, and is
desirable for wireless communication because a mobile terminal often
has limited battery power [RFC6636]. But if the number of valid
receivers is large, using unicast Query for each receiver is
inefficient because large number of Unicast Queries have to be
generated, in which situation normal multicast Query will be a good
choice because only one General Query is needed. If the number of
receivers to be queried is small, unicast Query is advantageous over
the multicast one.</t>
<t>More flexibly, the router can choose to switch between unicast and
multicast Queries according to the practical network conditions. For
example, if the receiver number is small, the router could send
unicast Queries respectively to each receiver, without arousing other
non-member terminal which is in dormant state. When the receiver
number reaches a predefined level, the router could change to use
multicast Queries. To have the knowledge of the number of the valid
receivers, a router is required to enable explicit tracking, and
because Group-Specific Query and Group-and-Source-Specific Query are
usually not used under explicit tracking [RFC6636], the switching
operation mostly applies to General Queries.</t>
</section>
<section title="General Query Supplemented with Unicast Query">
<t>The Unicast Query can be used in assistance to General Query to
improve the robustness of solicited reports when General Query fails
to collect all of its valid members. It requires the explicit tracking
to be enabled and can be used when a router after sending a periodical
General Query collects successfully most of the valid members'
responses while losing some of which are still valid in its database.
This may be because these reports are not generated or generated but
lost for some unknown reasons. The router could choose to unicast a
Query respectively to each non-respondent valid receiver to check
whether they are still alive for the multicast reception, without
affecting the majority of receivers that have already responded.
Unicast Queries under this condition could be sent at the end of the
[Maximum Response Delay] after posting a General Query, and be
retransmitted for [Last Member Query Count] times, at an interval of
[Last Member Query Interval].</t>
</section>
<section title="Retransmission of Queries">
<t>In IGMP and MLD, apart from the continuously periodical
transmission, General Query is also transmitted during a router's
startup. It is transmitted for [Startup Query Count] times by [Startup
Query Interval]. There are some other cases where retransmission of
General Query is beneficial which are not covered by current IGMP and
MLD protocols as shown as following.</t>
<t>For example, a router which keeps track of all its active
receivers, if after sending a General Query, fails to get any response
from the receivers which are still valid in its membership database.
This may be because all the responses of the receivers happen to be
lost, or the sent Query does not arrive at the other side of the link
to the receivers. The router could compensate this situation by
retransmitting the General Query to solicit its active members. The
retransmission can also be applied to Group-Specific or
Group-and-Source-Specific Query on a router without explicit tracking
capability, when these Specific Queries cannot collect valid response,
to prevent missing valid members caused by lost Queries and
Reports.</t>
<t>The above compensating Queries could be sent [Last Member Query
Count] times, at the interval of [Last Member Query Interval], if the
router cannot get any feedback from the receivers.</t>
</section>
<section title="General Query Suppression">
<t>In IGMP and MLD, the General Query is sent periodically and
continuously without any limitation. It helps soliciting the state of
current valid member but has to be processed by all hosts on the link,
whether they are valid multicast receivers or not. When there is no
receiver, the transmission of the General Query is a waste of
resources for both the host and the router.</t>
<t>An IGMP/MLD router could suppress its transmission of General Query
if it knows there is no valid multicast receiver on an interface, e.g.
in the following cases:</t>
<t>O When the last member reports its leave for a group. This could be
judged by an explicit tracking router checking its membership
database, or by a non-explicit-tracking router getting no response
after sending Group-Specific or Group-and-Source-Specific Query.</t>
<t>O When the only member on a PTP link reports its leaving</t>
<t>O When a router after retransmitting General Queries on startup
fails to get any response</t>
<t>O When a router previously has valid members but fails to get any
response after several rounds of General Queries.</t>
<t>In these cases the router could make the decision that no member is
on the interface and totally stop its transmission of periodical
General Queries. If afterwards any valid member joins a
group, the router could resume the original cycle of general Querying.
Because General Query influences all hosts on a link,
suppressing it when it is not needed is beneficial for both the link
efficiency and terminal power saving.</t>
</section>
<section title="Tuning Response Delay According to Link Type and Status ">
<t>IGMP and MLD use delayed response to spread unsolicited Reports
from different hosts to reduce possibility of packet burst. This is
implemented by a host responding to a Query in a specific time
randomly chosen between 0 and [Maximum Response Delay], the latter of
which is determined by the router and is carried in Query messages to
inform the hosts for calculation of the response delay. A larger value
will lessen the burst better but will increase leave latency (the time
taken to cease the traffic flowing after the last member requests the
escaping of a channel).</t>
<t>In order to avoid message burst and reduce leave latency, the
Response Delay may be dynamically calculated based on the expected
number of responders, and link type and status, as shown in the
following:</t>
<t>O If the expected number of reporters is large and link condition
is bad, longer Maximum Response Delay is recommended; if the expected
number of reporters is small and the link condition is good, smaller
Maximum response Delay should be set.</t>
<t>o If the link type is PTP, the Maximum Response Delay can be chosen
smaller, whereas if the link is PTMP or broadcast medium, the Maximum
Response Delay can be configured larger.</t>
<t>The Maximum Response Delay could be configured by the administrator
as mentioned above, or be calculated automatically by a software tool
implemented according to experiential model for different link modes.
The measures to determine the instant value of Maximum Response Delay
are out of this document's scope.</t>
</section>
<section title="Triggering Reports and Queries Quickly During Handover">
<t>When a mobile terminal is moving from one network to another, if it
is receiving multicast content, its new access network should try to
deliver the content to the receiver without disruption or performance
deterioration. In order to implement smooth handover between networks,
the terminal's membership should be acquired as quickly as possible by
the new access network.</t>
<t>An access router could trigger a Query to a terminal as soon as it
detects the terminal's attaching on its link. This could be a General
Query if the number of the entering terminals is not small (e.g when
they are simultaneously in a moving train). Or this Query could also
be a unicast Query for this incoming terminal to prevent unnecessary
action of other terminals in the switching area.</t>
<t>For the terminal, it could send a report immediately if it is
currently in the multicast reception state, when it begins to connect
the new network. This helps establishing more quickly the membership
state and enable faster multicast stream injection, because with the
active report the router does not need to wait for the query period to
acquire the terminal's newest state.</t>
</section>
</section>
<section anchor="Apply"
title="Applicability and Interoperability Considerations">
<t>Among the optimizations listed above, 'Switching between unicast and
multicast Queries'(3.1) and 'General Query Supplemented with Unicast
Query'(3.2) requires a router to know beforehand the valid members
connected through an interface, thus require explicit tracking
capability. An IGMP/MLD implementation could choose any combination of
the methods listed from 3.1 to 3.6 to optimize multicast communication
on a specific wireless or mobile network.</t>
<t>For example, an explicit-tracking IGMPv3 router, can switch to
unicast General Queries if the number of members on a link is small
(3.1), can trigger unicast Query to a previously valid receiver if
failing to get expected responses from it (3.2), can retransmit a
General Query if after the previous one cannot collect reports from all
valid members (3.3), and can stop sending a General Query when the last
member leaves the group (3.4), and etc.</t>
<t>For interoperability, it is required if multiple multicast routers
are connected to the same network for redundancy, each router are
configured with the same optimization policy to synchronize the
membership states among the routers.</t>
</section>
<section title="IGMP/MLD Suspend and Resume">
<section title="IGMP/MLD Suspend Request">
<t>IGMP/MLD Suspend is an operation triggered by a host that subscribes multicast channels or an IGMP/MLD proxy <xref target="refs.Proxy" />
to which hosts subscribing multicast channels attached. An IGMP/MLD Suspend message requests an adjacent upstream router to suspend forwarding
subscribed data, while to keep the subscription state (i.e., not to prune the routing path). It is useful especially in a mobile network. When a mobile host
moves from a current network (i.e., a mobile host's point of attachment) to a different network, an IGMP/MLD Suspend message is sent by the host itself
(or an IGMP/MLD proxy to which mobile hosts attached).</t>
<!-- The IGMP/MLD Suspend message will be sent by the mobile host or the proxy depending on which mobile protocol is in use. For instance, in
MIPv6 <xref target="refs.MIPv6" />, a mobile host detects its own movement and sends the IGMP/MLD Suspend message to its upstream router (or Home Agent).-->
<t>When an IGMP/MLD proxy receives IGMP/MLD Suspend messages on its downstream interface, it forwards the Suspend message to its upstream
router via its upstream interface if needed (see <xref target="sec.hold_recept" />.</t>
</section>
<!-- ============================================================ -->
<section anchor="sec.release_req" title="IGMP/MLD Resume Request">
<t>When a host that has subscribed multicast channels and sent IGMP/MLD Suspend messages attaches to a new network, it immediately sends
IGMP/MLD Resume messages to request its upstream router to resume forwarding the data. The Resume Records specified in the IGMP/MLD Resume
message will be the same as that of the Suspend Records the host sent.</t>
</section>
<!-- ============================================================ -->
<section anchor="sec.hold_recept" title="IGMP/MLD Suspend Reception">
<t>When a multicast router receives an IGMP/MLD Suspend message from the downstream member hosts or IGMP/MLD proxy, it examines whether
the message sender is the sole member of the reported channels at the downstream link or not. There are two ways to know it. One is done by the
Group-Specific or Group-and-Source Specific Queries. The other is done by the explicit tracking function <xref target="refs.explicit" />.</t>
<t>The router sends the Group-Specific or Group-and-Source Specific Queries for all records in the Suspend messages. If the router receives IGMP/MLD
reports including some or all of the Suspend Records, it eliminates the reported records from the Suspend Records and keeps forwarding these data. If the
router does not receive IGMP/MLD reports for some or all of the Suspend Records, it recognizes that the Suspend message sender is the sole member
host for these channels on the link. After the router organizes the new Suspend Records (that eliminate reported records from the original one), it suspends
data forwarding for them.</t>
<t>The explicit tracking function gives advantage of organizing the new Suspended Records. If a router enables the explicit tracking function, it can
recognize whether the message sender host is the sole member without sending the Group-Specific or Group-and-Source Specific Queries. Then the
router suspends data forwarding based on the up-to-date Suspend Records.</t>
<t>The multicast router maintains Suspend Records until it receives the corresponding IGMP/MLD Resume message (described in the next section) or
the IGMP/MLD Suspend Interval timer (described in <xref target="sec.value_hold" />) is expired. When either the Resume message reception or the
timer expiration occurs, the router resume data forwarding for the Suspend Records and discards the Suspend Records.</t>
<t>If a multicast router receives an IGMP/MLD Suspend message, which includes Multicast Address Records already suspended, the router restarts
the IGMP/MLD Suspend Interval timer for the corresponding Multicast Address Records.</t>
<t>When an IGMP/MLD proxy receives an IGMP/MLD Suspend message from a downstream host, it behaves as a multicast router as described above,
because the proxy device performs the router portion of the IGMP or MLD protocol on its downstream interfaces.</t>
<t>When a mobile node that has sent the IGMP/MLD Suspend message receives the corresponding Group-Specific or Group-and-Source Specific
Queries for the Suspend Records, it replies the standard IGMP/MLD Report messages as defined in <xref target="refs.IGMPv3" /><xref target="refs.MLDv2" />.
<!--(It is necessary because the router may prune if the Suppress sender does not reply, except the case the router tracks member hosts.)-->
</t>
</section>
<!-- ============================================================ -->
<section anchor="sec.release_recept" title="IGMP/MLD Resume Reception">
<t>When a multicast router receives an IGMP/MLD Resume message, the router examines the message sender and an IGMP/MLD Suspend Interval
timer. If the router has the Suspend Records given from the Resume message sender, it compares the Suspend Records with the notified Multicast
Address Records specified in the Resume message. For the matched Multicast Address Records, the router then removes the entries from the Suspend
Records and resumes data forwarding with restarting the group or source timers. For the mismatched Multicast Address Records, the router keeps
unchanged (then will be removed by timeout) or explicitly starts the leave (or prune) procedures for the channels, while it depends on the implementation.</t>
<t> If either the router does not have the corresponding Suspend Records or the IGMP/MLD Suspend Interval timer has expired, then the router does not
take any action.</t>
<t>If a router that did not recognize an IGMP/MLD Suspend message (e.g., due to packet loss or some troubles in its transmission) receives an IGMP/MLD
Resume message, it will accept the message as a regular Current-State Report IGMP/MLD message.
<!-- as specified in <xref target="sec.interop" />-->
</t>
</section>
<!-- ============================================================ -->
<!-- <section anchor="sec.format" title="IGMP/MLD Suspend and Resume Record Format">
<t>The standard IGMP/MLD Report message format and Multicast Address Record defined in <xref target="refs.IGMPv3" /><xref target="refs.MLDv2" />
can be used for both IGMP/MLD Suspend and Resume messages. However, the new Record Type values for both Records must be assigned as follows.</t>
<list style='format %d ' handIndent='10'>
<t>SUSPEND_INCLUDE - indicates that the interface has a filter mode of INCLUDE for the specified multicast address. The Source Address [i] fields in
this Multicast Address Record contain the interface's source list for the specified multicast address. A SUSPEND_INCLUDE Record is never sent with an
empty source list.</t> -->
<!-- 7 -->
<!-- <t>SUSPEND_EXCLUDE - indicates that the interface has a filter mode of EXCLUDE for the specified multicast address. The Source Address [i]
fields in this Multicast Address Record contain the interface's source list for the specified multicast address, if it is non-empty. When a mobile host works with
LW-IGMPv3/LW-MLDv2 (<xref target="refs.LW" />), the Multicast Address Record does not contain the Source Address [i] field with SUSPEND_EXCLUDE type
value.</t> -->
<!-- 8 -->
<!-- </list>
</section>-->
</section>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<!-- <section anchor="sec.interop" title="Interoperability with Older Protocols">-->
<!-- <t>An IGMP/MLD Notification operation is a simple optimization for mobile hosts to spontaneously send IGMP/MLD Current-State Report to their upstream
multicast routers. Since a multicast router solicits downstream membership information by IGMP/MLD General Query, non-upgraded mobile hosts can coexist in
the network. However, join and leave latency for non-upgraded mobile hosts may become longer due to the longer [Query Interval] timer configuration for multicast
routers. Note that the IGMP/MLD Notification operation does not require any modification to multicast routers.</t>-->
<!-- <t>If a multicast router does not support an IGMP/MLD Suspend operation, it will ignore the IGMP/MLD Suspend message. In this case, an IGMP/MLD
Current-State Report message sent by a mobile host that previously requested an IGMP/MLD Suspend operation to stop forwarding data is dealt with as a new
join request for the specified multicast sessions (when the corresponding group or source timer is expired) or simply updates the corresponding group and/or
source timer (when these timers are not expired and the membership status has been still active).</t>-->
<!-- </section>-->
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<section anchor="sec.value" title="Timers, Counters, and Their Default Values">
<!-- ============================================================ -->
<section anchor="sec.value_hold" title="IGMP/MLD Suspend Interval Timer">
<t>After a multicast router receiving an IGMP/MLD Suspend message will identify the corresponding multicast sessions/channels, it suspends data
forwarding and keeps the Suspend Records until the given amount of timer value is expired. This timer is named the "IGMP/MLD Suspend Interval timer",
which is a configurable value.</t>
<t>The Suspend Interval is used to allow a multicast router to resume the multicast session. Therefore, if the multicast router does not receive the
corresponding IGMP/MLD Resume message for the IGMP/MLD Resume operation within the Suspend Interval, it leaves the sessions/channels recorded
in the Suspend Records and discards the Suspend Records. Note that the router does not send any IGMP/MLD Query message for the timeout sessions/channels
and immediately leaves from them.</t>
<!-- <t>[TODO: We will provide the default Suspend Interval value based on some experimental results in the revised version. Note that this value might be
dependent on each mobile protocol; hence the value must be able to be adjusted by operators.]</t>-->
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
<t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>Since the methods only involve the tuning of protocol behavior by
e.g. retransmission, changing delay parameter, or other compensating
operations, they do not introduce additional security weaknesses. The
security consderations described in [RFC2236], [RFC3376], [RFC2710] and
[RFC3810] can be reused. And to achieve some security level in insecure
wireless network, it is possible to take stronger security procedures
during IGMP/MLD message exchange, which are out of the scope of this
memo.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Behcet Sarikaya, Qin Wu, Stig Venaas, Gorry Fairhurst,
Thomas C. Schmidt, Marshall Eubanks, Suresh Krishnan, J.William Atwood,
WeeSan Lee, Imed Romdhani, Liu Yisong and Wei Yong for
their valuable comments and suggestions on this document.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="refs.KEYWORDS">
<front>
<title>Key words for use in RFCs to indicate requirement levels</title>
<author initials="S" surname="Bradner" />
<date month="March" year="1997" />
</front>
<seriesInfo name="RFC" value="2119" />
</reference>
<reference anchor="refs.IGMPv3">
<front>
<title>Internet Group Management Protocol, Version 3</title>
<author initials="B" surname="Cain" />
<author initials="S" surname="Deering" />
<author initials="I" surname="Kouvelas" />
<author initials="B" surname="Fenner" />
<author initials="A" surname="Thyagarajan" />
<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 initials="L" surname="Costa" />
<date month="June" year="2004" />
</front>
<seriesInfo name="RFC" value="3810" />
</reference>
<reference anchor="refs.PIM">
<front>
<title>Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)</title>
<author initials="B" surname="Fenner" />
<author initials="M" surname="Handley" />
<author initials="H" surname="Holbrook" />
<author initials="I" surname="Kouvelas" />
<date month="August" year="2006" />
</front>
<seriesInfo name="RFC" value="4601" />
</reference>
<reference anchor="refs.IGMPv1">
<front>
<title>Host Extensions for IP Multicasting</title>
<author initials="S" surname="Deering" />
<date month="August" year="1989" />
</front>
<seriesInfo name="RFC" value="1112" />
</reference>
<reference anchor="refs.IGMPv2">
<front>
<title>Internet Group Management Protocol, Version 2</title>
<author initials="W" surname="Fenner" />
<date month="July" year="1997" />
</front>
<seriesInfo name="RFC" value="2373" />
</reference>
<reference anchor="refs.MLDv1">
<front>
<title>Multicast Listener Discovery (MLD) for IPv6</title>
<author initials="S" surname="Deering" />
<author initials="W" surname="Fenner" />
<author initials="B" surname="Haberman" />
<date month="October" year="1999" />
</front>
<seriesInfo name="RFC" value="2710" />
</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 initials="H" surname="He" />
<author initials="B" surname="Haberman" />
<author initials="H" surname="Sandick" />
<date month="August" year="2006" />
</front>
<seriesInfo name="RFC" value="4605" />
</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 initials="W" surname="Cao" />
<author initials="H" surname="Asaeda" />
<date month="February" year="2010" />
</front>
<seriesInfo name="RFC" value="5790" />
</reference>
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.2236'?>
<?rfc include='reference.RFC.2710'?>
<?rfc include='reference.RFC.3376'?>
<?rfc include='reference.RFC.3810'?>
<?rfc include='reference.RFC.5790'?>
<?rfc include='reference.RFC.6636'?>
</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" />
<date month="January" year="2013" />
</front>
<seriesInfo name="draft-ietf-pim-explicit-tracking-04.txt" value="(work in progress)" />
</reference>
<reference anchor="refs.MIPv6">
<front>
<title>Mobility Support in IPv6</title>
<author initials="D" surname="Johnson" />
<author initials="C" surname="Perkins" />
<author initials="J" surname="Arkko" />
<date month="June" year="2004" />
</front>
<seriesInfo name="RFC" value="3775" />
</reference>
<reference anchor="refs.PMIPv6">
<front>
<title>Proxy Mobile IPv6</title>
<author initials="S, Ed." surname="Gundavelli" />
<author initials="K" surname="Leung" />
<author initials="V" surname="Devarapalli" />
<author initials="K" surname="Chowdhury" />
<author initials="B" surname="Patil" />
<date month="August" year="2008" />
</front>
<seriesInfo name="RFC" value="5213" />
</reference>
<reference anchor="refs.Noel">
<front>
<title>Multicast for Mobile Hosts in IP Networks: Progress and Challenges</title>
<author initials="C" surname="Jelger" />
<author initials="T" surname="Noel" />
<date month="October" year="2002" />
</front>
<seriesInfo name="IEEE Wireless Comm." value="pp.58-64" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 18:59:15 |