idnits 2.17.00 (12 Aug 2021) /tmp/idnits14533/draft-ietf-multimob-igmp-mld-tuning-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 11, 2011) is 3966 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '5' is defined on line 451, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 454, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 457, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-asaeda-multimob-pmip6-extension-06 -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '14') (Obsoleted by RFC 6275) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MULTIMOB Working Group H. Asaeda 3 Internet-Draft Keio University 4 Expires: January 12, 2012 H. Liu 5 Q. Wu 6 Huawei Technologies 7 July 11, 2011 9 Tuning the Behavior of IGMP and MLD for Routers in Mobile and Wireless 10 Networks 11 draft-ietf-multimob-igmp-mld-tuning-01 13 Abstract 15 IGMP and MLD are the protocols used by hosts and multicast routers to 16 exchange their IP multicast group memberships with each other. This 17 document describes the ways of IGMPv3 and MLDv2 protocol optimization 18 for mobility, and aims to become a guideline for query and other 19 timers and values tuning. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 12, 2012. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Explicit Tracking of Membership Status . . . . . . . . . . . . 5 70 4. Tuning IGMP/MLD Timers and Values . . . . . . . . . . . . . . 6 71 4.1. Tuning IGMP/MLD General Query Interval . . . . . . . . . . 6 72 4.2. Tuning IGMP/MLD Query Response Interval . . . . . . . . . 7 73 4.3. Tuning Last Member Query Timer (LMQT) and Last 74 Listener Query Timer (LLQT) . . . . . . . . . . . . . . . 7 75 4.4. Tuning Startup Query Interval . . . . . . . . . . . . . . 8 76 4.5. Tuning Robustness Variable . . . . . . . . . . . . . . . . 8 77 4.6. Tuning Scenarios for Various Mobile IP Networks . . . . . 9 78 5. Destination Address of Specific Query . . . . . . . . . . . . 11 79 6. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 12 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 84 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 85 Appendix A. Unicasting General Query . . . . . . . . . . . . . . 17 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 88 1. Introduction 90 The Internet Group Management Protocol (IGMP) [2] for IPv4 and the 91 Multicast Listener Discovery Protocol (MLD) [3] for IPv6 are the 92 standard protocols for hosts to initiate joining or leaving multicast 93 sessions. These protocols must be also supported by multicast 94 routers or IGMP/MLD proxies [10] that maintain multicast membership 95 information on their downstream interfaces. Conceptually, IGMP and 96 MLD work on both wireless and mobile networks. However, wireless 97 access technologies operate on a shared medium or a point-to-point 98 link with limited frequency and bandwidth. In many wireless regimes, 99 it is desirable to minimize multicast-related signaling to preserve 100 the limited resources of battery powered mobile devices and the 101 constrained transmission capacities of the networks. A mobile host 102 may cause disruption of a multicast service initiation and 103 termination in the new or previous network upon its movement. Slow 104 multicast service activation following a join may incur additional 105 delay in receiving multicast packets and degrade reception quality. 106 Slow service termination triggered by IGMP/MLD querying or by a rapid 107 departure of the mobile host without leaving the group in the 108 previous network may waste network resources. 110 When IGMP and MLD are used with mobile IP protocols, the proximity of 111 network entities should be considered. For example, when bi- 112 directional tunnel is used with the mobility entities described in 113 [14][11] in place, the mobile host experiences additional latency, 114 because the round-trip time using bi-directional tunnel between 115 mobility entities is larger comparing to the case that a host and an 116 upstream router attach to a LAN. 118 To create the optimal multicast membership management condition, IGMP 119 and MLD protocols could be tuned to "ease a mobile host's processing 120 cost or battery power consumption by IGMP/MLD Query transmission 121 timing coordination by routers" and "realize fast state convergence 122 by successive monitoring whether downstream members exist or not". 124 This document describes the ways of tuning the IGMPv3 and MLDv2 125 protocol behavior on the router side for wireless and mobile 126 networks, including query and other timers tuning. The selective 127 optimization that provides tangible benefits to the mobile hosts and 128 routers is given by keeping track of downstream hosts' membership 129 status and varying IGMP/MLD Query types and values to tune the number 130 of responses. The proposed behavior interoperates with the IGMPv3 131 and MLDv2 protocols. 133 2. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 136 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in 137 this document are to be interpreted as described in RFC 2119 [1]. 139 3. Explicit Tracking of Membership Status 141 Mobile hosts use IGMP and MLD to request to join or leave multicast 142 sessions. When an adjacent upstream router receives the IGMP/MLD 143 Report messages, it recognizes the membership status on the link. To 144 update the membership status reliably, the router sends IGMP/MLD 145 Query messages periodically, and sends Group-Specific and/or Group- 146 and-Source Specific Queries when a member host reports its leave. 147 Then the other member hosts reply IGMP/MLD Report messages to notify 148 their memberships. IGMP/MLD Query is therefore necessary to obtain 149 the up-to-date membership information, but a large number of the 150 reply messages sent from all member hosts may cause network 151 congestion or consume network bandwidth cunsumption. 153 The "explicit tracking function" [9] is the possible approach to 154 reduce the transmitted number of IGMP/MLD messages and contribute to 155 the efficiency of mobile communications. It enables the router to 156 keep track of the membership status of the downstream IGMPv3 or MLDv2 157 member hosts. That is, if a router enables the explicit tracking 158 function, it does not always need to ask Current-State Report message 159 transmission from the receiver hosts since the router implicitly 160 recognizes the (potential) last member host when it receives the 161 State-Change Report. The router can therefore send IGMP/MLD Group- 162 Specific and Group-and-Source Specific Queries LMQC/LLQC times (see 163 Section 4.3 for LMQC/LLQC) only when it recognizes the last member 164 has left from the network. This reduces the transmitted number of 165 Current-State Report messages. 167 Enabling the explicit tracking function is advantageous for mobile 168 multicast, but the function requires additional processing capability 169 and a possibly large memory for routers to keep all membership 170 status. Especially when a router needs to maintain a large number of 171 receiver hosts, this resource requirement is potentially impacted. 172 Therefore, in this document, we propose that adjacent upstream 173 multicast routers SHOULD enable the explicit tracking function for IP 174 multicast communications on wireless networks, if they have enough 175 resources. If operators think that their routers do not have enough 176 resources, they MAY decide to disable this function on their routers. 177 Note that whether routers enable the explicit tracking function or 178 not, they need to maintain downstream membership status by sending 179 IGMPv3/MLDv2 General Query messages as some IGMPv3/MLDv2 messages may 180 be lost during transmission. 182 4. Tuning IGMP/MLD Timers and Values 184 4.1. Tuning IGMP/MLD General Query Interval 186 IGMP and MLD are non-reliable protocols; to cover the possibility of 187 a State-Change Report being missed by one or more multicast routers, 188 "hosts retransmit the same State-Change Report messages [Robustness 189 Variable] - 1 more times", at intervals chosen at random from the 190 range (0, [Unsolicited Report Interval]) [2][3]. Although this 191 behavior increases the protocol robustness, it does not guarantee 192 that the State-Change Report reaches the routers. Therefore, routers 193 still need to refresh the downstream membership information by 194 receiving Current-State Report periodically solicited by IGMP/MLD 195 General Query sent in the [Query Interval] period, in order to 196 enhance robustness of the host in case of link failures and packet 197 loss. It also supports the situation that mobile hosts turn off or 198 move from a network to other network managed by a different router 199 without any notification (e.g., leave request). 201 The [Query Interval] is the interval between General Queries sent by 202 the regular IGMPv3/MLDv2 querier, and the default value is 125 203 seconds [2][3]. By varying the [Query Interval], multicast routers 204 can tune the number of IGMP/MLD messages on the network; larger 205 values cause IGMP/MLD Queries to be sent less often. 207 This document proposes 150 seconds for the [Query Interval] value by 208 changing the Querier's Query Interval Code (QQIC) field specified in 209 the IGMP/MLD Query message, for the case that a router enabling the 210 explicit tracking function sends General Query and potentially 211 operates a large number of member hosts such as more than 200 hosts 212 on the wireless link. This longer interval value contributes to 213 minimizing traffic of Report messages and battery power consumption 214 for mobile hosts. 216 On the other hand, this document also proposes 60 to 90 seconds for 217 the [Query Interval] value for the case that a router enabling the 218 explicit tracking function attaches to a wireless link having higher 219 capacity of the resource. This shorter interval contributes to quick 220 synchronization of the membership information tracked by the router 221 but may consume battery power of mobile hosts. 223 If a router does not enable the explicit tracking function, the 224 [Query Interval] value would be its default value, 125 seconds. 226 In situations where Mobile IPv6 [14] is used, when the home agent 227 implements multicast router functionality and multicast data packets 228 are tunneled to and from the home agent, the home agent may want to 229 slow down Query periodicity, especially when network congestion is 230 detected. This can be done by the home agent starting forwarding 231 queries with the default [Query Interval] value and increasing it in 232 a gradual manner until it exceeds the mobile host's lifetime. 234 4.2. Tuning IGMP/MLD Query Response Interval 236 The [Query Response Interval] is the Max Response Time (or Max 237 Response Delay) used to calculate the Max Resp Code inserted into the 238 periodic General Queries. Its default value is 10 seconds expressed 239 by "Max Resp Code=100" for IGMPv3 [2] and "Maximum Response 240 Code=10000" for MLDv2 [3]. By varying the [Query Response Interval], 241 multicast routers can tune the burstiness of IGMP/MLD messages on the 242 network; larger values make the traffic less bursty as host responses 243 are spread out over a larger interval, but will increase join latency 244 when State-Change Report is missing. 246 According to our experimental analysis, this document proposes two 247 tuning scenarios for tuning the [Query Response Interval] value in 248 different wireless link conditions; one scenario is for a wireless 249 link with a lower capacity of network resource or a lossy link, and 250 the other scenario is for a wireless link with enough capacity or 251 reliable condition for IGMP/MLD message transmission. 253 Regarding the first scenario, for instance, when a multicast router 254 attaches to a bursty IEEE 802.11b link, the router configures the 255 longer [Query Response Interval] value, such as 10 to 20 (sec). This 256 configuration will reduce congestion of the Current-State Report 257 messages on a link but may increase join latency and leave latency 258 when the unsolicited messages (State-Change Record) are lost on the 259 router. 261 The second scenario may happen for a multicast router attaching to a 262 wireless link having higher capacity of the resource or a point-to- 263 (multi-)point link such as an IEEE 802.16e link, because IGMP/MLD 264 messages do not seriously affect the link condition. The router can 265 seek Current-State Report messages with the shorter [Query Response 266 Interval] value, such as 5 to 10 (sec). This configuration will 267 contribute to quickly (at some level) discovering non-tracked member 268 hosts and synchronizing the membership information. 270 4.3. Tuning Last Member Query Timer (LMQT) and Last Listener Query 271 Timer (LLQT) 273 Shortening the Last Member Query Timer (LMQT) for IGMPv3 and the Last 274 Listener Query Timer (LLQT) for MLDv2 contributes to minimizing leave 275 latency. LMQT is represented by the Last Member Query Interval 276 (LMQI), multiplied by the Last Member Query Count (LMQC), and LLQT is 277 represented by the Last Listener Query Interval (LLQI), multiplied by 278 the Last Listener Query Count (LLQC). 280 While LMQI and LLQI are changeable, it is reasonable to use the 281 default values (i.e., 1 second) for LMQI and LLQI in a wireless 282 network. LMQC and LLQC, whose default value is the [Robustness 283 Variable] value, are also tunable. Therefore, LMQC and LLQC MAY be 284 set to "1" for routers enabling the explicit tracking function, and 285 then LMQT and LLQT are set to 1 second. However, setting LMQC and 286 LLQC to 1 increases the risk of missing the last member; LMQC and 287 LLQC SHOULD be set to 1 only when network operators think that their 288 wireless link is stable enough. 290 On the other hand, if network operators think that their wireless 291 link is lossy (e.g., due to a large number of attached hosts or 292 limited resources), they MAY set LMQC and LLQC to "2" for their 293 routers enabling the explicit tracking function. Although bigger 294 LMQC and LLQC values may cause longer leave latency, the risk of 295 missing the last member will be reduced. 297 4.4. Tuning Startup Query Interval 299 The [Startup Query Interval] is the interval between General Queries 300 sent by a Querier on startup. The default value is 1/4 of [Query 301 Interval]; however, this document recommends the use of its shortened 302 value such as 1 second since the shorter value would contribute to 303 shortening handover delay for mobile hosts in, e.g., the base 304 solution with PMIPv6 [12]. Note that the [Startup Query Interval] is 305 a static value and cannot be changed by any external signal. 306 Therefore operators who maintain routers and wireless links must 307 properly configure this value. 309 4.5. Tuning Robustness Variable 311 To cover the possibility of unsolicited reports being missed by 312 multicast routers, unsolicited reports are retransmitted [Robustness 313 Variable] - 1 more times, at intervals chosen at random from the 314 defined range [2][3]. The QRV (Querier's Robustness Variable) field 315 in IGMP/MLD Query contains the [Robustness Variable] value used by 316 the querier. The default [Robustness Variable] value defined in 317 IGMPv3 [2] and MLDv2 [3] is "2". 319 This document proposes "2" for the [Robustness Variable] value for 320 mobility, when a router attaches to a wireless link having lower 321 capacity of the resource or a large number of hosts. For a router 322 that attaches to a wireless link having higher capacity of the 323 resource or reliable condition, it is not required to retransmit the 324 same State-Change Report message; hence the router sets the 325 [Robustness Variable] to "1". Note that whether the explicit 326 tracking function is enabled or not, the [Robustness Variable] value 327 SHOULD NOT be bigger than "2". 329 4.6. Tuning Scenarios for Various Mobile IP Networks 331 In mobile IP networks, IGMP and MLD are used either with three 332 deployment scenarios; (1) running directly between host and access 333 router on a wireless network, (2) running between host and home 334 router through a tunnel link, and (3) running between home router and 335 foreign router through a tunnel link. 337 When a receiver host connects directly through a wireless link to a 338 foreign access router or a home router, the tuning of the IGMP/MLD 339 protocol parameters should be the same as suggested in the previous 340 sections. The example of this scenario occurs when route 341 optimization is adopted in MIPv6 [14] or Mobile IP [15], or when in 342 Proxy Mobile IPv6 (PMIPv6) [11], the mobile access gateway, whose 343 role is similar to the one of a foreign router, acts as a multicast 344 router as proposed in [13]. 346 The second scenario occurs when bi-directional tunnel established 347 between host and home router is used to exchange IGMP/MLD messages 348 such as [14][15]. There are difficulties in tuning the parameters in 349 this situation, because the tunnel link condition is diverse and 350 changeable. When a host is far away from the home router, the 351 transmission delay between the two entities may be longer and the 352 packet delivery may be more unreliable. Thus the effects of the 353 IGMP/MLD message transmission through a tunnel link should be 354 considered during the parameter setting. For example, the [Query 355 Interval] and [Query Response Interval] could be set shorter to 356 compensate the transmission delay, and the [Robustness Variable] 357 could be increased for possible packet loss. 359 The third scenario occurs in [12], in which the mobile access gateway 360 (i.e., foreign router) acts as the IGMP/MLD Proxy [10] in PMIPv6 361 [11]. Through the bi-directional tunnel established with the local 362 mobility anchor (i.e., home router), the mobile access gateway sends 363 summary reports of its downstream member hosts to the local mobility 364 anchor. Apart from the distance factor that influences the parameter 365 setting, the [Query Response Interval] on the local mobility anchor 366 could be set to the smaller value since the number of foreign router 367 is much smaller compared to the that of the host and the chances of 368 packet burst is low for the same reason. 370 Ideally, the IGMP/MLD querier router adjusts its parameter setting 371 according to the actual mobile IP network conditions to benefit 372 service performance and resource utilization. It would be desirable 373 that a home router determines aforementioned timers and values 374 according to the delay between the initiating IGMP/MLD Query and the 375 responding IGMP/MLD Report, while describing such mechanism 376 dynamically adjusting these timers and values is out of scope of this 377 document. 379 5. Destination Address of Specific Query 381 IGMP/MLD Group-Specific and Group-and-Source Specific Queries defined 382 in [2][3] are sent to verify whether there are hosts that desire 383 reception of the specified group or a set of sources or to rebuild 384 the desired reception state for a particular group or a set of 385 sources. These specific Queries build and refresh multicast 386 membership state of hosts on an attached network. These specific 387 Queries should be sent to all desired hosts with specific multicast 388 address (not the all-hosts/all-nodes multicast address) as their IP 389 destination addresses, because hosts that do not join the multicast 390 session do not pay attention to these specific Queries, and only 391 active member hosts that have been receiving multicast contents with 392 the specified address reply IGMP/MLD reports. 394 6. Interoperability 396 IGMPv3 [2] and MLDv2 [3] provide the ability for hosts to report 397 source-specific subscriptions. With IGMPv3/MLDv2, a mobile host can 398 specify a channel of interest, using multicast group and source 399 addresses in its join request. Upon its reception, the upstream 400 router that supports IGMPv3/MLDv2 establishes the shortest path tree 401 toward the source without coordinating a shared tree. This function 402 is called the source filtering function and is required to support 403 Source-Specific Multicast (SSM) [8]. 405 Recently, the Lightweight-IGMPv3 (LW-IGMPv3) and Lightweight-MLDv2 406 (LW-MLDv2) [4] protocols have been defined as the proposed standard 407 protocols in the IETF. These protocols provide protocol simplicity 408 for mobile hosts and routers, as they eliminate a complex state 409 machine from the full versions of IGMPv3 and MLDv2, and promote the 410 opportunity to implement SSM in mobile communications. 412 This document assumes that both multicast routers and mobile hosts 413 MUST be IGMPv3/MLDv2 capable, regardless whether the protocols are 414 the full or lightweight version. And this document does not consider 415 interoperability with older version protocols. The main reason not 416 being interoperable with older IGMP/MLD protocols is that the 417 explicit tracking function does not work properly with older IGMP/MLD 418 protocols. 420 7. Security Considerations 422 This document neither provides new functions or modifies the standard 423 functions defined in [2][3][4]. Therefore there is no additional 424 security consideration provided. 426 8. Acknowledgements 428 Marshall Eubanks, Gorry Fairhurst, Dirk von Hugo, Imed Romdhani, 429 Behcet Sarikaya, Yogo Uchida, Stig Venaas, Jinwei Xia, and others 430 provided many constructive and insightful comments. 432 9. References 434 9.1. Normative References 436 [1] Bradner, S., "Key words for use in RFCs to indicate requirement 437 levels", RFC 2119, March 1997. 439 [2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 440 Thyagarajan, "Internet Group Management Protocol, Version 3", 441 RFC 3376, October 2002. 443 [3] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 444 (MLDv2) for IPv6", RFC 3810, June 2004. 446 [4] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet Group 447 Management Protocol Version 3 (IGMPv3) and Multicast Listener 448 Discovery Version 2 (MLDv2) Protocols", RFC 5790, 449 February 2010. 451 [5] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, 452 August 1989. 454 [6] Fenner, W., "Internet Group Management Protocol, Version 2", 455 RFC 2236, July 1997. 457 [7] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener 458 Discovery (MLD) for IPv6", RFC 2710, October 1999. 460 [8] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", 461 RFC 4607, August 2006. 463 [9] Asaeda, H. and Y. Uchida, "IGMP/MLD-Based Explicit Membership 464 Tracking Function for Multicast Routers", 465 draft-asaeda-mboned-explicit-tracking-02.txt (work in 466 progress), March 2011. 468 9.2. Informative References 470 [10] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet 471 Group Management Protocol (IGMP) / Multicast Listener Discovery 472 (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", 473 RFC 4605, August 2006. 475 [11] Gundavelli, S, Ed., Leung, K., Devarapalli, V., Chowdhury, K., 476 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 478 [12] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base Deployment 479 for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) 480 Domains", RFC 6224, April 2011. 482 [13] Asaeda, H., Seite, P., and J. Xia, "PMIPv6 Extensions for 483 Multicast", draft-asaeda-multimob-pmip6-extension-06 (work in 484 progress), July 2011. 486 [14] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 487 IPv6", RFC 3775, June 2004. 489 [15] Perkins, Ed., C., "IP Mobility Support for IPv4, Revised", 490 RFC 5944, November 2010. 492 Appendix A. Unicasting General Query 494 IGMPv3 and MLDv2 specifications [2][3] describe that a host MUST 495 accept and process any Query whose IP Destination Address field 496 contains any of the addresses (unicast or multicast) assigned to the 497 interface on which the Query arrives. In general, the all-hosts 498 multicast address (224.0.0.1) or link-scope all-nodes multicast 499 address (FF02::1) is used as the IP destination address of IGMP/MLD 500 General Query. On the other hand, according to [2][3], a router MAY 501 be able to unicast General Query to tracked member hosts in [Query 502 Interval], if the router keeps track of membership information 503 (Section 3). 505 Unicasting IGMP/MLD General Query would reduce the drain on battery 506 power of mobile hosts as only the active hosts that have been 507 receiving multicast contents respond the unicast IGMP/MLD General 508 Query messages and non-active hosts do not need to pay attention to 509 the IGMP/MLD messages. This also allows the upstream router to 510 proceed fast leaves (or shorten leave latency) by setting LMQC/LLQC 511 smaller, because the router can immediately converge and update the 512 membership information, ideally. 514 However, there is a concern in unicast General Query. If a multicast 515 router sends General Query "only" by unicast, it cannot discover 516 potential member hosts whose join requests were lost. Since the 517 hosts do not retransmit the same join requests (i.e., unsolicited 518 Report messages), they loose the chance to join the channels unless 519 the upstream router asks the membership information by sending 520 General Query by multicast. It will be solved by using both unicast 521 and multicast General Queries and configuring the [Query Interval] 522 timer value for multicast General Query and the [Unicast Query 523 Interval] timer value for unicast General Query. However, using two 524 different timers for General Queries would require the protocol 525 extension this document does not focus on. If a router does not 526 distinguish the multicast and unicast General Query Intervals, the 527 router should only use and enable multicast General Query. 529 Also, unicasting General Query does not remove multicasting General 530 Query. Multicast General Query is necessary to update membership 531 information if it is not correctly synchronized due to missing 532 Reports. Therefore, enabling unicast General Query SHOULD NOT be 533 used for the implementation that does not allow to configure 534 different query interval timers as [Query Interval] and [Unicast 535 Query Interval] (See Appendix A for the detail). If a router does 536 not distinguish these multicast and unicast General Query Intervals, 537 the router SHOULD only use and enable multicast General Query. 539 Authors' Addresses 541 Hitoshi Asaeda 542 Keio University 543 Graduate School of Media and Governance 544 5322 Endo 545 Fujisawa, Kanagawa 252-0882 546 Japan 548 Email: asaeda@wide.ad.jp 549 URI: http://www.sfc.wide.ad.jp/~asaeda/ 551 Hui Liu 552 Huawei Technologies Co., Ltd. 553 Huawei Bld., No.3 Xinxi Rd. 554 Shang-Di Information Industry Base 555 Hai-Dian Distinct, Beijing 100085 556 China 558 Email: helen.liu@huawei.com 560 Qin Wu 561 Huawei Technologies Co., Ltd. 562 Site B, Floor 12F, Huihong Mansion 563 No.91 Baixia Rd. 564 Nanjing, Jiangsu 21001 565 China 567 Email: bill.wu@huawei.com