Network working group H. Liu
Internet Draft Q. Wu
Category: Informational Huawei Technologies.
Created: March 8, 2010 H. Asaeda
Expires: September 2010 Keio Universitys
TM. Eubanks
Iformata Communications
Mobile and Wireless Tuning Requirements on IGMP/MLD Protocols
draft-liu-multimob-igmp-mld-mobility-req-03
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Liu and etc. Expires September 8, 2010 [Page 1]
Internet-Draft IGMP and MLD Requirements for Mobility March 2010
This Internet-Draft will expire on August 15, 2009.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document.
Abstract
This document presents the requirements for IGMP/MLD protocols to
allow the deployment of mobile multicast service. It is intended to
provide useful guideline when adapting current IGMP/MLD protocols to
support terminal mobility.
Conventions used in this document
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 [RFC2119].
Table of Contents
1. Introduction................................................. 3
2. Problem Statement ........................................... 3
3. The Behavior of IGMP and MLD Protocols....................... 5
3.1. IGMP Version 1.......................................... 5
3.2. IGMP Version 2.......................................... 5
3.3. IGMP Version 3.......................................... 6
3.4. Multicast Listener Discovery Protocols.................. 7
3.5. Lightweight IGMPv3/MLDv2................................ 7
4. Requirements for Wireless and Mobile Multicast............... 7
4.1. Functional Requirements for Mobile Multicast............ 7
4.2. Requirements on Tuning IGMP/MLD Protocol Parameters .... 8
4.3. Requirements for Handover............................... 9
4.4. Requirements for Wireless Link Types................... 10
4.5. Requirements for Explicit Tracking .................... 11
5. IGMP/MLD Tuning Requirements for Mobility and Wireless
Environment.................................................... 11
Liu and Etc. Expires September 8, 2010 [Page 2]
Internet-Draft IGMP and MLD Requirements for Mobility March 2010
5.1. Evaluation of Current Features of IGMP and MLD Protocols11
5.2. IGMP and MLD Protocol for Wireless or Mobile Network... 12
6. Security Considerations..................................... 14
7. References.................................................. 14
7.1. Normative References................................... 14
7.2. Informative Referencess ............................... 15
Authors' Addresses............................................. 16
1. Introduction
IP multicast efficiently distributes data to a number of receiver
hosts in IP networks simultaneously thereby saving network and
server resources. The receiver hosts use IGMP for IPv4 [2] and MLD
for IPv6 [3] to receive or to stop receiving data via multicast
(using join/leave or a subscribe/unsubscribe requests). The
intermediate routers construct multicast tree between the source and
receiver hosts with multicast routing protocols.
IGMP and MLD protocols are originally designed to work on wired
broadcast shared links (e.g. Ethernet) by taking into account the
wired link characteristics. When they are used on a wireless link,
it is necessary to consider how to make the protocols better fit the
properties of the wireless link. In this document, the requirements
for IGMP and MLD protocols that enable mobile multicast services via
a wireless link are discussed. The wireless link type could be but
should not be restricted to 3GPP, IEEE 802.11 and 802.16, which are
or may be popularly adopted in providers' network
IGMP or MLD protocol can work with any mobile protocols (e.g., MIPv6
[9], PMIPv6 [10], NEMO [11]) independently, if these protocols
support multicast. However, context transfer or other procedures to
provide seamless handover depend on the mobile protocols. Therefore,
this document does not assume mobile protocols that mobile hosts use,
and only protocol-independent considerations and requirements
regarding how mobile protocols should work with IGMP/MLD for
seamless handover are discussed.
2. Problem Statement
A mobile host usually accesses to a network via a wireless link.
When a mobile host wants to join or leave an IP multicast session,
it sends IGMP/MLD messages for the request to its upstream equipment.
The upstream equipment may be a wireless access router (in case of
MIPv6), a mobile router (in case of NEMO), a gateway (in case of
PMIPv6), or a switch or router that supporting IGMP/MLD Proxy. In
Liu and Etc. Expires September 8, 2010 [Page 3]
Internet-Draft IGMP and MLD Requirements for Mobility March 2010
the following part of this document, it is expressed as an "upstream
router" or "multicast router".
The upstream router should maintain the group membership states
indicating which multicast sessions mobile hosts have joined and
constructs the multicast tree towards the source with multicast
routing protocol procedures. If upstream wireless routers or
switches are wireless and do not maintain this group membership
states, they will flood all multicast data received onto each
wireless link, which is not an efficient use of wireless bandwidth
resources. Thus IGMP and MLD protocols are necessary to be
supported on the mobile and wireless hosts and their upstream
routers.
Apart from the above general wireless link characteristic, different
wireless technique exhibits different features. For the purpose of
generality, this memo does not concentrate on a specific wireless
link layer protocol, but rather focus on the popular link model
being abstracted from currently in-used wireless techniques, such as
IEEE 802.11x, IEEE 802.16x, 3GPP,and etc.
According to the properties of a wireless link, bandwidth usage and
packet loss should be carefully considered. It is also necessary to
take care of battery consumption of a mobile host. These conditions
encourage the minimization of exchanged data packets and control
messages including IGMP/MLD protocol messages if possible.
On the other hand, IGMP and MLD are asymmetric and non-reliable
protocols; multicast routers need solicited membership reports by
periodical IGMP/MLD Queries, in order to be robust in front of host
or link failures and packet loss. It is encouraged that host-and-
router communication is effectively coordinated to support limited
wireless or terminal resources.
When a host receiving multicast data moves from an access link to
another one, the host wants to continuously receive the multicast
data without any packet loss and session interruption, and the
network provider wants to minimize the amount of duplicated
multicast traffic. This seemless handover is a necessary component
of mobile multicast communication, which introduces additional
requirements on IGMP/MLD protocols during handover. Precisely, the
moving host's membership information should be transmitted to the
new access link as quickly as possible. This procedure reduces the
host's join latency. Or, if there is no member host on the access
link after the host moves, then the upstream router should leave
Liu and Etc. Expires September 8, 2010 [Page 4]
Internet-Draft IGMP and MLD Requirements for Mobility March 2010
from the multicast session quickly as well. This contributes to
releasing the unnecessary resources.
All the above problems stated above together with others are to be
discussed in this memo. In the following sections, we briefly
introduce the IGMP/MLD protocols, analyze the protocol behavior and
the requirements of wireless link characteristic and IP multicast
mobile service, and discuss the possibility of the enhancement of
the protocols if needed. The illustration below will consider both
IPv4 and IPv6 networks.
3. The Behavior of IGMP and MLD Protocols
A multicast receiving host uses IGMP protocols to join and leave a
multicast group on an IPv4 network, and uses MLD protocols on an
IPv6 network.
3.1. IGMP Version 1
IGMP Version 1 [5] defines the basic operating model between a
multicast receiving host and its upstream router to determine group
membership. The router periodically sends Host Membership Queries
to its attached network. A host sends a Host Membership Report to
the router when it decides to join a group, or it responds to the
Queries passively. The host does not send group leave message
explicitly, but rather silently leaves the group by ignoring a Host
Membership Query, which causes an undesirably long leave latency.
IGMPv1 is an obsolete protocol; hence it is not recommended for
mobile hosts to implement IGMPv1, whereas upstream routers may need
to support IGMPv1 to keep compatibility with non-upgraded mobile
hosts.
3.2. IGMP Version 2
IGMP Version 2 [6] has the optimizations that an IGMPv2 host can
explicitly send a Leave Report when it decides to stop receiving
multicast data. This enables faster leave from the multicast group.
When a multicast router receives a leave message, it will generate a
Group-Specific Query to verify whether there is other receiver for
the same group on its network. IGMPv2 also supports the case when
multiple multicast routers are connected to the same shared network.
In this case, a single Querier is elected by ordering the IP
addresses to take on the duty of sending Query packets.
Liu and Etc. Expires September 8, 2010 [Page 5]
Internet-Draft IGMP and MLD Requirements for Mobility March 2010
Several timers are defined in IGMPv2 and their values are
configurable. Query Interval is the interval between General
Queries sent by a router, which has influence on the total number of
IGMPv2 messages on a link. Query Response Interval is the maximum
response time of a report after a host receives the General Query.
It will reduce the bursty traffic of the reports on a link. Startup
Query Interval is the interval between the queries sent by the
Querier in startup. Last Member Query Interval is the maximum
response time used by Group-Specific Queries in response to leave
from session. This value can be tuned to modify the leave latency
of the network.
IGMPv2 also introduces timer related counters to make the protocol
function more robust. For example, it defines Robustness Variable
to quantify the number of reports sent out to prevent packet loss.
Last Member Query count is used to set the number of Group-Specific
Queries sent before the router assumes there is no local member.
Startup Query Count is the number of Queries issued on startup.
These values can be tuned according to the expected packet loss on a
link.
3.3. IGMP Version 3
IGMP Version 3 [2] introduces a big enhancement to the previous two
versions. It defines INCLUDE and EXCLUDE filter modes on both the
host and router side. With these filter modes, a host can specify
the desired or undesired source address(es) except for multicast
address(es) in IGMP report messages.
IGMPv3 router uses filter mode to process the group record properly.
The router also maintains a group-timer to indicate the filter mode
switch over and a source-timer to time each valid source. A new
type of Source-and-Group-Specific Query is utilized to verify there
are no receivers desiring to receive traffic from listed sources for
a particular group, which has been requested to no longer be
forwarded.
Another modification is that IGMPv3 does not adopt the report
suppression mechanism. Without suppression, the number of report
messages may increase greatly on a link. IGMPv3 solves this problem
by merging reports or queries into a combined packet.
An advantage of eliminating report suppression is that it provides
the possibility for the router to keep track of host membership
status on a link. This Explicit Tracking [2] consumes memory on the
Liu and Etc. Expires September 8, 2010 [Page 6]
Internet-Draft IGMP and MLD Requirements for Mobility March 2010
router, but provides feasibility to manage end users on a per-user
basis and implements fast leave function.
3.4. Multicast Listener Discovery Protocols
MLDv1 and MLDv2 are respectively derived from IGMPv2 and IGMPv3 to
be applied for IPv6 networks. The important difference between MLD
and IGMP is that MLD is a sub-protocol of ICMPv6 and its message
types are a subset of ICMPv6 messages. For MLDv1, parts of the
message types are renamed to distinguish from those of IGMPv2.
3.5. Lightweight IGMPv3/MLDv2
IGMPv3 and MLDv2 enable the support of Source-Specific Multicast
(SSM) communication [8] by indicating desired sources in the INCLUDE
Group Record. Its usage of excluding undesired sources by an
EXCLUDE filter mode operation has little practical prototype use and
no desired use case. Moreover, when a host requests to join or
leave session whose operation changes INCLUDE filter mode to EXCLUDE
filter mode or vise versa, both the host and the upstream router
will suffer from complex state transition and scalability problems.
In [4], simplified version protocols of IGMPv3/MLDv2 are defined to
keep the INCLUDE source-filtering characteristics to support SSM
communication and remove the EXCLUDE filter mode operation. With
the reduced number of report types and and without the filter-mode
related processing,the host-side kernel implementation and
especially the router's operation are greatly simplified, and less
states need to be stored by lightweight router compared to their
full IGMPv3/MLDv2 counterpart. These improvements are especially
desirable for multicast mobility, as wireless devices typically have
limited storage and CPU processing capabilities.
4. Requirements for Wireless and Mobile Multicast
4.1. Functional Requirements for Mobile Multicast
Any-Source Multicast (ASM) is a traditional multicast communication
model in which receivers requests all data from a multicast address,
which is denoted with (*,G). A host joining a (*,G) session will
receive data from all the sources sending to the specified multicast
address. On the other hand, in the SSM communication, a host
specifies both source and multicast addresses and receives the
traffic from the specified source(s). The subscribed source-
specific multicast session is denoted by an (S,G) and called a
channel.
Liu and Etc. Expires September 8, 2010 [Page 7]
Internet-Draft IGMP and MLD Requirements for Mobility March 2010
All the versions of IGMP/MLD support the ASM communication. It is
not recommended to use IGMPv1 in mobile communications since it does
not have a robust mechanism to retransmit report messages, does not
provide fast leave, and does not support SSM, as described in
Section 2. IGMPv2 and MLDv1 are possible to be used in mobile
communications, but they do not support SSM subscription.
To enable the SSM communication, a mobile host must use IGMPv3/MLDv2
or LW-IGMPv3/LW-MLDv2. As described in [4], there is no functional
difference to subscribe (S,G) channels between the full versions of
IGMPv3/MLDv2 and the lightweight version protocols. The lightweight
version protocols have the advantage of simpler processing.
IGMP/MLD protocols (except IGMPv1) protocols themselves implement
some fast join and fast leave functions. When a host joins a
multicast session, it sends unsolicited join report to its upstream
router immediately. The Startup Query Interval has been set to 1/4
of the General Query value to enable the faster join at startup.
When the host ceases from listening a session, it sends a request to
leave the session immediately. The Group-Specific or Source-and-
Group-Specific Queries are triggered when an IGMP/MLD router knows
that the reception for a group or a source-specific group has been
terminated. This helps the router acquire the multicast membership
information as fast as possible when all the members as a whole
leave a group. The time to complete leaving from a session is
referred to as leave latency. Lower leave latency (i.e. fast leave)
has the advantage of quickly releasing the network resources.
4.2. Requirements on Tuning IGMP/MLD Protocol Parameters
Within each protocol's scope, the number of transmitted packets on a
wireless link could be further decreased by tuning timer values.
For example, Query Interval can be set to a larger value to reduce
the packet quantity. The Query Response interval could be widened
to avoid the burst of messages.
On the other hand, to cover the possibility of a State-Change Report
being missed by one or more multicast routers, a host transmits the
same State-Change Report [Robustness Variable] times in all [2][3].
However, this manner does not only guarantee that the State-Change
Report is reached to the routers, but also increases the number or
amount of State-Change Report messages on a wireless link. It is
required to tune these values with the good balance of protocol
robustness and the amount of traffic.
Liu and Etc. Expires September 8, 2010 [Page 8]
Internet-Draft IGMP and MLD Requirements for Mobility March 2010
As well, various IGMP/MLD timers should be configurable. If non-
default settings are used, they MUST be consistent among all routers
on a single network.
4.3. Requirements for Handover
[12] categorized the diversified mobile IP schemes by their group
subscription manner principally as home subscription and remote
subscription. These two different subscription has important
influences on the handover behaviour. Since different mobile and
handover protocols may need different parameters and different
optimizations, this document describes the possible scenarios with
examples in MIPv6 [9] but only discussed the possible requirements
related to the group-subscription related behavior.
In home subscription (also referred to tunneled method), the
IGMP/MLD message should be encapsulated and tunneled to the home
network. The multicast router (e.g., Home Agent) on home network
will be responsible for joining and pruning a multicast tree. When
a mobile host moves to a new foreign network, it does not need to
re-join the multicast group.
In the remote subscription approach (also referred to optimal
multicast routing), a mobile host joins the group via a local
multicast router on the foreign network. The router intercepts the
host's report message and joins or prunes the multicast tree on the
foreign network. After handover to another foreign network, the
host needs to resend new reports to new access routers and the
latters will construct the new multicast tree on the new network.
If the old multicast branches have been torn down before the new
branches being constructed, the host will suffer from packets loss
during the handover.
To prevent packet loss, a make-before-break mechanism SHOULD be
provided. It requires a mobile host to join the group on the new
network as soon as possible once it decides to switch to the new
network. The host keeps the reception of the "old" multicast data
until the traffic from new branches arrives. Then the host begins
issuing leave reports to the previous attached multicast router.
The possibility of packet loss can be reduced by predicting the
movement of a mobile node during handover. The handover can be
initiated either by the mobile host or by the network. In the
mobile-initiated handover, the host acquires the handover
information quickly and can send early reports. In the network-
Liu and Etc. Expires September 8, 2010 [Page 9]
Internet-Draft IGMP and MLD Requirements for Mobility March 2010
initiated handover, the network entity indicates the possible
handover situation and the mobile host does not invoke any process.
It may be possible that IGMP and MLD could be extended to carry the
handover indication from a previous router to a new router to
facilitate the fast join and fast leave. Since IGMP/MLD protocol or
message extension may require additional operational costs or
interoperability problems, it must be carefully defined.
IGMP/MLD hosts and routers can adjust their timer and counter values
to make faster join/leave during handover, as described in Section
4.2. The adjustment is carried out by the application according to
the actual wireless situations and policies of the management.
4.4. Requirements for Wireless Link Types
Wireless access technique could be categorized to three different
types - shared, point-to-point (PTP), and point-to-multipoint (PTMP)
links. The shared link (e.g.IEEE802.11) resembles Ethernet that the
end-users share the same wireless media. IGMP/MLD should be
generally applicable because they are originally designed for the
shared Ethernet.
For PTP link (e.g.3G GSM, IEEE802.16), different links are separated
physically or logically from each other. The standard use of IGMP
and MLD requires the multicast router to maintain a separate
interface state for each link. It will be inefficient if the number
of the receiver becomes large. Considering there is only one
receiving host on each link, the operation of IGMP/MLD relating to
multiple receivers per interface should be taken out. For example,
Host Suppression and Delaying Response are unnecessary. Instead the
mobile could respond the reports immediately, which helps
implementing faster join and leave capability. Besides, when a host
requests its leave from the group, the successive Group-Specific
Query or Group-and-Source-Specific Query to inquire other possible
receivers is not needed. Finally, the periodic General Query which
is sent separately to each mobile host, is unnecessary to be sent to
all the links but rather only to the hosts which have made the group
join and have reception state on the router. This is desirable for
the battery saving for the mobile terminal not involved in the
multicast reception will not be frequently awakened when in the
sleeping mode.
Wireless PTMP links (e.g.3GPP MBMS, and IEEE 802.16) is point-to-
multipoint (or shared) in down link direction, but point-to-point in
up link direction. The IGMP/MLD protocols should present both
Liu and Etc. Expires September 8, 2010 [Page 10]
Internet-Draft IGMP and MLD Requirements for Mobility March 2010
shared media and point-to-point media features. Host Suppression
and Delaying Response should not be adopted. Group-Specific Query
and Group-and-Source-Specific Query triggered by group leave are
also unnecessary. And General Query should be multicast to the
shared down link, which is the same as the shared link model but
different from the PTP link.
4.5. Requirements for Explicit Tracking
Since the full and lightweight IGMPv3 and MLDv2 protocols disable a
report suppression mechanism (described in Section 3.3), multicast
routers working with these protocols can choose to implement
explicit tracking of mobile hosts [2]. The explicit tracking
enables the router to learn the reception state of each receiver,
but at the meantime consumes substantial memory resources on the
router.
The advantage of explicit tracking is that it provides better
manageability of mobile receivers. It is unnecessary to issue
Group-Specific queries and Source-Specific Queries to stop receiving
on subnets whose router keeps track of group and source receivers.
5. IGMP/MLD Tuning Requirements for Mobility and Wireless Environment
5.1. Evaluation of Current Features of IGMP and MLD Protocols
To evaluate whether IGMP and MLD protocols are applicable to
wireless communication, their key features should be analyzed
regarding their functionality, reliability and efficiency.
IGMP/MLD join and leave are sent unsolicitedly when a host intends
to join or leave a group. They are closest to user's experience and
must be guaranteed. Current IGMP and MLD provide the reliability
for these packets by retransmission for [Robustness Variable] times.
Retransmission provides reliability to some degree but if in most
cases the first packet is a success, the other retransmissions are a
waste of resources. In other cases if all the retransmission fail
the host has no indication of the situation. Besides, it is
troublesome to determine the value of [Robustness Variable], for the
wireless link condition may alter from time to time and a host may
change its connection from one access network to another. Thus it
is required that the transmission reliability for IGMP/MLD join and
leave should be enhanced to improve the user experience.
IGMPv2 and MLDv1 only support ASM communication mode, but does not
support SSM subscription and explicit tracking, which limits their
Liu and Etc. Expires September 8, 2010 [Page 11]
Internet-Draft IGMP and MLD Requirements for Mobility March 2010
widespread deployment in future multicast network. IGMPv3 and MLDv2
(and also LW-IGMP/LW-MLD) support all the features of ASM and SSM
communication, and of explicit tracking. They are much better the
candidates for wireless and mobile networks than their previous
versions. The disadvantage of (LW-) IGMPv3 and MLDv2 is that
because host suppression is not available, the report count in
response to query is not a small number, if there are many active
receivers on the network. Even though the protocols enable a host
to utilize combined report to reduce the packet number, further
optimization is still required to efficiency the bandwidth usage.
As the summary, IGMP and MLD for wireless or mobile network should
have the following ideal characteristics:
o ASM and SSM mode support
o Explicit tracking[2]
o Enhanced robustness.
O Minimized packet transmission and packet burst
5.2. IGMP and MLD Protocol for Wireless or Mobile Network
(LW-) IGMPv3/MLDv2 are suggested to be used as the basis for
optimization for wireless and mobile networks, because they are more
applicable to current multicast scenarios, as illustrated in section
5.1. Apart from the parameter tuning (in section 4.2), there are
several other measures which are suggested to be used when make this
adaption.
5.2.1 Robustness Enhancement for unsolicited report
For the reasons given in section 5.1, acknowledge-retransmission is
suggested to be used for a unsolicited (LW-) IGMPv3/MLDv2 Report
[ACK-draft], whose mechanism is commonly deployed in today's
protocol design. Its basic protocol behavior is direct and simple.
A host after sending a join report starts a retransmission timer and
waits for the acknowledgement (ACK) from the router. If the ACK is
not received when the timer expires, another report is retransmitted.
A parameter should also be used to limit the maximum retransmission
times for the report.
5.2.2 Efficiency Considerations for Passive Report
Liu and Etc. Expires September 8, 2010 [Page 12]
Internet-Draft IGMP and MLD Requirements for Mobility March 2010
Passive reports in response to Queries are not acknowledged for not
introducing too many report packets on the network, and they are not
acknowledged also because the Query-Response to-and-fro implies an
acknowledgement to some degree.
Further, if the number of the receivers on a network is large, it is
suggested that Queries are sent only once, rather than for
[Robustness Variable] times. This is because each turn of Query
will trigger all active members' response, which is not an efficient
usage of bandwidth resources.
The passive report manner could also be optimized for PTP and PTMP
link types. Because these two types of links are not shared (or
exclusive) for the end users, the Delayed Response which prevent
report collision on a link is not necessary. Without Delayed
Response, the report could be responded to the router immediately,
and it is much easier to implement robust enhancement for passive
Report and for a Query, as shown in section 5.2.3 and 5.2.5.
5.2.3 Robustness Considerations for Passive Report
If in some cases a host's response report is lost due to bad
transmission condition, there is still some remedy that can tackle
this issue.
For example, a router after sending a Query collects successfully
all the members' report responses except for other one or two which
are kept in its database. This may be because the non-response ones
silently leave the network without any notification, or because
their reports are lost for unreliable transmission. The router in
this case could unicast respectively to each non-respondent receiver
to check whether they are still alive for the multicast service
reception. Unicast Query is different from normal group queries for
its destination address is set to the unicast address of a receiver
[13].
5.2.4 Efficiency Enhancement of Queries
[14] discusses several processing for reducing Queries when mobile
receiver is on the foreign network, e.g. attenuating the Queries on
the home network when the router on the remote network process the
receiver's report, and the stopping or resuming of Queries under
specific conditions. Irrespective of the mobile receivers' position,
there are still some optimizations that might be usable for
minimization the packet transmission.
Liu and Etc. Expires September 8, 2010 [Page 13]
Internet-Draft IGMP and MLD Requirements for Mobility March 2010
First, if explicit tracking is used, the router is able to keep all
active members state for reception. The Group Specific and Source-
and-Group Specific Queries, which are sent to query other members
when a member leaves a group or a source-specific group, are
unnecessary because the router knows who are active on the link
through explicit tracking. Thus it is suggested that when explicit
tracking is used, only periodical query is sent.
Further, to reduce the packet burst on link with large number of
receivers, the router can limited its scope of its periodical
Queries. For example, if the receiver number is small, the
periodical General Queries for all multicast receivers is enough.
If the multicast receiver on a link is large, the router could
periodically send Group Queries to a group or send Source-Group
Specific Queries to a source-group. In this case the router tunes
its behavior by sending these two Queries periodically instead of
triggering them when a member leaves.
5.2.5 Robustness Enhancement of Queries
If the Query is tuned for wireless network by sending only once, as
shown in section 5.2.2, the reliability of the query behavior is
weaker than wired IGMPv3/MLDv2. In fact, this situation could also
be improved by tuning a router's behavior. A router which keeps
track of all its active receivers, if after sending a Query, fails
to get any response from any receiver, it can derive that its just-
sent Query might have been lost before reaching other end of the
link. The router could choose to compensate this situation by
sending another Query to query its members.
6. Security Considerations
Apart from the security issue of IGMP/MLD, additional requirements
should be considered for the features of the wireless link. They
will be described in the later version of this draft.
7. References
7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", RFC 2119, March 1997.
[2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version 3", RFC
3376, October 2002.
Liu and Etc. Expires September 8, 2010 [Page 14]
Internet-Draft IGMP and MLD Requirements for Mobility March 2010
[3] Vida, R. and L. Costa, "Multicast Listener Discovery Version
2(MLDv2) for IPv6", RFC 3810, June 2004.
[4] Liu, H., Cao, W., and H. Asaeda, "Lightweight IGMPv3 and MLDv2
Protocols", RFC5790, September 2008.
[5] Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
August 1989.
[6] Fenner, W., "Internet Group Management Protocol, Version 2", RFC
2236, November 1997.
[7] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999.
[8] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP",
RFC 4607, August 2006.
7.2. Informative Referencess
[9] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[10] Gundavelli, Ed., S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[11] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January
2005.
[12] Romdhani, I., Kellil, M., and H. Lach, "IP Mobile Multicast:
Challenges and Solutions", IEEE Comm. Surveys 6(1), 2004.
[13] H. Asaeda, "IGMP and MLD Optimization for Mobile Hosts and
Routers", draft-asaeda-multimob-igmp-mld-optimization-01,work in
progress,2010.
[14] I. Romdhani, J. Munoz, H. Bettahar, and A. Bouabdallah,
"Adaptive Multicast Membership Management for Mobile Multicast
Receivers", IEEE, 2006.
Liu and Etc. Expires September 8, 2010 [Page 15]
Internet-Draft IGMP and MLD Requirements for Mobility March 2010
Authors' Addresses
Hui Liu
Huawei Technologies Co., Ltd.
Huawei Bld., No.3 Xinxi Rd.
Shang-Di Information Industry Base
Hai-Dian Distinct, Beijing 100085
China
EMail: Liuhui47967@huawei.com
Qin Wu
Huawei Technologies Co., Ltd.
Site B, Floor 12, Huihong Mansion, No.91 Baixia Rd.
Nanjing, Jiangsu 21001
China
Phone: +86-25-84565892
EMail: sunseawq@huawei.com
Hitoshi Asaeda
Keio University
Graduate School of Media and Governance
5322 Endo
Fujisawa, Kanagawa 252-8520
Japan
EMail: asaeda@wide.ad.jp
URI: http://www.sfc.wide.ad.jp/~asaeda/
T.M. Eubanks
Iformata Communications
130 W. Second Street
Dayton, Ohio 45402
USA
Phone: +1 703 501 4376
EMail: marshall.eubanks@iformata.com
URI: http://www.iformata.com/
Liu and Etc. Expires September 8, 2010 [Page 16]