One document matched: draft-liu-multimob-igmp-mld-mobility-req-02.txt
Differences from draft-liu-multimob-igmp-mld-mobility-req-01.txt
Network working group H. Liu
Internet Draft Huawei Technologies Co., Ltd.
Category: Informational H. Asaeda
Created: July 13, 2009 Keio Universitys
Expires: January 2010 TM. Eubanks
Iformata Communications
Mobile and Wireless Multicast Requirements on IGMP/MLD Protocols
draft-liu-multimob-igmp-mld-mobility-req-02
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and 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 August 15, 2009.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your
rights and restrictions with respect to this document.
Liu and etc. Expires January 13, 2010 [Page 1]
Internet-Draft IGMP and MLD Requirements for Mobility July 2009
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..................................................2
2. Problem Statement.............................................3
3. The Behavior of IGMP and MLD Protocols........................4
3.1. IGMP Version 1...........................................5
3.2. IGMP Version 2...........................................5
3.3. IGMP Version 3...........................................6
3.4. Multicast Listener Discovery Protocols...................6
3.5. Lightweight IGMPv3/MLDv2.................................6
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................................8
4.4. Requirements for Wireless Link Types.....................9
4.5. Requirements for Explicit Tracking......................10
5. Security Considerations......................................11
6. References...................................................11
6.1. Normative References....................................11
6.2. Informative Referencess.................................11
Authors' Addresses..............................................12
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.
Liu and Etc. Expires January 13, 2010 [Page 2]
Internet-Draft IGMP and MLD Requirements for Mobility July 2009
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
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
Liu and Etc. Expires January 13, 2010 [Page 3]
Internet-Draft IGMP and MLD Requirements for Mobility July 2009
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
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.
Liu and Etc. Expires January 13, 2010 [Page 4]
Internet-Draft IGMP and MLD Requirements for Mobility July 2009
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.
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.
Liu and Etc. Expires January 13, 2010 [Page 5]
Internet-Draft IGMP and MLD Requirements for Mobility July 2009
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 consumes memory on the
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
Liu and Etc. Expires January 13, 2010 [Page 6]
Internet-Draft IGMP and MLD Requirements for Mobility July 2009
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.
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.
Liu and Etc. Expires January 13, 2010 [Page 7]
Internet-Draft IGMP and MLD Requirements for Mobility July 2009
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.
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
Liu and Etc. Expires January 13, 2010 [Page 8]
Internet-Draft IGMP and MLD Requirements for Mobility July 2009
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-
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
Liu and Etc. Expires January 13, 2010 [Page 9]
Internet-Draft IGMP and MLD Requirements for Mobility July 2009
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
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. 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.
Liu and Etc. Expires January 13, 2010 [Page 10]
Internet-Draft IGMP and MLD Requirements for Mobility July 2009
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.
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] Liu, H., Cao, W., and H. Asaeda, "Lightweight IGMPv3 and MLDv2
Protocols", draft-ietf-mboned-lightweight-igmpv3-mldv2-04.txt (work
in progress), 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.
6.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.
Liu and Etc. Expires January 13, 2010 [Page 11]
Internet-Draft IGMP and MLD Requirements for Mobility July 2009
[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.
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
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 January 13, 2010 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 04:22:22 |