MULTIMOB Group H. Liu
Internet-Draft Huawei Technologies Co., Ltd.
Expires: May 15, 2008 H. Asaeda
Keio University
November 12, 2007
Mobile Multicast Requirements on IGMP/MLD Protocols
draft-liu-multimob-igmp-mld-mobility-req-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on May 15, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Liu & Asaeda Expires May 15, 2008 [Page 1]
Internet-Draft IGMP and MLD Requirements for Mobility November 2007
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.
Liu & Asaeda Expires May 15, 2008 [Page 2]
Internet-Draft IGMP and MLD Requirements for Mobility November 2007
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 [1].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
3. The Behavior of IGMP and MLD Protocols . . . . . . . . . . . . 6
3.1. IGMP Version 1 . . . . . . . . . . . . . . . . . . . . . . 6
3.2. IGMP Version 2 . . . . . . . . . . . . . . . . . . . . . . 6
3.3. IGMP Version 3 . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Multicast Listener Discovery Protocols . . . . . . . . . . 7
3.5. Lightweight IGMPv3/MLDv2 . . . . . . . . . . . . . . . . . 8
4. Requirements for IGMP/MLD to support IP multicast mobility . . 9
4.1. General Evaluation of IGMP/MLD Protocols in mobile
environments . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Requirements on the Tuning of IGMP/MLD Protocol
Parameters . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Requirements on IGMP/MLD during handover . . . . . . . . . 10
4.4. Requirements on large number of point-to-point link . . . 11
4.5. Requirements for Explicit Tracking . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Normative References . . . . . . . . . . . . . . . . . . . 14
6.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Liu & Asaeda Expires May 15, 2008 [Page 3]
Internet-Draft IGMP and MLD Requirements for Mobility November 2007
1. Introduction
With the increasing demand for the Internet broadband video service,
IP multicast has more potential to be widely deployed to improve
bandwidth efficiency. It is even desirable if the consumers can
obtain such service while they are in the moving state. Much efforts
have been taken to integrate IP multicast technology with current
mobility IP mechanism to make a feasible solution.
IP multicast is defined for the transmission of an IP datagram from a
multicast source to a host group. The end host uses IGMP for IPv4
and MLD for IPv6 to subscribe or unsubscribe a group. The
intermediate routers construct multicast tree between the source and
the receiving hosts with multicast routing protocols.
The IGMP and MLD protocol are natively designed for the fixed
network. Even though the protocols are thought to be applicable also
to the mobile or wireless environments, their protocol manner should
be carefully evaluated whether they are completely suitable or should
make some extension or modifications in these situations.
In this draft, the requirements of mobile multicast service imposing
on the IGMP/MLD group subscription mechanism are discussed in detail.
Liu & Asaeda Expires May 15, 2008 [Page 4]
Internet-Draft IGMP and MLD Requirements for Mobility November 2007
2. Problem Statement
IP Multicast mobility generally is characterized by receiver
mobility, source mobility and network mobility. The receiver
mobility is our discussion focus because it has more promising
application scenarios, exhibits less deployment complexity, and has
more influence on the operation of IGMP/MLD protocols.
A mobile host usually accesses to the network via wireless connection
where bandwidth efficiency, packet loss under bad conditions,
security issues due to interception and attack should be seriously
considered. And a mobile terminal cares much about its battery
consumption. All these require the IGMP/MLD protocols to be as
compact as possible.
When the receiving host moves from one network to another, it
sometimes need to re-subscribe the multicast group. The handover
will introduce extra packet loss and session disruption. This
requires the IGMP/MLD to make group join and leave operation as
quickly as possible to accelerate the reconnection and release the
unnecessary link resources.
In the following part of this draft, we first introduce the IGMP/MLD
protocols, then analyze whether their protocol behavior can meet the
requirements of IP multicast mobile service, and if needed, discuss
the possibility of the modification or extension of the protocols.
The illustration blow will consider both IPv4 and IPv6 networks.
Liu & Asaeda Expires May 15, 2008 [Page 5]
Internet-Draft IGMP and MLD Requirements for Mobility November 2007
3. The Behavior of IGMP and MLD Protocols
A multicast receiving host using IGMP protocols to join and leave a
multicast group on an IPv4 network, and using MLD protocols on an
IPv6 network.
3.1. IGMP Version 1
IGMP Version 1 [4] defines the basic operating model between the
multicast receiving host and its upstream router to determine group
membership. The router periodically launches General Group Queries
to its attached subnet. An host sends an IGMP Report to the router
when it decides to join a group, or it responds to the Queries
passively.
IGMPv1 introduces two specific mechanisms to avoid the implosion of
concurrent reports when the host answers the Group Query - delaying
response and suppressing reports. Delaying response means when a
host receives a Query, it does not respond with a report immediately,
but rather waits a random period of time. Suppression means the host
will withdrawn its own report when it hears a report from other host
joining the same group. It is impossible for the multicast router to
track per host status for the suppression of the group report.
IGMPv1 host does not send group leave message explicitly. It
silently leaves the group by initiating no report when receiving
Group Query.
3.2. IGMP Version 2
IGMP Version 2 [5] makes a series of optimization to improve the
performance of IGMPv1. First, the IGMPv2 explicitly sends a leave
report when it decides to stop receiving from a group, which enables
fast leaving of a multicast group. Further, when a multicast router
receives such leave message, it will generate a Group-Specific Query,
which helps the router to further determine whether there is other
receiver for this group on its network. The third optimization lies
in that IGMPv2 can support more complicated networking when multiple
multicast routers connected to the same network. In this case a
single Querier is elected by ordering the addresses to take on the
duty of sending Query packets.
Several timers are defined with their values configurable. Query
Interval is the interval between General Queries sent by a router,
which has influence on the total number of IGMPv2 messages on the
subnet. Query Response Interval is the maximum response time of a
report after the host receiving the General Query. It helps reduce
the burst of the reports on a subnet. Startup Query Interval is the
Liu & Asaeda Expires May 15, 2008 [Page 6]
Internet-Draft IGMP and MLD Requirements for Mobility November 2007
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 group leave. 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 robustly. 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 are no local members.
Startup Query Count is the number of Queries issued on startup. The
above values could be tuned according to the expected packet loss on
a subnet.
3.3. IGMP Version 3
IGMP Version 3 [2] introduces a big enhancement to the previously two
versions. It defines INCLUDE and EXCLUDE filter-mode on both the
host and router side. Using this filter mode, the host can specify
the source list information in its group report.
IGMPv3 router uses filter-mode to process the group record properly.
The router also maintain a group-timer to indicate the filter mode
switchover 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 use host suppression,
because the various packet type and the diverse information carried
in the report make it rather difficult to define a uniform
suppression policy. Without suppression, the number of packet may
increase greatly on the subnet. IGMPv3 solves this problem by make
pending reports or queries merged into a combined packet.
An advantage for non-suppression is that it provide the possibility
for the router to keep the receiving status of each individual
member, which is known as Explicit Tracking. The tracking consumes
much more memory on the router, but provides feasibility to manage
end users.
3.4. Multicast Listener Discovery Protocols
MLD1 and MLDv2 are respectively derived from IGMPv2 and IGMPv3 to be
used for IPv6 host and router. The most important difference between
MLD and IGMP is that MLD use ICMPv6 message format. For MLDv1 parts
of the message types are renamed to distinguish from those of IGMPv2.
Liu & Asaeda Expires May 15, 2008 [Page 7]
Internet-Draft IGMP and MLD Requirements for Mobility November 2007
3.5. Lightweight IGMPv3/MLDv2
IGMPv3 and MLDv2 are very complex for the processing compared to
their previous versions, which hindered the protocols from being
deployed as expected to some degree.
IGMPv3 supports the Source-Specific Multicast (SSM) communication [7]
by including sources in the INCLUDE Group Record. But its usage of
excluding undesired sources in EXCLUDE mode has little practical
prototype, whereas has the major contribution of processing
complexity.
In [8], a simplified version of IGMPv3 is defined to keep the INCLUDE
source-filtering characteristics to support SSM communication, while
removing EXCLUDE source-filtering operation. The report types are
reduced and the router part operation is greatly simplified.
Besides, less states need to be stored by lightweight router compared
to their full IGMPv3/MLDv2 counterpart.
Liu & Asaeda Expires May 15, 2008 [Page 8]
Internet-Draft IGMP and MLD Requirements for Mobility November 2007
4. Requirements for IGMP/MLD to support IP multicast mobility
4.1. General Evaluation of IGMP/MLD Protocols in mobile environments
As mentioned in Section 3, bandwidth efficiency and security require
the compactness of the IGMP/MLD protocols. This compactness means
IGMP/MLD should minimize the packet interchanging between the mobile
host and the multicast router.
Considering the traditional multicast communication, called Any-
Source Multicast (ASM), and SSM communication model, an ASM host can
receive all the traffic from all the sources sending to the group,
while an SSM host receives the traffic from a source through the
subscribed (S,G) channel. The former is prone to interception and is
more possible to import unnecessary multicast traffic onto local
network, whether the host is willing to receive them or not. So from
the mobile edge's prospective, SSM is a favorable choice to provide
mobile multicast service.
All the versions of IGMP/MLD support the ASM scenarios. Even though
IGMPv1 has least packet transmission, but since it has no robust
mechanism required in unreliable wireless situations, it should not
be considered as an applicable solution. IGMPv2 and MLDv1 are more
concise compared with IGMPv3/MLDv2 for its host suppression
operation. But they do not support SSM subscription, thus have
little potential to be widely deployed.
When using SSM communication model, the mobile host can use IGMPv3/
MLDv2 and LW-IGMPv3/LW-MLDv2 to subscribe a SSM group. There is no
packet overhead difference between the two protocols in both ASM and
SSM reception model. The lightweight versions have the advantage of
simpler processing.
IGMP/MLD protocols (except for IGMPv1) adopt some measures to
implement fast join and leave for a group. When a host intends to
join a group, it sends unsolicited report immediately. The Startup
Query Interval has been set to the 1/4 of General Query value to
enable the fast joining at startup. When the host ceases from
hearing from a group, it reports the leaving 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 just been stopped. This helps the router acquire
the information as fast as possible when all the members as a whole
leave a group. The latency of this kind of leaving of all members is
referred to as network latency. Lower latency or faster leave has
the advantage of releasing the network more quickly.
Liu & Asaeda Expires May 15, 2008 [Page 9]
Internet-Draft IGMP and MLD Requirements for Mobility November 2007
4.2. Requirements on the Tuning of IGMP/MLD Protocol Parameters
Within each protocol's scope, the packet number on the network could
be further decreased by tuning the value of the timer. 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, the message robustness requires some type of
messages are transmitted more than once. Robust Variable is defined
for IGMP/MLD protocols to adapt to networks of different robustness
degree. It decides the transmitting times of the Startup Query, Last
Member Query and Unsolicited Reports. On lossy subnet, the Robust
Variable should be increased to allow for the expected level of
packet loss.
The 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 on IGMP/MLD during handover
The handover manners are illustrated in diversified mobile IP
multicast schemes. [9] categorized the schemes by their group
subscription manner principally as home subscription-based and remote
subscription based solutions.
In home subscription, the IGMP/MLD message should be encapsulated and
tunneled to the home network. The multicast router (usually 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.
While in the remote subscription approach, the 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. After handover to another foreign network, the hosts
need to resend new reports to the routers on the new network. If the
old multicast branches have been tore down before the new branches
being able to be constructed, the host will suffer from packets loss
during the handover.
To prevent the possible packets loss, make-before-break mechanism
should be provided. This requires the IGMP/MLD mobile host to join
the group on the new network as soon as possible once it decides to
switch onto 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
Liu & Asaeda Expires May 15, 2008 [Page 10]
Internet-Draft IGMP and MLD Requirements for Mobility November 2007
multicast router.
The mobile host can further benefit less packet loss from prediction
of the handover. The detection and handover can be initiated either
by the mobile host or by the network part. In the mobile-initiated
handover, the host acquires the handover information quickly and can
send early reports. While in the network-initiated handover, the
network entity should indicate the mobile the possible handover
situation. How this indication (usually layer2 information) is
transmitted from the network to the host can be realized depending on
the application.
It is possible that IGMP and MLD are extended to carry this handover
indication from router to the host to facilitate the fast join. In
this case some extension should be made on the IGMP/MLD packet.
However, this handover indication may also be required by other
unicast sessions. A common handover indicating mechanism may be
utilized for both multicast and unicast cases, which is not
necessarily an IGMP/MLD extended solution.
IGMP/MLD host and router can adjust their timer and counter values to
make faster join/leave during handoever, as described in Section 4.2.
The retransmission number of the report and query messages should
make reference to the practical conditions of the wireless access
connection.
4.4. Requirements on large number of point-to-point link
Two link modes are characterized in wireless access networks
[10][11]: shared link and point-to-point (PTP) link. IGMP and MLD
are considered to be heavy when large number of PTP link is connected
to the same multicast router, for the router should keep the state of
each mobile in a separate interface. The protocol overhead speeds up
(e.g. Query amount) as the number of the mobile node increases.
There are two solutions to the problem. One option is using
multicast VLAN in IGMP/MLD snooping switch, with each multicast group
number belonging to a separate multicast VLAN, which can be
interpreted as logical sharing on a multicast VLAN.
The other option is simplifying IGMP/MLD Protocols to suit the PTP
links. Because generally there is only one receiving host on each
link, the operation of IGMP/MLD relating to multiple receivers on
each interface should be taken out. Host suppression is unnecessary.
Delaying response randomly to avoid bursting of packets can also be
given up; instead the mobile could respond reports immediately, which
can implement better fast-leave capability. Besides, neither Group-
Specific query nor Source-and-Group-Specific is needed because when
Liu & Asaeda Expires May 15, 2008 [Page 11]
Internet-Draft IGMP and MLD Requirements for Mobility November 2007
this receiver mobile leaves this group, in most cases there is little
other listeners for the group or the sources on the same mobile.
When PTP link receiver number becomes large, the memory consumption
on the multicast router may be undesirable for an interface structure
should be recorded for each receiver. Thus the router should
maintain least necessary state for each receiver. From this point of
view, LW-IGMP/MLD protocols which discarding EXCLUDE filter-mode are
preferably to be used when supporting SSM reception.
4.5. Requirements for Explicit Tracking
If Host Suppression is not adopted, IGMP/MLD multicast routers could
chose to implement explicit tracking of mobile hosts. The explicit
tracking enables the router to learn the reception state of each
receiver, but at the meantime consumes much memory resources on the
router.
The advantage of explicit tracking is that it provides better
manageability of (mobile) receivers. Besides, for the router knows
who is listening for which group and sources, the Group-Specific
query and Source-Specific Query triggered by stopping receiving is
unnecessary to issue on the subnet.
As mentioned in previous section, as tracking large number of hosts
consumes a lot of memory, the LW-IGMP/MLD is preferred when SSM
reception mode is to be deployed.
Liu & Asaeda Expires May 15, 2008 [Page 12]
Internet-Draft IGMP and MLD Requirements for Mobility November 2007
5. 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.
Liu & Asaeda Expires May 15, 2008 [Page 13]
Internet-Draft IGMP and MLD Requirements for Mobility November 2007
6. References
6.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.
[3] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004.
[4] Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
August 1989.
[5] Fenner, W., "Internet Group Management Protocol, Version 2",
RFC 2373, July 1997.
[6] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999.
[7] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP",
RFC 4607, August 2006.
6.2. Informative References
[8] Liu, H., Cao, W., and H. Asaeda, "Lightweight IGMPv3 and MLDv2
Protocols",
draft-ietf-mboned-lightweight-igmpv3-mldv2-01.txt (work in
progress), June 2007.
[9] Romdhani, I., Kellil, M., and H. Lach, "IP Mobile Multicast:
Challenges and Solutions", IEEE Comm. Surveys 6(1), 2004.
[10] Schmidt, T., Waehlisch, M., and et. al, "Mobility in MIPv6:
Problem Statement and Brief Survey",
draft-irtf-mobopts-mmcastv6-ps-01.txt (work in progress),
July 2007.
[11] Zhang, H., Guan, J., and et. al, "MIPv6 Extensions for Mobile
Multicast: Problem Statement",
draft-zhang-multimob-memcast-ps-00.txt (work in progress),
July 2007.
Liu & Asaeda Expires May 15, 2008 [Page 14]
Internet-Draft IGMP and MLD Requirements for Mobility November 2007
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
Hitoshi Asaeda
Keio University
Graduate School of Media and Governance
5322 Endo
Fujisawa, Kanagawa 252-8520
Japan
Email: asaeda@wide.ad.jp
Liu & Asaeda Expires May 15, 2008 [Page 15]
Internet-Draft IGMP and MLD Requirements for Mobility November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Liu & Asaeda Expires May 15, 2008 [Page 16]