< draft-liu-multimob-igmp-mld-wireless-mobile-00.txt   draft-liu-multimob-igmp-mld-wireless-mobile-01.txt >
Multimob Working Group H. Liu Multimob Working Group H. Liu
Internet-Draft M. McBride Internet-Draft M. McBride
Intended status: Informational Huawei Technologies Intended status Huawei Technologies
Expires: September 3, 2012 March 2, 2012 Expires: September 13, 2012 March 12, 2012
IGMP/MLD Optimization in Wireless and Mobile Networks IGMP/MLD Optimization in Wireless and Mobile Networks
draft-liu-multimob-igmp-mld-wireless-mobile-00 draft-liu-multimob-igmp-mld-wireless-mobile-01
Abstract Abstract
This document proposes a variety of optimization approaches for IGMP This document proposes a variety of optimization approaches for IGMP
and MLD in wireless and mobile networks. It aims to provide useful and MLD in wireless and mobile networks. It aims to provide useful
guideline to allow efficient multicast communication in these guideline to allow efficient multicast communication in these
networks using IGMP or MLD protocols. networks using IGMP or MLD protocols.
Requirements Language Requirements Language
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 September 3, 2012. This Internet-Draft will expire on September 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Characteristics of Wireless and mobile Multicast . . . . . 3 2.1. Characteristics of Wireless and Mobile Multicast . . . . . 3
2.2. Wireless Link Model . . . . . . . . . . . . . . . . . . . 4 2.2. Wireless Link Model . . . . . . . . . . . . . . . . . . . 4
2.3. Requirements on IGMP and MLD . . . . . . . . . . . . . . . 4 2.3. Requirements on IGMP and MLD . . . . . . . . . . . . . . . 5
3. IGMP/MLD optimization for Wireless and Mobile Network . . . . 5 3. IGMP/MLD Optimization for Wireless and Mobile Networks . . . . 6
3.1. Minimizing Query Frequency by increasing intervals . . . . 6 3.1. Switching Between Unicast and Multicast Queries . . . . . 6
3.2. Switching Between Unicast and Multicast Queries . . . . . 7 3.2. General Query Supplemented with Unicast Query . . . . . . 6
3.3. General Query Supplemented with Unicast Query . . . . . . 7 3.3. Retransmission of Queries . . . . . . . . . . . . . . . . 7
3.4. Retransmission of General Query . . . . . . . . . . . . . 8 3.4. General Query Suppression . . . . . . . . . . . . . . . . 7
3.5. General Query Supplemented with Unicast Query . . . . . . 8 3.5. Tuning Response Delay According to Link Type and Status . 8
3.6. Tuning Response Delay according to link type and status . 9 3.6. Triggering Reports and Queries Quickly During Handover . . 9
3.7. Triggering Reports and Queries quickly during handover . . 10 4. Applicability and Interoperability Considerations . . . . . . 9
4. Applicability and interoperability considerations . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
With the wide deployment of various wireless access techniques and With the wide deployment of various wireless access techniques and
the tendency to support video applications on these networks, the tendency to support video applications on these networks,
wireless and mobile multicast come to attract more and more interests wireless and mobile multicast come to attract more and more interests
from content and service providers, but still face great challenges from content and service providers, but still face great challenges
when considering dynamic group membership management and constant when considering dynamic group membership management and constant
update of delivery path introduced by node movement, and high update of delivery path introduced by node movement, and high
probability of loss and congestion due to limited reliability and probability of loss and congestion due to limited reliability and
skipping to change at page 3, line 25 skipping to change at page 3, line 25
Multicast network is generally constructed by IGMP and MLD group Multicast network is generally constructed by IGMP and MLD group
management protocol (respectively for IPv4 and IPv6 networks) to management protocol (respectively for IPv4 and IPv6 networks) to
track valid receivers and by multicast routing protocol to build track valid receivers and by multicast routing protocol to build
multicast delivery paths. This document focuses only on IGMP and multicast delivery paths. This document focuses only on IGMP and
MLD, which are used by a host to subscribe a multicast group and are MLD, which are used by a host to subscribe a multicast group and are
most possibly to be exposed to wireless link to support terminal most possibly to be exposed to wireless link to support terminal
mobility. As IGMP and MLD were designed for fixed users using wired mobility. As IGMP and MLD were designed for fixed users using wired
link, they do not necessarily work well for all kinds of wireless link, they do not necessarily work well for all kinds of wireless
link types and mobile scenarios, thus should be enhanced to be link types and mobile scenarios, thus should be enhanced to be
adapted to these environment. adapted to these environments.
This memo proposes a variety of optimizations for IGMP and MLD in This memo proposes a variety of optimizations for IGMP and MLD in
wireless and mobile networks to improve network performance, with wireless and mobile networks to improve network performance, with
minimum changes on the protocol behavior while without introducing minimum changes on the protocol behavior and without introducing
interoperability issues. These solutions can also be applied in interoperability issues. These solutions can also be applied in
wired network when efficiency or reliability is required. wired network when efficiency or reliability is required.
For generality, this memo does not put any limitation 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 over the
air techniques (such as WiFi) have multicast limitations, it is
probable that IGMP/MLD is enabled on the wireless terminal and
multicast needs to be supported across the network. The mobile IP
protocol adopted on the core side, upstream from the access router,
could either be PMIP, MIPv4, or MIPv6.
2. Requirements 2. Requirements
2.1. Characteristics of Wireless and mobile Multicast 2.1. Characteristics of Wireless and Mobile Multicast
Several aspects should be considered when supporting IP multicast in Several aspects should be considered when supporting IP multicast in
wireless and mobile networks, including: wireless and mobile networks, including:
O Limited link bandwidth: wireless link usually has limited O Limited link bandwidth: wireless link usually has limited
bandwidth, and the situation will be made even worse if high volume bandwidth, and the situation will be made even worse if high volume
video multicast data has to be carried. Also the bandwidth available video multicast data has to be carried. Also the bandwidth available
in the upstream and downstream directions may be asymmetrical. in the upstream and downstream directions may be asymmetrical.
O High loss rate: wireless link usually has packet loss ranging from O High loss rate: wireless link usually has packet loss ranging from
skipping to change at page 4, line 44 skipping to change at page 5, line 8
uplink channel for each receiver. Bandwidth downstream is shared by uplink channel for each receiver. Bandwidth downstream is shared by
all receivers on the same link. all receivers on the same link.
Broadcast link can connect two or more nodes and supports broadcast Broadcast link can connect two or more nodes and supports broadcast
transmission. It is quite similar to fixed Ethernet link model and transmission. It is quite similar to fixed Ethernet link model and
its link resource is shared in both uplink and downlink directions. its link resource is shared in both uplink and downlink directions.
2.3. Requirements on IGMP and MLD 2.3. Requirements on IGMP and MLD
IGMP and MLD are usually run between mobile or wireless terminals and IGMP and MLD are usually run between mobile or wireless terminals and
their first-hop access routers (i.e.home or foreign routers) to their first-hop access routers (i.e. home or foreign routers) to
subscribe an IP multicast channel, and sometimes run between home subscribe an IP multicast channel. Currently the version in-use
router and access router (in PMIP case [RFC6224]) to proxy IGMP/MLD includes IGMPv2 [RFC2236] and its IPv6 counterpart MLDv1 [RFC2710],
in mobile network the summarized IGMP/MLD reports from the latter to IGMPv3 [RFC3376] and its IPv6 counterpart MLDv2 [RFC3810], and LW-
the former. Currently the version in-use includes IGMPv2 [RFC2236] IGMPv3/MLDv2 [RFC5790]. All these versions have basic group
and its IPv6 counterpart MLDv1 [RFC2710], IGMPv3 [RFC3376] and its management capability required by a multicast subscription. The
IPv6 counterpart MLDv2 [RFC3810], and lightweight IGMPv3/MLDv2 differences lie in that IGMPv2 and MLDv1 can only join and leave a
[RFC5790]. All these versions have basic group management capability non-source specific group, while IGMPv3 and MLDv2 can select
required by a multicast subscription. The differences lie in that including and excluding specific sources for their join and leave
IGMPv2 and MLDv1 can only join and leave a non-source specific group, operation, and LW-IGMPv3/MLDv2 simplifies IGMPv3/MLDv2 procedures by
while IGMPv3 and MLDv2 can select including and excluding specific discarding excluding-source function. Among these versions, (LW-)
sources for their join and leave operation, and LW-IGMPv3/MLDv2 IGMPv3/MLDv2 has the capability of explicit track each host member.
simplifies IGMPv3/MLDv2 procedures by discarding useless excluding-
source function. Among these versions, (LW-) IGMPv3/MLDv2 has the
capability of explicit track each host member.
From the illustration given in section 2.1 and 2.2, it is desirable 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 for IGMP and MLD to have the following characteristics when used in
wireless and mobile networks: wireless and mobile networks:
o Adaptive to link conditions: wireless network has various link o Adaptive to link conditions: wireless network has various link
types, each with different bandwidth and performance features. IGMP types, each with different bandwidth and performance features. IGMP
or MLD should be able to be adaptive to different link model and link or MLD should be able to be adaptive to different link model and link
conditions to optimize its protocol operation. conditions to optimize its protocol operation.
skipping to change at page 5, line 43 skipping to change at page 6, line 5
limited, precious, and congested compared to their wired counterpart. limited, precious, and congested compared to their wired counterpart.
This requires packet exchange be minimized without degrading protocol This requires packet exchange be minimized without degrading protocol
performance. performance.
o Packet burst avoidance: large number of packets generated within a o Packet burst avoidance: large number of packets generated within a
short time interval may have the tendency to deteriorate wireless short time interval may have the tendency to deteriorate wireless
network conditions. IGMP and MLD should be optimized if their network conditions. IGMP and MLD should be optimized if their
protocol message generation has the potential of introducing packet protocol message generation has the potential of introducing packet
burst. burst.
3. IGMP/MLD optimization for Wireless and Mobile Network 3. IGMP/MLD Optimization for Wireless and Mobile Networks
This section introduces several optimization methods for IGMP and MLD This section introduces several optimization methods for IGMP and MLD
in wireless or mobile environment. The aim is to meet the in wireless or mobile environment. The aim is to meet the
requirements described in section 2.3. These measures could be requirements described in section 2.3. These measures could be
applied between host and access routers in mobile or wireless applied between host and access routers in mobile or wireless
network, and in mobile PMIPv6 [RFC6224] case, could also be used network. It should be noted that because an enhancement in one
between access and home routers. It should be noted that because an direction might result in weakening effect in another, balances
enhancement in one direction might result in weakening effect in should be taken cautiously to realize overall performance elevation.
another, balances should be taken cautiously to realize overall
performance elevation.
3.1. Minimizing Query Frequency by increasing intervals
In IGMP and MLD, Group-Specific Query and Group-and-Source-Specific
Query are triggered on reception of a Leave message, and are sent for
[Last Member Query Count] times with fixed [Last Member Query
Interval], to learn whether there are valid members from an attached
link. If a network is undergoing congestion, multiple transmissions
of the Queries as above may further deteriorate the conditions. To
avoid congestion or make remedy during congestion, these Queries can
be slowed down when a router cannot collect successfully expected
responses.
The slowing down process of the Queries could be arranged in a
prolonged time interval as described in [ADAPTIVE]. The slowdown
process should be: a router after sending a Query, if acquires the
expected responses from the receivers, refreshes its state database
and optionally stop the querying retransmission process, or if after
a time interval fails to get the expected report responses, resends a
Query with an increased (e.g. double) interval. This process can be
repeated, each time the retransmission is arranged in a progressively
prolonged time interval, till the router receives the expected
responses, or determines the receiver is unreachable and stops the
sending of the Query.
Query slowdown can be applied in the cases as listed in the following
examples:
O When Group-Specific Query and Group-and-Source-Specific Query are
used to track other members but cannot get any response.
O When all group members leave a group or move out of scope, the
General Query sent by the router cannot solicit any response on a
network, as illustrated in section 3.4.
O When General Query is retransmitted due to possible loss or
congestion deducing from no responses from valid members in the
database, on the primes that explicit tracking is used.
O When General Query is retransmitted by a router on startup but no
response can be acquired.
O When unicast Query is sent to query a particular valid receiver,
from whom no response could be collected, as described in section 3.2
and 3.3. This requires explicit tracking to be enabled.
Query retransmission with incremental interval enables the router to
reduce the total query-response times and consequently the packet
count. The variable time interval and the termination condition of
retransmission should be configurable and could be set according to
actual network condition, which is out the scope of this document.
3.2. Switching Between Unicast and Multicast Queries 3.1. Switching Between Unicast and Multicast Queries
IGMP/MLD protocols use multicast Queries whose destination addresses IGMP/MLD protocols use multicast Queries whose destination addresses
are multicast addresses and also allow use of unicast Query with are multicast addresses and also allow use of unicast Query with
unicast destination to be sent only for one destination. Unicast unicast destination to be sent only for one destination. Unicast
Query has the advantage of not affecting other hosts on the same Query has the advantage of not affecting other hosts on the same
link, and is desirable for wireless communication because a mobile link, and is desirable for wireless communication because a mobile
terminal often has limited battery power. But if the number of valid terminal often has limited battery power. But if the number of valid
receivers is large, using unicast Query for each receiver is receivers is large, using unicast Query for each receiver is
inefficient because large number of Unicast Queries have to be inefficient because large number of Unicast Queries have to be
generated, in which situation normal multicast Query will be a good generated, in which situation normal multicast Query will be a good
choice because only one General Query is needed. If the number of choice because only one General Query is needed. If the number of
receivers to be queried is small, unicast Query is advantageous over receivers to be queried is small, unicast Query is advantageous over
the multicast one. the multicast one.
More flexibly, the router can choose to switch between unicast and More flexibly, the router can choose to switch between unicast and
multicast Query according to the practical network conditions. For multicast Query according to the practical network conditions. For
example, if the receiver number is small, the router could send example, if the receiver number is small, the router could send
unicast Queries respectively to each receiver, without arousing other unicast Queries respectively to each receiver, without arousing other
non-member host which is in the dormant state. When the receiver non-member host which is in dormant state. When the receiver number
number reaches a predefined level, the router could change to use reaches a predefined level, the router could change to use multicast
multicast Queries. To have the knowledge of the number of the valid Queries. To have the knowledge of the number of the valid receivers,
receivers, a router is required to enable explicit tracking, and a router is required to enable explicit tracking, and because Group-
because Group-Specific Query and Group-and-Source-Specific Query are Specific Query and Group-and-Source-Specific Query are usually not
usually not used under explicit tracking, the switching only applies used under explicit tracking, the switching mostly applies to General
to General Queries. Queries.
3.3. General Query Supplemented with Unicast Query 3.2. General Query Supplemented with Unicast Query
Unicast Query also can be used in assistance to General Query to Unicast Query also can be used in assistance to General Query to
improve the robustness of solicited reports when General Query fails improve the robustness of solicited reports when General Query fails
to collect all of its valid members. It requires the explicit 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 tracking to be enabled and can be used when a router after sending a
periodical General Query collects successfully most of the valid periodical General Query collects successfully most of the valid
members' responses while losing some of which are still valid in its members' responses while losing some of which are still valid in its
database. This may be because the non-respondent ones silently leave database. This may be because the non-respondent ones silently leave
the network without any notification, or because their reports are the network without any notification, or because their reports are
lost for some unknown reasons. The router could choose to unicast a lost for some unknown reasons. The router could choose to unicast a
skipping to change at page 8, line 4 skipping to change at page 7, line 8
tracking to be enabled and can be used when a router after sending a tracking to be enabled and can be used when a router after sending a
periodical General Query collects successfully most of the valid periodical General Query collects successfully most of the valid
members' responses while losing some of which are still valid in its members' responses while losing some of which are still valid in its
database. This may be because the non-respondent ones silently leave database. This may be because the non-respondent ones silently leave
the network without any notification, or because their reports are the network without any notification, or because their reports are
lost for some unknown reasons. The router could choose to unicast a lost for some unknown reasons. The router could choose to unicast a
Query respectively to each non-respondent valid receiver to check Query respectively to each non-respondent valid receiver to check
whether they are still alive for the multicast reception, without whether they are still alive for the multicast reception, without
affecting the majority of receivers that have already responded. affecting the majority of receivers that have already responded.
Unicast Queries under this condition could be sent at the end of the Unicast Queries under this condition could be sent at the end of the
[Maximum Response Delay] after posting a General Query, and be [Maximum Response Delay] after posting a General Query, and be
retransmitted for [Last Member Query Count] times, at a constant retransmitted for [Last Member Query Count] times, at a constant
interval, or at incremental interval as described in section 3.1. interval or at incremental interval as described [ADAPTIVE].
3.4. Retransmission of General Query 3.3. Retransmission of Queries
In IGMP and MLD, apart from the continuously periodical transmission, In IGMP and MLD, apart from the continuously periodical transmission,
General Query is also transmitted during a router's startup. It is General Query is also transmitted during a router's startup. It is
transmitted for [Startup Query Count] times by [Startup Query transmitted for [Startup Query Count] times by [Startup Query
Interval]. There are some other cases where retransmission of Interval]. There are some other cases where retransmission of
General Query is beneficial which are not covered by current IGMP and General Query is beneficial which are not covered by current IGMP and
MLD protocols as shown as following. MLD protocols as shown as following.
For example, a router which keeps track of all its active receivers, 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 if after sending a General Query, fails to get any response from the
receivers which are still valid in its membership database. This may receivers which are still valid in its membership database. This may
be because all these valid receivers have left the group silently or be because all these valid receivers have left the group silently or
moved out of range, or all the responses of the receivers happen to moved out of range, or all the responses of the receivers happen to
be lost, or the sent Query does not arrive at the other side of the 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 link to the receivers. The router could compensate this situation by
retransmitting the General Query to solicit its active members. retransmitting the General Query to solicit its active members. The
retransmission can also be used to group or source-specific group
Queries on a router without explicit tracking capability, when the
Queries cannot collect valid response, to prevent missing valid
memebers caused by lost Queries and Reports.
This compensating General Query could be sent several times, if the The compensating Queries could be sent several times, if the router
router cannot get any feedback from the receivers which are valid in cannot get any feedback from the receivers. The repetition of the
the database. The repetition of the transmission could be in fixed transmission could be in fixed interval, or in prolonged interval as
interval, or in prolonged interval as described in section 3.1. The described [ADAPTIVE].
method can also be applied to router without explicit tracking
enabled, in which case General Query is retransmitted if no valid
response can be collected for a group or source-specific group which
previously has valid reception state.
3.5. General Query Supplemented with Unicast Query 3.4. General Query Suppression
In IGMP and MLD, General Query is sent periodically and continuously In IGMP and MLD, General Query is sent periodically and continuously
without any limitation. It helps soliciting the state of current without any limitation. It helps soliciting the state of current
valid member but has to be processed by all terminals on the link, valid member but has to be processed by all terminals on the link,
whether they are valid multicast receivers or not. When there is no whether they are valid multicast receivers or not. When there is no
receiver, the transmission of the General Query is a waste of receiver, the transmission of the General Query is a waste of
resources for both the terminals and the router. resources for both the terminals and the router.
An IGMP/MLD router could suppress its transmission of General Query An IGMP/MLD router could suppress its transmission of General Query
if it knows there is no valid multicast receiver on an interface, if it knows there is no valid multicast receiver on an interface,
skipping to change at page 9, line 4 skipping to change at page 8, line 9
resources for both the terminals and the router. resources for both the terminals and the router.
An IGMP/MLD router could suppress its transmission of General Query An IGMP/MLD router could suppress its transmission of General Query
if it knows there is no valid multicast receiver on an interface, if it knows there is no valid multicast receiver on an interface,
e.g. in the following cases: e.g. in the following cases:
O When the last member reports its leave for a group. This could be O When the last member reports its leave for a group. This could be
judged by an explicit tracking router checking its membership judged by an explicit tracking router checking its membership
database, or by a non-explicit-tracking router getting no response database, or by a non-explicit-tracking router getting no response
after sending Group-Specific Query or Group-and-Source-Specific Query after sending Group-Specific Query or Group-and-Source-Specific Query
O When the only member on a PTP link reports its leaving O When the only member on a PTP link reports its leaving
O When a router after retransmitting General Queries on startup fails O When a router after retransmitting General Queries on startup fails
to get any response to get any response
O When a router previously has valid members but fails to get any O When a router previously has valid members but fails to get any
response after several rounds of General Queries. response after several rounds of General Queries.
In these cases the router could make the decision that no member is In these cases the router could make the decision that no member is
on the interface and totally stop its transmission of periodical on the interface and totally stop its transmission of periodical
General Queries. If afterwards there is any valid member joins a General Queries. If afterwards there is any valid member joins a
group, the router could resume the original cycle of general group, the router could resume the original cycle of general
Querying. Because General Query has influences on all terminals on a Querying. Because General Query has influences on all terminals on a
link, suppressing it when it is not needed is beneficial for both the link, suppressing it when it is not needed is beneficial for both the
link efficiency and terminal power saving. link efficiency and terminal power saving.
3.6. Tuning Response Delay according to link type and status 3.5. Tuning Response Delay According to Link Type and Status
IGMP and MLD use delayed response to spread unsolicited Reports from IGMP and MLD use delayed response to spread unsolicited Reports from
different hosts to reduce possibility of packet burst. This is different hosts to reduce possibility of packet burst. This is
implemented by a host responding to a Query in a specific time implemented by a host responding to a Query in a specific time
randomly chosen between 0 and [Maximum Response Delay]. The value of randomly chosen between 0 and [Maximum Response Delay]. The value of
[Maximum Response Delay] is determined by the router and is carried [Maximum Response Delay] is determined by the router and is carried
in Query messages to inform the hosts for the calculation. A larger in Query messages to inform the hosts for the calculation. A larger
value will lessen the burst better but will increase leave latency value will lessen the burst better but will increase leave latency
(the time between the last listener request escaping a channel and (the time between the last listener request escaping a channel and
the traffic actually ceases flowing). the traffic actually ceases flowing).
skipping to change at page 10, line 5 skipping to change at page 9, line 11
o If the link type is PTP, the Maximum Response Delay can be chosen 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 smaller, whereas if the link is PTMP or broadcast medium, the Maximum
Response Delay can be configured larger. Response Delay can be configured larger.
The Maximum Response Delay could be configured by the administrator The Maximum Response Delay could be configured by the administrator
as mentioned above, or be calculated automatically by a software tool as mentioned above, or be calculated automatically by a software tool
implemented according to experiential model for different link modes. implemented according to experiential model for different link modes.
How to determine the instant value of Maximum Response Delay is out How to determine the instant value of Maximum Response Delay is out
of this document's scope. of this document's scope.
3.7. Triggering Reports and Queries quickly during handover 3.6. Triggering Reports and Queries Quickly During Handover
When a mobile terminal is moving from one network to another, if it When a mobile terminal is moving from one network to another, if it
is receiving multicast content, its new access network should try to is receiving multicast content, its new access network should try to
deliver the content to the receiver without disruption or performance deliver the content to the receiver without disruption or performance
deterioration. In order to implement smooth handover between deterioration. In order to implement smooth handover between
networks, the terminal's membership should be acquired as quickly as networks, the terminal's membership should be acquired as quickly as
possible by the new access network. possible by the new access network.
The access router could trigger a Query to the terminal as soon as it The access router could trigger a Query to the terminal as soon as it
detects a new terminal on its link. This could be a General Query if detects a new terminal on its link. This could be a General Query if
skipping to change at page 10, line 27 skipping to change at page 9, line 33
could also be a unicast Query for this incoming terminal to prevent could also be a unicast Query for this incoming terminal to prevent
unnecessary action of other terminals in the switching area. unnecessary action of other terminals in the switching area.
For the terminal, it could send a report immediately if it is For the terminal, it could send a report immediately if it is
currently in the multicast reception state, when it begins to connect currently in the multicast reception state, when it begins to connect
the new network. This helps establishing more quickly the membership the new network. This helps establishing more quickly the membership
state and enable faster multicast stream injection, because with the state and enable faster multicast stream injection, because with the
active report the router does not need to wait for the query period active report the router does not need to wait for the query period
to acquire the terminal's newest state. to acquire the terminal's newest state.
4. Applicability and interoperability considerations 4. Applicability and Interoperability Considerations
Among the optimizations listed above, 'Switching between unicast and Among the optimizations listed above, 'Switching between unicast and
multicast Queries'(3.2) and 'General Query Supplemented with Unicast multicast Queries'(3.1) and 'General Query Supplemented with Unicast
Query'(3.3) require a router to know beforehand the valid members Query'(3.2) require a router to know beforehand the valid members
connected through an interface, thus require explicit tracking connected through an interface, thus require explicit tracking
capability. "Minimizing Query Frequency by increasing intervals" capability. An IGMP/MLD implementation could choose any combination
(3.1) is only meaningful when for the same network condition the of the methods listed from 3.1 to 3.6 to optimize multicast
retransmission count for a fixed interval is not small (more than the communication on a specific wireless or mobile network.
default value of 2). An IGMP/MLD implementation could choose any
combination of the methods listed from 3.1 to 3.7 to optimize
multicast communication on a specific wireless or mobile network.
For example, an explicit-tracking IGMPv3 router, can switch to For example, an explicit-tracking IGMPv3 router, can switch to
unicast General Query if the number of members on a link is small unicast General Queries if the number of members on a link is small
(3.3), can trigger unicast Query to a previously valid receiver if (3.1), can trigger unicast Query to a previously valid receiver if
failing to get expected responses from it (3.3), can retransmit a failing to get expected responses from it (3.2), can retransmit a
General Query if after the previous one cannot collect reports from General Query if after the previous one cannot collect reports from
valid members (3.4), and can stop sending a General Query when the all valid members (3.3), and can stop sending a General Query when
last member leaves the group (3.5), and etc. the last member leaves the group (3.4), and etc.
For interoperability, it is suggested if multiple multicast routers For interoperability, it is required if multiple multicast routers
are connected to the same network for redundancy, each router are are connected to the same network for redundancy, each router are
configured with the same optimization policy to synchronize the configured with the same optimization policy to synchronize the
membership states among the routers.. membership states among the routers.
5. IANA Considerations 5. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
6. Security Considerations 6. Security Considerations
 End of changes. 31 change blocks. 
137 lines changed or deleted 87 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/