idnits 2.17.00 (12 Aug 2021) /tmp/idnits13311/draft-ietf-multimob-igmp-mld-tuning-02.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 (October 31, 2011) is 3854 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 448, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 451, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 454, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-pim-explicit-tracking-00 == Outdated reference: A later version (-11) exists of draft-asaeda-multimob-pmip6-extension-07 -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '14') (Obsoleted by RFC 6275) Summary: 1 error (**), 0 flaws (~~), 9 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: May 3, 2012 H. Liu 5 Q. Wu 6 Huawei Technologies 7 October 31, 2011 9 Tuning the Behavior of IGMP and MLD for Routers in Mobile and Wireless 10 Networks 11 draft-ietf-multimob-igmp-mld-tuning-02 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 May 3, 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 spectrum 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 [11][14] 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 This document describes the ways of tuning the IGMPv3 and MLDv2 119 protocol behavior on multicast router and proxy side for wireless and 120 mobile networks, including query and other timers tuning. The 121 selective optimization that provides tangible benefits to the mobile 122 hosts and routers is given by keeping track of downstream hosts' 123 membership status and varying IGMP/MLD Query types and values to tune 124 the number of responses. The proposed behavior interoperates with 125 the IGMPv3 and MLDv2 protocols. 127 2. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 130 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in 131 this document are to be interpreted as described in RFC 2119 [1]. 133 In this document, "router" means both multicast router and IGMP/MLD 134 proxy. 136 3. Explicit Tracking of Membership Status 138 Mobile hosts use IGMP and MLD to request to join or leave multicast 139 sessions. When an adjacent upstream router receives the IGMP/MLD 140 Report messages, it recognizes the membership status on the link. To 141 update the membership status reliably, the router sends IGMP/MLD 142 Query messages periodically, and sends Group-Specific and/or Group- 143 and-Source Specific Queries when a member host reports its leave. 144 Then the other member hosts reply IGMP/MLD Report messages to notify 145 their memberships. IGMP/MLD Query is therefore necessary to obtain 146 the up-to-date membership information, but a large number of the 147 reply messages sent from all member hosts may cause network 148 congestion or consume network bandwidth cunsumption. 150 The "explicit tracking function" [9] is the possible approach to 151 reduce the transmitted number of IGMP/MLD messages and contribute to 152 the efficiency of mobile communications. It enables the router to 153 keep track of the membership status of the downstream IGMPv3 or MLDv2 154 member hosts. That is, if a router enables the explicit tracking 155 function, it does not always need to ask Current-State Report message 156 transmission from the receiver hosts since the router implicitly 157 recognizes the (potential) last member host when it receives the 158 State-Change Report. The router can therefore send IGMP/MLD Group- 159 Specific and Group-and-Source Specific Queries LMQC/LLQC times (see 160 Section 4.3 for LMQC/LLQC) only when it recognizes the last member 161 has left from the network. This reduces the transmitted number of 162 Current-State Report messages. 164 Enabling the explicit tracking function is advantageous for mobile 165 multicast, but the function requires additional processing capability 166 and a possibly large memory for routers to keep all membership 167 status. Especially when a router needs to maintain a large number of 168 receiver hosts, this resource requirement is potentially impacted. 169 Therefore, this document recommends that adjacent upstream multicast 170 routers enables the explicit tracking function for IP multicast 171 communications on wireless and mobile networks, if they have enough 172 resources. If operators think that their routers do not have enough 173 resources, they may disable this function on their routers. Note 174 that whether routers enable the explicit tracking function or not, 175 they need to maintain downstream membership status by sending IGMPv3/ 176 MLDv2 General Query messages as some IGMPv3/MLDv2 messages may be 177 lost during transmission. 179 4. Tuning IGMP/MLD Timers and Values 181 4.1. Tuning IGMP/MLD General Query Interval 183 IGMP and MLD are non-reliable protocols; to cover the possibility of 184 a State-Change Report being missed by one or more multicast routers, 185 "hosts retransmit the same State-Change Report messages [Robustness 186 Variable] - 1 more times", at intervals chosen at random from the 187 range (0, [Unsolicited Report Interval]) [2][3]. Although this 188 behavior increases the protocol robustness, it does not guarantee 189 that the State-Change Report reaches the routers. Therefore, routers 190 still need to refresh the downstream membership information by 191 receiving Current-State Report periodically solicited by IGMP/MLD 192 General Query sent in the [Query Interval] period, in order to 193 enhance robustness of the host in case of link failures and packet 194 loss. It also supports the situation that mobile hosts turn off or 195 move from a network to other network managed by a different router 196 without any notification (e.g., leave request). 198 The [Query Interval] is the interval between General Queries sent by 199 the regular IGMPv3/MLDv2 querier, and the default value is 125 200 seconds [2][3]. By varying the [Query Interval], multicast routers 201 can tune the number of IGMP/MLD messages on the network; larger 202 values cause IGMP/MLD Queries to be sent less often. 204 This document proposes 150 seconds for the [Query Interval] value by 205 changing the Querier's Query Interval Code (QQIC) field specified in 206 the IGMP/MLD Query message, for the case that a router enabling the 207 explicit tracking function sends General Query and potentially 208 operates a large number of member hosts such as more than 200 hosts 209 on the wireless link. This longer interval value contributes to 210 minimizing traffic of Report messages and battery power consumption 211 for mobile hosts. 213 On the other hand, this document also proposes 60 to 90 seconds for 214 the [Query Interval] value for the case that a router enabling the 215 explicit tracking function attaches to a wireless link having higher 216 capacity of the resource. This shorter interval contributes to quick 217 synchronization of the membership information tracked by the router 218 but may consume battery power of mobile hosts. 220 If a router does not enable the explicit tracking function, the 221 [Query Interval] value would be its default value, 125 seconds. 223 In situations where Mobile IPv6 [14] is used, when the home agent 224 implements multicast router functionality and multicast data packets 225 are tunneled to and from the home agent, the home agent may want to 226 slow down Query periodicity, especially when network congestion is 227 detected. This can be done by the home agent starting forwarding 228 queries with the default [Query Interval] value and increasing it in 229 a gradual manner until it exceeds the mobile host's lifetime. 231 4.2. Tuning IGMP/MLD Query Response Interval 233 The [Query Response Interval] is the Max Response Time (or Max 234 Response Delay) used to calculate the Max Resp Code inserted into the 235 periodic General Queries. Its default value is 10 seconds expressed 236 by "Max Resp Code=100" for IGMPv3 [2] and "Maximum Response 237 Code=10000" for MLDv2 [3]. By varying the [Query Response Interval], 238 multicast routers can tune the burstiness of IGMP/MLD messages on the 239 network; larger values make the traffic less bursty as host responses 240 are spread out over a larger interval, but will increase join latency 241 when State-Change Report is missing. 243 According to our experimental analysis, this document proposes two 244 tuning scenarios for tuning the [Query Response Interval] value in 245 different wireless link conditions; one scenario is for a wireless 246 link with a lower capacity of network resource or a lossy link, and 247 the other scenario is for a wireless link with enough capacity or 248 reliable condition for IGMP/MLD message transmission. 250 Regarding the first scenario, for instance, when a multicast router 251 attaches to a bursty IEEE 802.11b link, the router configures the 252 longer [Query Response Interval] value, such as 10 to 20 (sec). This 253 configuration will reduce congestion of the Current-State Report 254 messages on a link but may increase join latency and leave latency 255 when the unsolicited messages (State-Change Record) are lost on the 256 router. 258 The second scenario may happen for a multicast router attaching to a 259 wireless link having higher capacity of the resource or a point-to- 260 (multi-)point link such as an IEEE 802.16e link, because IGMP/MLD 261 messages do not seriously affect the link condition. The router can 262 seek Current-State Report messages with the shorter [Query Response 263 Interval] value, such as 5 to 10 (sec). This configuration will 264 contribute to quickly (at some level) discovering non-tracked member 265 hosts and synchronizing the membership information. 267 4.3. Tuning Last Member Query Timer (LMQT) and Last Listener Query 268 Timer (LLQT) 270 Shortening the Last Member Query Timer (LMQT) for IGMPv3 and the Last 271 Listener Query Timer (LLQT) for MLDv2 contributes to minimizing leave 272 latency. LMQT is represented by the Last Member Query Interval 273 (LMQI), multiplied by the Last Member Query Count (LMQC), and LLQT is 274 represented by the Last Listener Query Interval (LLQI), multiplied by 275 the Last Listener Query Count (LLQC). 277 While LMQI and LLQI are changeable, it is reasonable to use the 278 default values (i.e., 1 second) for LMQI and LLQI in a wireless 279 network. LMQC and LLQC, whose default value is the [Robustness 280 Variable] value, are also tunable. Therefore, LMQC and LLQC MAY be 281 set to "1" for routers enabling the explicit tracking function, and 282 then LMQT and LLQT are set to 1 second. However, setting LMQC and 283 LLQC to 1 increases the risk of missing the last member; LMQC and 284 LLQC SHOULD be set to 1 only when network operators think that their 285 wireless link is stable enough. 287 On the other hand, if network operators think that their wireless 288 link is lossy (e.g., due to a large number of attached hosts or 289 limited resources), they MAY set LMQC and LLQC to "2" for their 290 routers enabling the explicit tracking function. Although bigger 291 LMQC and LLQC values may cause longer leave latency, the risk of 292 missing the last member will be reduced. 294 4.4. Tuning Startup Query Interval 296 The [Startup Query Interval] is the interval between General Queries 297 sent by a Querier on startup. The default value is 1/4 of [Query 298 Interval]; however, this document recommends the use of its shortened 299 value such as 1 second since the shorter value would contribute to 300 shortening handover delay for mobile hosts in, e.g., the base 301 solution with PMIPv6 [12]. Note that the [Startup Query Interval] is 302 a static value and cannot be changed by any external signal. 303 Therefore operators who maintain routers and wireless links must 304 properly configure this value. 306 4.5. Tuning Robustness Variable 308 To cover the possibility of unsolicited reports being missed by 309 multicast routers, unsolicited reports are retransmitted [Robustness 310 Variable] - 1 more times, at intervals chosen at random from the 311 defined range [2][3]. The QRV (Querier's Robustness Variable) field 312 in IGMP/MLD Query contains the [Robustness Variable] value used by 313 the querier. The default [Robustness Variable] value defined in 314 IGMPv3 [2] and MLDv2 [3] is "2". 316 This document proposes "2" for the [Robustness Variable] value for 317 mobility, when a router attaches to a wireless link having lower 318 capacity of the resource or a large number of hosts. For a router 319 that attaches to a wireless link having higher capacity of the 320 resource or reliable condition, it is not required to retransmit the 321 same State-Change Report message; hence the router sets the 322 [Robustness Variable] to "1". Note that whether the explicit 323 tracking function is enabled or not, the [Robustness Variable] value 324 SHOULD NOT be bigger than "2". 326 4.6. Tuning Scenarios for Various Mobile IP Networks 328 In mobile IP networks, IGMP and MLD are used either with three 329 deployment scenarios; (1) running directly between host and access 330 router on a wireless network, (2) running between host and home 331 router through a tunnel link, and (3) running between home router and 332 foreign router through a tunnel link. 334 When a receiver host connects directly through a wireless link to a 335 foreign access router or a home router, the tuning of the IGMP/MLD 336 protocol parameters should be the same as suggested in the previous 337 sections. The example of this scenario occurs when route 338 optimization is adopted in MIPv6 [14] or Mobile IP [15], or when in 339 Proxy Mobile IPv6 (PMIPv6) [11], the mobile access gateway, whose 340 role is similar to the one of a foreign router, acts as a multicast 341 router as proposed in [13]. 343 The second scenario occurs when bi-directional tunnel established 344 between host and home router is used to exchange IGMP/MLD messages 345 such as [14][15]. There are difficulties in tuning the parameters in 346 this situation, because the tunnel link condition is diverse and 347 changeable. When a host is far away from the home router, the 348 transmission delay between the two entities may be longer and the 349 packet delivery may be more unreliable. Thus the effects of the 350 IGMP/MLD message transmission through a tunnel link should be 351 considered during the parameter setting. For example, the [Query 352 Interval] and [Query Response Interval] could be set shorter to 353 compensate the transmission delay, and the [Robustness Variable] 354 could be increased for possible packet loss. 356 The third scenario occurs in [12], in which the mobile access gateway 357 (i.e., foreign router) acts as the IGMP/MLD Proxy [10] in PMIPv6 358 [11]. Through the bi-directional tunnel established with the local 359 mobility anchor (i.e., home router), the mobile access gateway sends 360 summary reports of its downstream member hosts to the local mobility 361 anchor. Apart from the distance factor that influences the parameter 362 setting, the [Query Response Interval] on the local mobility anchor 363 could be set to the smaller value since the number of foreign router 364 is much smaller compared to the that of the host and the chances of 365 packet burst is low for the same reason. 367 Ideally, the IGMP/MLD querier router adjusts its parameter setting 368 according to the actual mobile IP network conditions to benefit 369 service performance and resource utilization. It would be desirable 370 that a home router determines aforementioned timers and values 371 according to the delay between the initiating IGMP/MLD Query and the 372 responding IGMP/MLD Report, while describing such mechanism 373 dynamically adjusting these timers and values is out of scope of this 374 document. 376 5. Destination Address of Specific Query 378 IGMP/MLD Group-Specific and Group-and-Source Specific Queries defined 379 in [2][3] are sent to verify whether there are hosts that desire 380 reception of the specified group or a set of sources or to rebuild 381 the desired reception state for a particular group or a set of 382 sources. These specific Queries build and refresh multicast 383 membership state of hosts on an attached network. These specific 384 Queries should be sent to all desired hosts with specific multicast 385 address (not the all-hosts/all-nodes multicast address) as their IP 386 destination addresses, because hosts that do not join the multicast 387 session do not pay attention to these specific Queries, and only 388 active member hosts that have been receiving multicast contents with 389 the specified address reply IGMP/MLD reports. 391 6. Interoperability 393 IGMPv3 [2] and MLDv2 [3] provide the ability for hosts to report 394 source-specific subscriptions. With IGMPv3/MLDv2, a mobile host can 395 specify a channel of interest, using multicast group and source 396 addresses in its join request. Upon its reception, the upstream 397 router that supports IGMPv3/MLDv2 establishes the shortest path tree 398 toward the source without coordinating a shared tree. This function 399 is called the source filtering function and is required to support 400 Source-Specific Multicast (SSM) [8]. 402 Recently, the Lightweight-IGMPv3 (LW-IGMPv3) and Lightweight-MLDv2 403 (LW-MLDv2) [4] protocols have been defined as the proposed standard 404 protocols in the IETF. These protocols provide protocol simplicity 405 for mobile hosts and routers, as they eliminate a complex state 406 machine from the full versions of IGMPv3 and MLDv2, and promote the 407 opportunity to implement SSM in mobile communications. 409 This document assumes that both multicast routers and mobile hosts 410 MUST be IGMPv3/MLDv2 capable, regardless whether the protocols are 411 the full or lightweight version. And this document does not consider 412 interoperability with older version protocols. The main reason not 413 being interoperable with older IGMP/MLD protocols is that the 414 explicit tracking function does not work properly with older IGMP/MLD 415 protocols. 417 7. Security Considerations 419 This document neither provides new functions or modifies the standard 420 functions defined in [2][3][4]. Therefore there is no additional 421 security consideration provided. 423 8. Acknowledgements 425 Luis M. Contreras, Marshall Eubanks, Gorry Fairhurst, Dirk von Hugo, 426 Imed Romdhani, Behcet Sarikaya, Yogo Uchida, Stig Venaas, Jinwei Xia, 427 and others provided many constructive and insightful comments. 429 9. References 431 9.1. Normative References 433 [1] Bradner, S., "Key words for use in RFCs to indicate requirement 434 levels", RFC 2119, March 1997. 436 [2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 437 Thyagarajan, "Internet Group Management Protocol, Version 3", 438 RFC 3376, October 2002. 440 [3] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 441 (MLDv2) for IPv6", RFC 3810, June 2004. 443 [4] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet Group 444 Management Protocol Version 3 (IGMPv3) and Multicast Listener 445 Discovery Version 2 (MLDv2) Protocols", RFC 5790, 446 February 2010. 448 [5] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, 449 August 1989. 451 [6] Fenner, W., "Internet Group Management Protocol, Version 2", 452 RFC 2236, July 1997. 454 [7] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener 455 Discovery (MLD) for IPv6", RFC 2710, October 1999. 457 [8] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", 458 RFC 4607, August 2006. 460 9.2. Informative References 462 [9] Asaeda, H. and N. Leymann, "IGMP/MLD-Based Explicit Membership 463 Tracking Function for Multicast Routers", 464 draft-ietf-pim-explicit-tracking-00.txt (work in progress), 465 October 2011. 467 [10] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet 468 Group Management Protocol (IGMP) / Multicast Listener Discovery 469 (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", 470 RFC 4605, August 2006. 472 [11] Gundavelli, S, Ed., Leung, K., Devarapalli, V., Chowdhury, K., 473 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 475 [12] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base Deployment 476 for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) 477 Domains", RFC 6224, April 2011. 479 [13] Asaeda, H., Seite, P., and J. Xia, "PMIPv6 Extensions for 480 Multicast", draft-asaeda-multimob-pmip6-extension-07 (work in 481 progress), October 2011. 483 [14] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 484 IPv6", RFC 3775, June 2004. 486 [15] Perkins, Ed., C., "IP Mobility Support for IPv4, Revised", 487 RFC 5944, November 2010. 489 Appendix A. Unicasting General Query 491 IGMPv3 and MLDv2 specifications [2][3] describe that a host MUST 492 accept and process any Query whose IP Destination Address field 493 contains any of the addresses (unicast or multicast) assigned to the 494 interface on which the Query arrives. In general, the all-hosts 495 multicast address (224.0.0.1) or link-scope all-nodes multicast 496 address (FF02::1) is used as the IP destination address of IGMP/MLD 497 General Query. On the other hand, according to [2][3], a router MAY 498 be able to unicast General Query to tracked member hosts in [Query 499 Interval], if the router keeps track of membership information 500 (Section 3). 502 Unicasting IGMP/MLD General Query would reduce the drain on battery 503 power of mobile hosts as only the active hosts that have been 504 receiving multicast contents respond the unicast IGMP/MLD General 505 Query messages and non-active hosts do not need to pay attention to 506 the IGMP/MLD messages. This also allows the upstream router to 507 proceed fast leaves (or shorten leave latency) by setting LMQC/LLQC 508 smaller, because the router can immediately converge and update the 509 membership information, ideally. 511 However, there is a concern in unicast General Query. If a multicast 512 router sends General Query "only" by unicast, it cannot discover 513 potential member hosts whose join requests were lost. Since the 514 hosts do not retransmit the same join requests (i.e., unsolicited 515 Report messages), they loose the chance to join the channels unless 516 the upstream router asks the membership information by sending 517 General Query by multicast. It will be solved by using both unicast 518 and multicast General Queries and configuring the [Query Interval] 519 timer value for multicast General Query and the [Unicast Query 520 Interval] timer value for unicast General Query. However, using two 521 different timers for General Queries would require the protocol 522 extension this document does not focus on. If a router does not 523 distinguish the multicast and unicast General Query Intervals, the 524 router should only use and enable multicast General Query. 526 Also, unicasting General Query does not remove multicasting General 527 Query. Multicast General Query is necessary to update membership 528 information if it is not correctly synchronized due to missing 529 Reports. Therefore, enabling unicast General Query SHOULD NOT be 530 used for the implementation that does not allow to configure 531 different query interval timers as [Query Interval] and [Unicast 532 Query Interval]. If a router does not distinguish these multicast 533 and unicast General Query Intervals, the router SHOULD only use and 534 enable multicast General Query. 536 Authors' Addresses 538 Hitoshi Asaeda 539 Keio University 540 Graduate School of Media and Governance 541 5322 Endo 542 Fujisawa, Kanagawa 252-0882 543 Japan 545 Email: asaeda@wide.ad.jp 546 URI: http://www.sfc.wide.ad.jp/~asaeda/ 548 Hui Liu 549 Huawei Technologies Co., Ltd. 550 Huawei Bld., No.3 Xinxi Rd. 551 Shang-Di Information Industry Base 552 Hai-Dian Distinct, Beijing 100085 553 China 555 Email: helen.liu@huawei.com 557 Qin Wu 558 Huawei Technologies Co., Ltd. 559 Site B, Floor 12F, Huihong Mansion 560 No.91 Baixia Rd. 561 Nanjing, Jiangsu 21001 562 China 564 Email: bill.wu@huawei.com