One document matched: draft-wu-multimob-igmp-mld-tuning-00.txt
Network working group Q. Wu
Internet Draft H. Liu
Category: Informational Huawei
Created: March 22, 2010
Expires: September 2010
Proposal for Tuning IGMPv3/MLDv2 Protocol Behavior in Wireless and
Mobile networks
draft-wu-multimob-igmp-mld-tuning-00
Abstract
This document proposes a variety of optimization approaches for
tuning IGMPv3 and MLDv2 in wireless and mobile networks. It intends
to provide useful guideline when deploy current IGMP/MLD protocols
to support multicast listener mobility in wireless communication.
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].
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.
Wu,et al Expires September 22, 2010 [Page 1]
Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior March 2010
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) 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.
Table of Contents
1. Introduction..................................................3
2. Impact of wireless and mobility on IGMP/MLD...................3
2.1. Requirement for characteristics of wireless on IGMP/MLD..3
2.2. Evaluation of current versions of IGMP and MLD...........5
3. IGMP/MLD tuning optimization for Wireless or Mobile Network...5
3.1. Optimization Consideration for Report Messages...........6
3.2. Optimization Considerations for Query Messages...........6
3.2.1. Disable Group Specific Queries on leave.............7
3.2.2. Limiting the scope of periodical Queries............7
3.2.3. Conditional Retransmission of Queries on loss.......7
3.2.4. Unicast Query for the lost solicit report...........8
3.2.5. Query Retransmission in incremental interval........8
3.3. Optimization Considerations for Link Type................8
4. Security Considerations.......................................9
5. Acknowledgement...............................................9
6. References...................................................10
6.1. Normative References....................................10
6.2. Informative Referencess.................................10
Authors' Addresses..............................................11
Wu,et al Expires September 22, 2010 [Page 2]
Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior March 2010
1. Introduction
With the emerging techniques for different wireless networks, IP
multicast sees their potentiality to be deployed to support wireless
or mobile video service, and also faces great challenges for its
efficiency and reliability in the wireless network, e.g. with
possibly higher packet loss rate and limited frequency and bandwidth,
more prone to congestion, and frequent joining or leaving multicast
group due to handover and fast channel change.
However as described in [RFC1112], the current versions of IGMP and
MLD are only designed for fixed Ethernet model. They are not
specified for other type of network like wireless link types.
Therefore IGMP/MLD protocol should be enhanced or tuned to adapt to
wireless environment to meet the reliability and efficiency
requirements in the scenarios described in [REQUIRE].
This memo proposes a variety of optimization approaches for tuning
IGMP/MLD protocols in wireless or mobile communication environment.
It aims to make the minimum tuning without introducing obvious
changes on the protocol behavior. These solutions can also be used
in wired network when efficiency and reliability are required. They
are discussed in detail in Section 3.
2. Impact of wireless and mobility on IGMP/MLD
This section analyzes the impact of wireless and mobility on
IGMP/MLD protocols. Also the current versions of IGMP and MLD are
evaluated.
2.1. Requirement for characteristics of wireless on IGMP/MLD
As mentioned in the section 1, IGMP/MLD faces great challenges for
its efficiency and reliability in the wireless network. Due to this
impact of wireless and mobility on IGMP/MLD, IGMP and MLD should
have the following characteristics when used in wireless and mobile
networks [REQUIRE]:
o ASM and SSM subscription: SSM [RFC4607]mode is different from ASM
for it allows only sources specific multicast delivery. Comparing
with ASM mode, it is more secure and applicable to broadcast video
service, and must be supported together with SSM mode in practical
multicast network.
Wu,et al Expires September 22, 2010 [Page 3]
Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior March 2010
o Fast Join and Leave: Fast join and leave of a subscriber helps to
improve the user's experience during channel join and channel
zapping. Fast leave also facilitates releasing of unused network
resources quickly. Besides, mobility and handover may cause a user
to join and leave a multicast group frequently, which also require
fast join and leave to accelerate service activation and to optimize
resource usages.
o Explicit Tracking: Tracking each member by the router enables a
multicast router to explicitly keep track the membership of all
multicast hosts in the access network. And because the router has
record of each user in its state database, it is possible to
simplify the Query mechanism by reducing both the unnecessary
Queries and reports generated on a network.
o Robustness to packet loss: Wireless link has the characteristic
that packet transmission is unreliable due to instable link
conditions. For mobile IP network, packets sometimes have to travel
between home network and foreign network and have the possibility of
being lost due to long distance transmission. These network
scenarios have more strict robustness requirement on delivery of
IGMP and MLD protocol messages.
o Minimum packet transmission: Wireless link resources are usually
more precious and limited compared to their wired counterpart.
Minimizing packet exchange without degrading general protocol
performance should also be emphasized to improve efficiency and
increase network capacity.
o Avoiding packet burst: Large number of packets generated within a
short time interval may have the tendency to deteriorate wireless
network conditions. IGMP and MLD when using in wireless and mobile
networks should be optimized if their protocol message generation
has the potential of introducing packet burst.
o Adaptive to different link mode: IGMP and MLD are originally
designed for wired Ethernet link and some of their processing are
only applicable to shared link model. Wireless and mobile network
link type is versatile, including shared, point-to-point, point-to-
multipoint, and tunnel interface. Because different link model has
different features, IGMP/MLD protocol behavior should be tuned to
adapt to different link model.
Wu,et al Expires September 22, 2010 [Page 4]
Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior March 2010
2.2. Evaluation of current versions of IGMP and MLD
IGMPv2 [RFC2236] and MLDv1 [RFC2710] only support ASM communication
mode. They do not support SSM subscription and explicit tracking,
which limit their widespread deployment in practical multicast
network. IGMPv3 [RFC3376] and MLDv2 [RFC3810] and their lightweight
version LW-IGMPv3/LW-MLDv2 [RFC5760] support all the features of ASM
and SSM communication, and of explicit tracking. They are much
better to be candidates for wireless and mobile networks than their
previous versions and are the basis of the optimization discussed in
this document.
IGMPv3/MLDv2 join and leave Reports are sent unsolicitedly when a
host intends to join or leave a group. They are closest to user's
experience and must be guaranteed to improve service performance and
to optimize resource use. Current IGMPv3 and MLDv2 provide the
reliability for these messages by simple retransmission, which is
not adequate from both the robustness and efficiency aspects[ROBUST].
They are suggested to be enhanced by acknowledgement-retransmission
in [IGMP-ACK].
IGMPv3 and MLDv2 do not adopt host suppression mechanism. Their
report count in response to a Query is not small, if the number of
active receivers on the network is large. Even though the protocols
enable the reports on an interface to be merged, further
optimizations are still required to improve the efficiency and to
reduce bandwidth occupation.
To meet the requirements listed in section 2.1, the protocol message
of IGMPv3/MLDv2, including the various Queries and Reports, together
with their behavior, need to be regulated to adapt to wireless and
mobile scenarios. Because an enhancement in one direction might
introduce side effects in another one, balances should be taken
carefully to avoid defects and improve protocol performance as a
whole, as illustrated in section 3.
3. IGMP/MLD tuning optimization for Wireless or Mobile Network
As mentioned in section 2, IGMPv3/MLDv2 or LW-IGMPv3/MLDv2 are
recommended to be used as the basis for optimization of IGMP/MLD to
adapt to wireless and mobile networks. In this section, taking
these characteristics requirement into account, we will discuss
several optimization approaches for tuning of IGMP and MLD in the
wireless environment. The optimizations try to minimize the packet
transmission for both the Reports and Queries, and at the meanwhile
take the factor of improving reliability into account, with minimum
Wu,et al Expires September 22, 2010 [Page 5]
Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior March 2010
cost. The different link types are also considered when making the
regulations.
3.1. Optimization Consideration for Report Messages
Unsolicited reports are generated when hosts' interface state
changes, they are sent actively when a user intends to join or leave
a group or a source-group. However in some cases, the unsolicited
reports are prone to loss due to network conditions degradation or
long distance travel. Even the report can be retransmitted for
[Robust Variable] times, the packet sent by the host is received by
the router can not be guaranteed. Furthermore, Excessive Packet
retransmission is the waste of resource. These issue can be
addressed by acknowledge-retransmission described in [IGMP-ACK] for
an unsolicited IGMPv3/MLDv2 Report. A host after sending an
unsolicited report starts a retransmission timer and waits for the
acknowledgement (ACK or multicast data) from the router. Upon receiving
ACK or multicast data, the host stops the timer and retransmission.
If the acknowledgement 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.
Solicited reports are generated in response to Queries and are used
to refresh the state database of the host on the router. They are
suggested not to be acknowledged in order not to introduce too many
report packets on the network, and they are not acknowledged also
because the Query-Response to-and-fro itself implies an
acknowledgement to some degree. If in some cases a host's solicited
report is lost due to unstable transmission condition, there is
still some remedy that can tackle this issue, as described in
section 3.2.5.
3.2. Optimization Considerations for Query Messages
IGMPv3 and MLDv2 have three kinds of Queries: General Query
periodically sent to all multicast receivers, Group Specific Query
sent when a receiver leaves a (*,G) group, and Source-and-Group
Specific Query sent when a receiver leaves an (S,G) group. These
Queries have different functional scope. They are used to fetch and
refresh the downstream membership information by being responded by
solicited reports.
This section lists the possible optimization methods for Query
messages. The solutions are not intended to be adopted altogether
or simultaneously, but can be taken selectively according to the
scale and conditions of the operating network.
Wu,et al Expires September 22, 2010 [Page 6]
Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior March 2010
3.2.1. Disable Group Specific Queries on leave
If explicit tracking is used, the router is able to keep states for
all active members in reception. The Group Specific and Source-and-
Group Specific Queries, which are sent to query other members when a
member leaves, are unnecessary because the router knows who are
active on the interface. It is possible that when explicit tracking
is used, only periodical Query is used.
Disable of Group and Source-Group specific Queries in case a
member leaves a group will reduce both the number of Query and the
number of Report exchanged on the network, which helps to minimize
packet number and packet burst when explicit tracking is enabled.
3.2.2. Limiting the scope of periodical Queries
General Query is sent by a router periodically to all multicast
receivers belonging to all groups and all source-groups and will
probably result in burst response and link congestion if the
receiver number on the link is large, even if Delay response is used.
Therefore large number of reports within a specified time interval
should be avoided if the number of the receiver on the link is large.
A router can tune the scope of its periodical Queries according to
the network conditions and user scale. For example, if the receiver
number is small, the periodical General Queries for all multicast
receivers is enough. If the number of the multicast receiver on a
link is large, the router could choose to periodically send Group
Queries to a (*,G) group in different time interval or send Source-
Group Specific Queries to an (S,G) group in different time interval.
In this case the router tunes its behavior by sending these two
Queries periodically instead of triggering them when a member
reports its leave. Using periodical Group Specific Queries or
Source-Group Specific Queries sent in different time interval has
the advantages of avoiding packet bursts and the response report
from unrelated group when the receiver number is large.
3.2.3. Conditional Retransmission of Queries on loss
A router which keeps track of all its active receivers, if after
sending a Query, fails to get any response from any receiver, it
could 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 solicit its
active members. Optionally, the router could resend several Queries
in incremental interval as described in section 3.2.5
Wu,et al Expires September 22, 2010 [Page 7]
Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior March 2010
3.2.4. Unicast Query for the lost solicit report
Unicast Query mechanism is first suggested in [OPTIMIZ] to benefit
the battery power consumption on mobile terminals. It is used here
to improve the robustness of solicited reports. A router after
sending a periodical Query collects successfully all the members'
report responses except for one or two which are currently still
valid in its database. This may be because the non-respondent ones
silently leave the network without any notification, or because
their reports are lost due to some unknown reason. The router in
this case could choose to unicast a Query respectively to each non-
respondent receiver to check whether they are still alive for the
multicast reception, without affecting the majority of receivers
that have already responded. Optionally, unicast Queries could be
resent in incremental interval, as described in section 3.2.5.
3.2.5. Query Retransmission in incremental interval
Query Retransmission [ADAPTIVE] can be slowed down when a router can
not collect successfully all the members' report responses and
network congestion is going to happen. It basis behavior is: the
router after sending a Query, if acquires the response from the
receiver, refreshes its state database and stop the querying
retransmission process, or if after a time interval fails to get the
report response, resends a Query in an increasing (e.g. double)
interval. This process can be repeated several times, each time the
retransmission is arranged in a prolonged time interval, till the
router receives the response, or determines the receiver is
unreachable and then stops the sending of the Query ultimately.
This query retransmission in incremental interval processing enables
the router to reduce the packet retransmission in the same time
period comparing with unconditional retransmission (i.e.
retransmission for multiple times with fixed interval). It is
suggested be used to improve the robustness of the solicited report
and of the Query as illustrated in section 3.2.3 and 3.2.4. The
variable time interval and the termination condition should be
configurable and could be set according to actual network
arrangement.
3.3. Optimization Considerations for Link Type
Wireless access link is characterized as three types as described in
[REQUIRE]: shared, Point-to-Point (PTP) and point-to-multipoint
(PTMP). Shared network resembles Ethernet as its link is shared
among all end users. For PTP link, the communication channel
Wu,et al Expires September 22, 2010 [Page 8]
Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior March 2010
between users and first-hop routers are dedicated in both uplink
(i.e. from the user to the router) and downlink direction. PTMP
link represents the link model where the uplink is dedicated while
the downlink is shared.
For shared wireless networks, the basic mechanism of IGMPv3 and
MLDv2 should be applicable, ideally with some efficiency and
robustness enhancement when needed. For PTP or PTMP links, some
characteristics of IGMP and MLD which are specific for shared
network should not be reused if they have additional processing
overhead and link burden.
For example, Delay Response which is used to prevent bursting of
solicited reports, should not be required in PTP and PTMP link,
because there is only one receiver reported to the router on each
uplink. Without Delayed Response, the report could be responded to
the router immediately, and it is faster to implement robust
enhancement for a solicited Report (see section 3.2.3) and for a
Query (see section 3.2.4), because it'll take less time for the
router to make collection of the reports. For the same reason,
Group specific Query and Source-and-Group Specific Query, which are
used to query other valid members, are not necessary for PTP and
PTMP link.
Finally, for PTP links, periodical General Query, which is sent
separately to each interface, is unnecessary to be sent to all the
interfaces but rather only to the hosts which have made the group
join and have reception state on the router. This will not only
reduce the necessary Queries, but also be desirable for the battery
saving for the mobile terminal not involved in the multicast
reception for not being frequently awakened when in the sleeping
mode.
4. Security Considerations
They will be described in the later version of this draft.
5. Acknowledgement
The authors would like to thank Liu Yisong and Wei Yong for their
valuable comments on the optimization methods.
Wu,et al Expires September 22, 2010 [Page 9]
Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior March 2010
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate
requirement levels", RFC 2119, March 1997.
[RFC1112] Deering, S. "Host Extensions for IP Multicasting", RFC1112,
August 1989.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, November 1997.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version 3", RFC
3376, October 2002.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2(MLDv2) for IPv6", RFC 3810, June 2004.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006.
[RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight IGMPv3 and
MLDv2 Protocols", RFC5790, February 2010.
6.2. Informative Referencess
[REQUIRE] H. Liu, Q. Wu, H. Asaeda and TM. Eubanks, "Mobile and
Wireless Multicast Requirements on IGMP/MLD Protocols", draft-liu-
multimob-igmp-mld-mobility-req-03.txt, March 2010.
[ROBUST] A. Sen Mazumder, "Facilitating Robust Multicast Group
Management", NOSSDAV'05, June 13-14, 2005, Stevenson, Washington,
USA.
[IGMP-ACK] H. Liu, Q, Wu, "Reliable IGMP and MLD Protocols in
Wireless Environment", draft-liu-multimob-reliable-igmp-mld-00.txt,
February 2010.
[OPTIMIZ] H. Asaeda, "Tuning IGMPv3/MLDv2 Protocol Behavior in
Wireless and Mobile networks", draft-asaeda-multimob-igmp-mld-
optimization-02, work in progress, March 2010.
Wu,et al Expires September 22, 2010 [Page 10]
Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior March 2010
[ADAPTIVE] I. Romdhani, J. Munoz, H. Bettahar, and A. Bouabdallah,
"Adaptive Multicast Membership Management for Mobile Multicast
Receivers", IEEE, 2006.
Authors' Addresses
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
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
Wu,et al Expires September 22, 2010 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-23 15:16:56 |