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