< draft-ietf-multimob-igmp-mld-tuning-01.txt   draft-ietf-multimob-igmp-mld-tuning-02.txt >
MULTIMOB Working Group H. Asaeda MULTIMOB Working Group H. Asaeda
Internet-Draft Keio University Internet-Draft Keio University
Expires: January 12, 2012 H. Liu Expires: May 3, 2012 H. Liu
Q. Wu Q. Wu
Huawei Technologies Huawei Technologies
July 11, 2011 October 31, 2011
Tuning the Behavior of IGMP and MLD for Routers in Mobile and Wireless Tuning the Behavior of IGMP and MLD for Routers in Mobile and Wireless
Networks Networks
draft-ietf-multimob-igmp-mld-tuning-01 draft-ietf-multimob-igmp-mld-tuning-02
Abstract Abstract
IGMP and MLD are the protocols used by hosts and multicast routers to IGMP and MLD are the protocols used by hosts and multicast routers to
exchange their IP multicast group memberships with each other. This exchange their IP multicast group memberships with each other. This
document describes the ways of IGMPv3 and MLDv2 protocol optimization document describes the ways of IGMPv3 and MLDv2 protocol optimization
for mobility, and aims to become a guideline for query and other for mobility, and aims to become a guideline for query and other
timers and values tuning. timers and values tuning.
Status of this Memo Status of this Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 12, 2012. This Internet-Draft will expire on May 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 15 skipping to change at page 3, line 15
1. Introduction 1. Introduction
The Internet Group Management Protocol (IGMP) [2] for IPv4 and the The Internet Group Management Protocol (IGMP) [2] for IPv4 and the
Multicast Listener Discovery Protocol (MLD) [3] for IPv6 are the Multicast Listener Discovery Protocol (MLD) [3] for IPv6 are the
standard protocols for hosts to initiate joining or leaving multicast standard protocols for hosts to initiate joining or leaving multicast
sessions. These protocols must be also supported by multicast sessions. These protocols must be also supported by multicast
routers or IGMP/MLD proxies [10] that maintain multicast membership routers or IGMP/MLD proxies [10] that maintain multicast membership
information on their downstream interfaces. Conceptually, IGMP and information on their downstream interfaces. Conceptually, IGMP and
MLD work on both wireless and mobile networks. However, wireless MLD work on both wireless and mobile networks. However, wireless
access technologies operate on a shared medium or a point-to-point access technologies operate on a shared medium or a point-to-point
link with limited frequency and bandwidth. In many wireless regimes, link with limited spectrum and bandwidth. In many wireless regimes,
it is desirable to minimize multicast-related signaling to preserve it is desirable to minimize multicast-related signaling to preserve
the limited resources of battery powered mobile devices and the the limited resources of battery powered mobile devices and the
constrained transmission capacities of the networks. A mobile host constrained transmission capacities of the networks. A mobile host
may cause disruption of a multicast service initiation and may cause disruption of a multicast service initiation and
termination in the new or previous network upon its movement. Slow termination in the new or previous network upon its movement. Slow
multicast service activation following a join may incur additional multicast service activation following a join may incur additional
delay in receiving multicast packets and degrade reception quality. delay in receiving multicast packets and degrade reception quality.
Slow service termination triggered by IGMP/MLD querying or by a rapid Slow service termination triggered by IGMP/MLD querying or by a rapid
departure of the mobile host without leaving the group in the departure of the mobile host without leaving the group in the
previous network may waste network resources. previous network may waste network resources.
When IGMP and MLD are used with mobile IP protocols, the proximity of When IGMP and MLD are used with mobile IP protocols, the proximity of
network entities should be considered. For example, when bi- network entities should be considered. For example, when bi-
directional tunnel is used with the mobility entities described in directional tunnel is used with the mobility entities described in
[14][11] in place, the mobile host experiences additional latency, [11][14] in place, the mobile host experiences additional latency,
because the round-trip time using bi-directional tunnel between because the round-trip time using bi-directional tunnel between
mobility entities is larger comparing to the case that a host and an mobility entities is larger comparing to the case that a host and an
upstream router attach to a LAN. upstream router attach to a LAN.
To create the optimal multicast membership management condition, IGMP
and MLD protocols could be tuned to "ease a mobile host's processing
cost or battery power consumption by IGMP/MLD Query transmission
timing coordination by routers" and "realize fast state convergence
by successive monitoring whether downstream members exist or not".
This document describes the ways of tuning the IGMPv3 and MLDv2 This document describes the ways of tuning the IGMPv3 and MLDv2
protocol behavior on the router side for wireless and mobile protocol behavior on multicast router and proxy side for wireless and
networks, including query and other timers tuning. The selective mobile networks, including query and other timers tuning. The
optimization that provides tangible benefits to the mobile hosts and selective optimization that provides tangible benefits to the mobile
routers is given by keeping track of downstream hosts' membership hosts and routers is given by keeping track of downstream hosts'
status and varying IGMP/MLD Query types and values to tune the number membership status and varying IGMP/MLD Query types and values to tune
of responses. The proposed behavior interoperates with the IGMPv3 the number of responses. The proposed behavior interoperates with
and MLDv2 protocols. the IGMPv3 and MLDv2 protocols.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 [1]. this document are to be interpreted as described in RFC 2119 [1].
In this document, "router" means both multicast router and IGMP/MLD
proxy.
3. Explicit Tracking of Membership Status 3. Explicit Tracking of Membership Status
Mobile hosts use IGMP and MLD to request to join or leave multicast Mobile hosts use IGMP and MLD to request to join or leave multicast
sessions. When an adjacent upstream router receives the IGMP/MLD sessions. When an adjacent upstream router receives the IGMP/MLD
Report messages, it recognizes the membership status on the link. To Report messages, it recognizes the membership status on the link. To
update the membership status reliably, the router sends IGMP/MLD update the membership status reliably, the router sends IGMP/MLD
Query messages periodically, and sends Group-Specific and/or Group- Query messages periodically, and sends Group-Specific and/or Group-
and-Source Specific Queries when a member host reports its leave. and-Source Specific Queries when a member host reports its leave.
Then the other member hosts reply IGMP/MLD Report messages to notify Then the other member hosts reply IGMP/MLD Report messages to notify
their memberships. IGMP/MLD Query is therefore necessary to obtain their memberships. IGMP/MLD Query is therefore necessary to obtain
skipping to change at page 5, line 38 skipping to change at page 5, line 38
Specific and Group-and-Source Specific Queries LMQC/LLQC times (see Specific and Group-and-Source Specific Queries LMQC/LLQC times (see
Section 4.3 for LMQC/LLQC) only when it recognizes the last member Section 4.3 for LMQC/LLQC) only when it recognizes the last member
has left from the network. This reduces the transmitted number of has left from the network. This reduces the transmitted number of
Current-State Report messages. Current-State Report messages.
Enabling the explicit tracking function is advantageous for mobile Enabling the explicit tracking function is advantageous for mobile
multicast, but the function requires additional processing capability multicast, but the function requires additional processing capability
and a possibly large memory for routers to keep all membership and a possibly large memory for routers to keep all membership
status. Especially when a router needs to maintain a large number of status. Especially when a router needs to maintain a large number of
receiver hosts, this resource requirement is potentially impacted. receiver hosts, this resource requirement is potentially impacted.
Therefore, in this document, we propose that adjacent upstream Therefore, this document recommends that adjacent upstream multicast
multicast routers SHOULD enable the explicit tracking function for IP routers enables the explicit tracking function for IP multicast
multicast communications on wireless networks, if they have enough communications on wireless and mobile networks, if they have enough
resources. If operators think that their routers do not have enough resources. If operators think that their routers do not have enough
resources, they MAY decide to disable this function on their routers. resources, they may disable this function on their routers. Note
Note that whether routers enable the explicit tracking function or that whether routers enable the explicit tracking function or not,
not, they need to maintain downstream membership status by sending they need to maintain downstream membership status by sending IGMPv3/
IGMPv3/MLDv2 General Query messages as some IGMPv3/MLDv2 messages may MLDv2 General Query messages as some IGMPv3/MLDv2 messages may be
be lost during transmission. lost during transmission.
4. Tuning IGMP/MLD Timers and Values 4. Tuning IGMP/MLD Timers and Values
4.1. Tuning IGMP/MLD General Query Interval 4.1. Tuning IGMP/MLD General Query Interval
IGMP and MLD are non-reliable protocols; to cover the possibility of IGMP and MLD are non-reliable protocols; to cover the possibility of
a State-Change Report being missed by one or more multicast routers, a State-Change Report being missed by one or more multicast routers,
"hosts retransmit the same State-Change Report messages [Robustness "hosts retransmit the same State-Change Report messages [Robustness
Variable] - 1 more times", at intervals chosen at random from the Variable] - 1 more times", at intervals chosen at random from the
range (0, [Unsolicited Report Interval]) [2][3]. Although this range (0, [Unsolicited Report Interval]) [2][3]. Although this
skipping to change at page 14, line 7 skipping to change at page 14, line 7
protocols. protocols.
7. Security Considerations 7. Security Considerations
This document neither provides new functions or modifies the standard This document neither provides new functions or modifies the standard
functions defined in [2][3][4]. Therefore there is no additional functions defined in [2][3][4]. Therefore there is no additional
security consideration provided. security consideration provided.
8. Acknowledgements 8. Acknowledgements
Marshall Eubanks, Gorry Fairhurst, Dirk von Hugo, Imed Romdhani, Luis M. Contreras, Marshall Eubanks, Gorry Fairhurst, Dirk von Hugo,
Behcet Sarikaya, Yogo Uchida, Stig Venaas, Jinwei Xia, and others Imed Romdhani, Behcet Sarikaya, Yogo Uchida, Stig Venaas, Jinwei Xia,
provided many constructive and insightful comments. and others provided many constructive and insightful comments.
9. References 9. References
9.1. Normative References 9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to indicate requirement [1] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", RFC 2119, March 1997. levels", RFC 2119, March 1997.
[2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version 3", Thyagarajan, "Internet Group Management Protocol, Version 3",
skipping to change at page 15, line 36 skipping to change at page 15, line 36
[6] Fenner, W., "Internet Group Management Protocol, Version 2", [6] Fenner, W., "Internet Group Management Protocol, Version 2",
RFC 2236, July 1997. RFC 2236, July 1997.
[7] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener [7] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999. Discovery (MLD) for IPv6", RFC 2710, October 1999.
[8] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", [8] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP",
RFC 4607, August 2006. RFC 4607, August 2006.
[9] Asaeda, H. and Y. Uchida, "IGMP/MLD-Based Explicit Membership
Tracking Function for Multicast Routers",
draft-asaeda-mboned-explicit-tracking-02.txt (work in
progress), March 2011.
9.2. Informative References 9.2. Informative References
[9] Asaeda, H. and N. Leymann, "IGMP/MLD-Based Explicit Membership
Tracking Function for Multicast Routers",
draft-ietf-pim-explicit-tracking-00.txt (work in progress),
October 2011.
[10] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet [10] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet
Group Management Protocol (IGMP) / Multicast Listener Discovery Group Management Protocol (IGMP) / Multicast Listener Discovery
(MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")",
RFC 4605, August 2006. RFC 4605, August 2006.
[11] Gundavelli, S, Ed., Leung, K., Devarapalli, V., Chowdhury, K., [11] Gundavelli, S, Ed., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[12] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base Deployment [12] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base Deployment
for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6)
Domains", RFC 6224, April 2011. Domains", RFC 6224, April 2011.
[13] Asaeda, H., Seite, P., and J. Xia, "PMIPv6 Extensions for [13] Asaeda, H., Seite, P., and J. Xia, "PMIPv6 Extensions for
Multicast", draft-asaeda-multimob-pmip6-extension-06 (work in Multicast", draft-asaeda-multimob-pmip6-extension-07 (work in
progress), July 2011. progress), October 2011.
[14] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in [14] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[15] Perkins, Ed., C., "IP Mobility Support for IPv4, Revised", [15] Perkins, Ed., C., "IP Mobility Support for IPv4, Revised",
RFC 5944, November 2010. RFC 5944, November 2010.
Appendix A. Unicasting General Query Appendix A. Unicasting General Query
IGMPv3 and MLDv2 specifications [2][3] describe that a host MUST IGMPv3 and MLDv2 specifications [2][3] describe that a host MUST
skipping to change at page 17, line 48 skipping to change at page 17, line 48
extension this document does not focus on. If a router does not extension this document does not focus on. If a router does not
distinguish the multicast and unicast General Query Intervals, the distinguish the multicast and unicast General Query Intervals, the
router should only use and enable multicast General Query. router should only use and enable multicast General Query.
Also, unicasting General Query does not remove multicasting General Also, unicasting General Query does not remove multicasting General
Query. Multicast General Query is necessary to update membership Query. Multicast General Query is necessary to update membership
information if it is not correctly synchronized due to missing information if it is not correctly synchronized due to missing
Reports. Therefore, enabling unicast General Query SHOULD NOT be Reports. Therefore, enabling unicast General Query SHOULD NOT be
used for the implementation that does not allow to configure used for the implementation that does not allow to configure
different query interval timers as [Query Interval] and [Unicast different query interval timers as [Query Interval] and [Unicast
Query Interval] (See Appendix A for the detail). If a router does Query Interval]. If a router does not distinguish these multicast
not distinguish these multicast and unicast General Query Intervals, and unicast General Query Intervals, the router SHOULD only use and
the router SHOULD only use and enable multicast General Query. enable multicast General Query.
Authors' Addresses Authors' Addresses
Hitoshi Asaeda Hitoshi Asaeda
Keio University Keio University
Graduate School of Media and Governance Graduate School of Media and Governance
5322 Endo 5322 Endo
Fujisawa, Kanagawa 252-0882 Fujisawa, Kanagawa 252-0882
Japan Japan
 End of changes. 16 change blocks. 
40 lines changed or deleted 37 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/