idnits 2.17.1 draft-ietf-multimob-igmp-mld-tuning-06.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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 477: '... IGMPv3 and MLDv2 specifications [1][2] describe that a host MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 26, 2012) is 4407 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-pim-explicit-tracking-00 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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 Intended status: Informational H. Liu 5 Expires: September 27, 2012 Q. Wu 6 Huawei 7 March 26, 2012 9 Tuning the Behavior of IGMP and MLD for Routers in Mobile and Wireless 10 Networks 11 draft-ietf-multimob-igmp-mld-tuning-06 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 tuning of IGMPv3/ 19 MLDv2 Queries and timer and counter values. 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 September 27, 2012. 38 Copyright Notice 40 Copyright (c) 2012 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 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Explicit Tracking of Membership Status . . . . . . . . . . . . 4 58 4. Tuning IGMP/MLD Timers and Values . . . . . . . . . . . . . . 4 59 4.1. Tuning IGMP/MLD General Query Interval . . . . . . . . . . 5 60 4.2. Tuning IGMP/MLD Query Response Interval . . . . . . . . . 6 61 4.3. Tuning Last Member Query Timer (LMQT) and Last 62 Listener Query Timer (LLQT) . . . . . . . . . . . . . . . 6 63 4.4. Tuning Startup Query Interval . . . . . . . . . . . . . . 7 64 4.5. Tuning Robustness Variable . . . . . . . . . . . . . . . . 7 65 4.6. Tuning Scenarios for Various Mobile IP Networks . . . . . 8 66 5. Destination Address of Specific Query . . . . . . . . . . . . 9 67 6. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 9 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 73 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 74 Appendix A. Unicasting General Query . . . . . . . . . . . . . . 11 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 77 1. Introduction 79 The Internet Group Management Protocol (IGMP) [1] for IPv4 and the 80 Multicast Listener Discovery Protocol (MLD) [2] for IPv6 are the 81 standard protocols for hosts to initiate joining or leaving of 82 multicast sessions. These protocols must be also supported by 83 multicast routers or IGMP/MLD proxies [5] that maintain multicast 84 membership information on their downstream interfaces. Conceptually, 85 IGMP and MLD work on both wireless and mobile networks. However, 86 wireless access technologies operate on a shared medium or a point- 87 to-point link with limited spectrum and bandwidth. In many wireless 88 regimes, it is desirable to minimize multicast-related signaling to 89 preserve the limited resources of battery powered mobile devices and 90 the constrained transmission capacities of the networks. The motion 91 of a host may cause disruption of a multicast service initiation and 92 termination in the new or previous network upon its movement. Slow 93 multicast service activation following a join may incur additional 94 delay in receiving multicast packets and degrade reception quality. 95 Slow service termination triggered by a rapid departure of the mobile 96 host without leaving the group in the previous network may waste 97 network resources. 99 When IGMP and MLD are used with mobile IP protocols, the proximity of 100 network entities should be considered. For example, when bi- 101 directional tunnel is used with the mobility entities described in 102 [6][7], the mobile host experiences additional latency, because the 103 round-trip time using bi-directional tunnel between mobility entities 104 is larger comparing to the case that a host and an upstream router 105 attach to a LAN. 107 This document describes the ways of tuning the IGMPv3 and MLDv2 108 protocol behavior on multicast router and proxy side for wireless and 109 mobile networks, including query and related timers tuning. The 110 selective optimization that provides tangible benefits to the mobile 111 hosts and routers is given by keeping track of downstream hosts' 112 membership status and varying IGMP/MLD Query types and values to tune 113 the number of responses. This document does not make any changes to 114 the IGMPv3 and MLDv2 protocls and only suggests optimal settings for 115 the configurable parameters of the protocols in mobile and wireless 116 environments. 118 2. Terminology 120 In this document, "router" means both multicast router and IGMP/MLD 121 proxy. 123 3. Explicit Tracking of Membership Status 125 Mobile hosts use IGMP and MLD to request to join or leave multicast 126 sessions. When an adjacent upstream router receives the IGMP/MLD 127 Report messages, it recognizes the membership status on the link. To 128 update the membership status reliably, the router sends IGMP/MLD 129 Query messages periodically, and sends Group-Specific and/or Group- 130 and-Source Specific Queries when a member host reports its leave. 131 IGMP/MLD Query is therefore necessary to obtain the up-to-date 132 membership information, but a large number of the reply messages sent 133 from all member hosts may cause network congestion or consume network 134 bandwidth. 136 The "explicit tracking function" [8] is the possible approach to 137 reduce the transmitted number of IGMP/MLD messages and contribute to 138 the efficiency of mobile communications. It enables the router to 139 keep track of the membership status of the downstream IGMPv3 or MLDv2 140 member hosts. That is, if a router enables the explicit tracking 141 function, it does not always need to ask Current-State Report 142 message's transmission from the receiver hosts since the router 143 implicitly recognizes the (potential) last member host when it 144 receives the State-Change Report reporting a leave. The router can 145 therefore send IGMP/MLD Group-Specific and Group-and-Source Specific 146 Queries LMQC/LLQC times (see Section 4.3 for LMQC/LLQC) only when it 147 recognizes the last member has left from the network. This reduces 148 the transmitted number of Current-State Report messages. 150 Enabling the explicit tracking function is advantageous for mobile 151 multicast, but the function requires additional processing capability 152 and possibly a large memory for routers to keep all membership 153 status. Especially when a router needs to maintain a large number of 154 receiver hosts, this resource requirement is potentially impacted. 155 Therefore, in this document it is recommended that adjacent upstream 156 multicast routers enable the explicit tracking function for IP 157 multicast communications on wireless and mobile networks, if they 158 have enough resources. If operators think that their routers do not 159 have enough resources, they may disable this function on their 160 routers. Note that whether routers enable the explicit tracking 161 function or not, they need to maintain downstream membership status 162 by sending IGMPv3/MLDv2 General Query messages as some IGMPv3/MLDv2 163 messages may be lost during transmission. 165 4. Tuning IGMP/MLD Timers and Values 166 4.1. Tuning IGMP/MLD General Query Interval 168 IGMP and MLD are non-reliable protocols; to cover the possibility of 169 a State-Change Report being missed by one or more multicast routers, 170 "hosts retransmit the same State-Change Report messages [Robustness 171 Variable] - 1 more times", at intervals chosen at random from the 172 range (0, [Unsolicited Report Interval]) [1][2]. Although this 173 behavior increases the protocol robustness, it does not guarantee 174 that the State-Change Report reaches the routers. Therefore, routers 175 still need to refresh the downstream membership information by 176 receiving Current-State Report periodically solicited by IGMP/MLD 177 General Query sent in the [Query Interval] period, in order to 178 enhance robustness of the host in case of link failures and packet 179 loss. It also supports the situation that mobile hosts turn off or 180 move from a network to other network managed by a different router 181 without any notification (e.g., leave request). 183 The [Query Interval] is the interval between General Queries sent by 184 the regular IGMPv3/MLDv2 querier, and the default value is 125 185 seconds [1][2]. By varying the [Query Interval], multicast routers 186 can tune the number of IGMP/MLD messages on the network; larger 187 values cause IGMP/MLD Queries to be sent less often. 189 This document proposes 150 seconds for the [Query Interval] value by 190 changing the Querier's Query Interval Code (QQIC) field specified in 191 the IGMP/MLD Query message, for the case that a router enabling the 192 explicit tracking function potentially operates a large number of 193 member hosts such as more than 200 hosts on the wireless link. This 194 longer interval value contributes to minimizing traffic of Report 195 messages and battery power consumption for mobile hosts. 197 On the other hand, this document also proposes 60 to 90 seconds for 198 the [Query Interval] value for the case that a router enabling the 199 explicit tracking function attaches to a wireless link with higher 200 capacity. This shorter interval contributes to quick synchronization 201 of the membership information tracked by the router but may consume 202 battery power of mobile hosts. 204 If a router does not enable the explicit tracking function, the 205 [Query Interval] value would be its default value, 125 seconds. 207 In situations where Mobile IPv6 [7] is used, when the home agent 208 implements multicast router functionality and multicast data packets 209 are tunneled to and from the home agent, the home agent may want to 210 slow down Query periodicity. It happens, for example, when the home 211 agent detects network congestion. In this case, the home agent 212 starts forwarding queries with the default [Query Interval] value and 213 increases the value in a gradual manner. 215 4.2. Tuning IGMP/MLD Query Response Interval 217 The [Query Response Interval] is the Max Response Time (or Max 218 Response Delay) used to calculate the Max Resp Code inserted into the 219 periodic General Queries. Its default value is 10 seconds expressed 220 by "Max Resp Code=100" for IGMPv3 [1] and "Maximum Response 221 Code=10000" for MLDv2 [2]. By varying the [Query Response Interval], 222 multicast routers can tune the burstiness of IGMP/MLD messages on the 223 network; larger values make the traffic less bursty as host's 224 responses are spread out over a larger interval, but will increase 225 join latency when State-Change Report (i.e., join request) is 226 missing. 228 According to our experimental analysis, this document proposes two 229 tuning scenarios for tuning the [Query Response Interval] value in 230 different wireless link conditions; one scenario is for a wireless 231 link with a lower capacity of network resource or a lossy link, and 232 the other scenario is for a wireless link with enough capacity or 233 reliable condition for IGMP/MLD message transmission. 235 Regarding the first scenario, for instance, when a multicast router 236 attaches to a bursty IEEE 802.11b link, the router configures the 237 longer [Query Response Interval] value, such as 10 to 20 (sec). This 238 configuration will reduce congestion of the Current-State Report 239 messages on a link but may increase join latency and leave latency 240 when the unsolicited messages (State-Change Record) are lost on the 241 router. Note that as defined in Section 4.1.1 of [1], in IGMPv3, the 242 Max Resp Code larger than 128 represents the exponential values, and 243 changes the granularity. For example, if one wants to set the Max 244 Response Time to 20.0 seconds, the Max Resp Code should be expressed 245 with "0b10001001", which is divided into "mant=0b1001" and 246 "exp=0b000". 248 The second scenario may happen for a multicast router attaching to a 249 wireless link having higher capacity of the resource or a point-to- 250 (multi-)point link such as an IEEE 802.16e link, because IGMP/MLD 251 messages do not seriously affect the link condition. The router can 252 seek Current-State Report messages with the shorter [Query Response 253 Interval] value, such as 5 to 10 (sec). This configuration will 254 contribute to quickly (at some level) discovering non-tracked member 255 hosts and synchronizing the membership information. 257 4.3. Tuning Last Member Query Timer (LMQT) and Last Listener Query 258 Timer (LLQT) 260 Shortening the Last Member Query Timer (LMQT) for IGMPv3 and the Last 261 Listener Query Timer (LLQT) for MLDv2 contributes to minimizing leave 262 latency. LMQT is represented by the Last Member Query Interval 263 (LMQI), multiplied by the Last Member Query Count (LMQC), and LLQT is 264 represented by the Last Listener Query Interval (LLQI), multiplied by 265 the Last Listener Query Count (LLQC). 267 While LMQI and LLQI are changeable, it is reasonable to use the 268 default values (i.e., 1 second) for LMQI and LLQI in a wireless 269 network. LMQC and LLQC, whose default value is the [Robustness 270 Variable] value, are also tunable. Therefore, LMQC and LLQC can be 271 set to "1" for routers enabling the explicit tracking function, and 272 then LMQT and LLQT are set to 1 second. However, setting LMQC and 273 LLQC to 1 increases the risk of missing the last member; LMQC and 274 LLQC ought to be set to 1 only when network operators think that 275 their wireless link is stable enough. 277 On the other hand, if network operators think that their wireless 278 link is lossy (e.g., due to a large number of attached hosts or 279 limited resources), they can set LMQC and LLQC to "2" for their 280 routers enabling the explicit tracking function. Although bigger 281 LMQC and LLQC values may cause longer leave latency, the risk of 282 missing the last member will be reduced. 284 4.4. Tuning Startup Query Interval 286 The [Startup Query Interval] is the interval between General Queries 287 sent by a Querier on startup. The default value is 1/4 of [Query 288 Interval]; however, a shortened value such as 1 second would help 289 contribute to shortening handover delay for mobile hosts in, e.g., 290 the base solution with PMIPv6 [9]. Note that the [Startup Query 291 Interval] is a static value and cannot be changed by any external 292 signal. Therefore operators who maintain routers and wireless links 293 need to properly configure this value. 295 4.5. Tuning Robustness Variable 297 To cover the possibility of unsolicited reports being missed by 298 multicast routers, unsolicited reports are retransmitted [Robustness 299 Variable] - 1 more times, at intervals chosen at random from the 300 defined range [1][2]. The QRV (Querier's Robustness Variable) field 301 in IGMP/MLD Query contains the [Robustness Variable] value used by 302 the querier. The default [Robustness Variable] value defined in 303 IGMPv3 [1] and MLDv2 [2] is "2". 305 This document proposes "2" for the [Robustness Variable] value for 306 mobility, when a router attaches to a wireless link having lower 307 capacity of the resource or a large number of hosts. For a router 308 that attaches to a wireless link having higher capacity or is known 309 to be reliable, it is not required to retransmit the same State- 310 Change Report message; hence the router sets the [Robustness 311 Variable] to "1". 313 4.6. Tuning Scenarios for Various Mobile IP Networks 315 In mobile IP networks, IGMP and MLD are used either with three 316 deployment scenarios; (1) running directly between host and access 317 router on a wireless network, (2) running between host and home 318 router through a tunnel link, and (3) running between home router and 319 foreign router through a tunnel link. 321 When a receiver host connects directly through a wireless link to a 322 foreign access router or a home router, the tuning of the IGMP/MLD 323 protocol parameters should be the same as suggested in the previous 324 sections. The example of this scenario occurs when in Proxy Mobile 325 IPv6 (PMIPv6) [6], the mobile access gateway, whose role is similar 326 to a foreign router, acts as a multicast router or proxy. 328 The second scenario occurs when bi-directional tunnel established 329 between host and home router is used to exchange IGMP/MLD messages 330 such as in [7][10]. There are difficulties in tuning the parameters 331 in this situation, because the tunnel link condition is diverse and 332 changeable. When a host is far away from the home router, the 333 transmission delay between the two entities may be longer and the 334 packet delivery may be more unreliable. Thus the effects of the 335 IGMP/MLD message transmission through a tunnel link ought to be 336 considered during the parameter setting. For example, the [Query 337 Interval] and [Query Response Interval] could be set shorter to 338 compensate the transmission delay, and the [Robustness Variable] 339 could be increased for possible packet loss. 341 The third scenario occurs in [9], in which the mobile access gateway 342 (i.e., foreign router) acts as the IGMP/MLD Proxy [5] in PMIPv6 [6]. 343 Through the bi-directional tunnel established with the local mobility 344 anchor (i.e., home router), the mobile access gateway sends summary 345 reports of its downstream member hosts to the local mobility anchor. 346 Apart from the distance factor that influences the parameter setting, 347 the [Query Response Interval] on the local mobility anchor could be 348 set to a smaller value because the number of the mobile access 349 gateways is much smaller compared to that of the host and the chances 350 of packet burst is low for the same reason. And the power 351 consumption due to a lower query interval is not an issue for the 352 moble access gateways because the mobile access gateways are usually 353 not battery-powered. 355 Ideally, the IGMP/MLD querier router adjusts its parameter setting 356 according to the actual mobile IP network conditions to benefit 357 service performance and resource utilization. It would be desirable 358 that a home router determines aforementioned timers and values 359 according to the delay between the initiating IGMP/MLD Query and the 360 responding IGMP/MLD Report, while describing such mechanism 361 dynamically adjusting these timers and values is out of scope of this 362 document. 364 5. Destination Address of Specific Query 366 IGMP/MLD Group-Specific and Group-and-Source Specific Queries defined 367 in [1][2] are sent to verify whether there are hosts that desire 368 reception of the specified group or a set of sources or to rebuild 369 the desired reception state for a particular group or a set of 370 sources. These specific Queries build and refresh multicast 371 membership state of hosts on an attached network. 373 Group-specific queries are sent with an IP destination address equal 374 to the multicast address of interest, as defined in [1][2]. Using 375 the multicast group of interest in the specific query is preferred in 376 this environment because hosts that do not join the multicast session 377 do not pay attention to these specific Queries, and only active 378 member hosts that have been receiving multicast contents with the 379 specified address reply to IGMP/MLD reports. 381 6. Interoperability 383 IGMPv3 [1] and MLDv2 [2] provide the ability for hosts to report 384 source-specific subscriptions. With IGMPv3/MLDv2, a mobile host can 385 specify a channel of interest, using multicast group and source 386 addresses in its join request. Upon its reception, the upstream 387 router that supports IGMPv3/MLDv2 establishes the shortest path tree 388 toward the source without coordinating a shared tree. This function 389 is called the source filtering function and is required to support 390 Source-Specific Multicast (SSM) [3]. 392 Recently, the Lightweight-IGMPv3 (LW-IGMPv3) and Lightweight-MLDv2 393 (LW-MLDv2) [4] protocols have been defined as the proposed standard 394 protocols in the IETF. These protocols provide protocol simplicity 395 for mobile hosts and routers, as they eliminate a complex state 396 machine from the full versions of IGMPv3 and MLDv2, and promote the 397 opportunity to implement SSM in mobile communications. 399 This document assumes that both multicast routers and mobile hosts 400 are IGMPv3/MLDv2 capable, regardless whether the protocols are the 401 full or lightweight version. And this document does not consider 402 interoperability with older version protocols. One of the reasons 403 not being interoperable with older IGMP/MLD protocols is that the 404 explicit tracking function does not work properly with older IGMP/MLD 405 protocols because of a report suppression mechanism; a host would not 406 send a pending IGMP/MLD report if a similar report was sent by 407 another listener on the link. 409 7. IANA Considerations 411 This document has no actions for IANA. 413 8. Security Considerations 415 This document neither provides new functions or modifies the standard 416 functions defined in [1][2][4]. Therefore there is no additional 417 security consideration provided. 419 9. Acknowledgements 421 Luis M. Contreras, Marshall Eubanks, Gorry Fairhurst, Dirk von Hugo, 422 Imed Romdhani, Behcet Sarikaya, Stig Venaas, Jinwei Xia, and others 423 provided many constructive and insightful comments. 425 10. References 427 10.1. Normative References 429 [1] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 430 Thyagarajan, "Internet Group Management Protocol, Version 3", 431 RFC 3376, October 2002. 433 [2] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 434 (MLDv2) for IPv6", RFC 3810, June 2004. 436 [3] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", 437 RFC 4607, August 2006. 439 [4] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet Group 440 Management Protocol Version 3 (IGMPv3) and Multicast Listener 441 Discovery Version 2 (MLDv2) Protocols", RFC 5790, 442 February 2010. 444 10.2. Informative References 446 [5] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet 447 Group Management Protocol (IGMP) / Multicast Listener Discovery 448 (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", 449 RFC 4605, August 2006. 451 [6] Gundavelli, S, Ed., Leung, K., Devarapalli, V., Chowdhury, K., 452 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 454 [7] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 455 IPv6", RFC 6275, July 2011. 457 [8] Asaeda, H. and N. Leymann, "IGMP/MLD-Based Explicit Membership 458 Tracking Function for Multicast Routers", 459 draft-ietf-pim-explicit-tracking-00.txt (work in progress), 460 October 2011. 462 [9] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base Deployment 463 for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) 464 Domains", RFC 6224, April 2011. 466 [10] Perkins, Ed., C., "IP Mobility Support for IPv4, Revised", 467 RFC 5944, November 2010. 469 Appendix A. Unicasting General Query 471 This appendix describes the possible IGMP and MLD protocol extensions 472 for further optimization in mobile and wireless environments. It 473 might be beneficial to include the following consideration when the 474 new version or modification of IGMP and MLD protocols are considered 475 in the future. 477 IGMPv3 and MLDv2 specifications [1][2] describe that a host MUST 478 accept and process any Query whose IP Destination Address field 479 contains any of the addresses (unicast or multicast) assigned to the 480 interface on which the Query arrives. In general, the all-hosts 481 multicast address (224.0.0.1) or link-scope all-nodes multicast 482 address (FF02::1) is used as the IP destination address of IGMP/MLD 483 General Query. On the other hand, according to [1][2], a router may 484 be able to unicast General Query to the tracked member hosts in 485 [Query Interval], if the router keeps track of membership information 486 (Section 3). 488 Unicasting IGMP/MLD General Query would reduce the drain on battery 489 power of mobile hosts as only the active hosts that have been 490 receiving multicast contents respond the unicast IGMP/MLD General 491 Query messages and non-active hosts do not need to pay attention to 492 the IGMP/MLD Query messages. This also allows the upstream router to 493 proceed fast leaves (or shorten leave latency) by setting LMQC/LLQC 494 smaller, because the router can immediately converge and update the 495 membership information, ideally. 497 However, there is a concern in unicast General Query. If a multicast 498 router sends General Query "only" by unicast, it cannot discover 499 potential member hosts whose join requests were lost. Since the 500 hosts do not retransmit the same join requests (i.e., unsolicited 501 Report messages), they lose the chance to join the channels unless 502 the upstream router asks the membership information by sending 503 General Query by multicast. It will be solved by using both unicast 504 and multicast General Queries and configuring the [Query Interval] 505 timer value for multicast General Query and the [Unicast Query 506 Interval] timer value for unicast General Query. However, using two 507 different timers for General Queries would require the protocol 508 extension this document does not focus on. If a router does not 509 distinguish the multicast and unicast General Query Intervals, the 510 router should only use and enable multicast General Query. 512 Also, unicasting General Query does not remove multicasting General 513 Query. Multicast General Query is necessary to update membership 514 information if it is not correctly synchronized due to missing 515 Reports. Therefore, enabling unicast General Query should not be 516 used for the implementation that does not allow to configure 517 different query interval timers as [Query Interval] and [Unicast 518 Query Interval]. If a router does not distinguish these multicast 519 and unicast General Query Intervals, the router should only use and 520 enable multicast General Query. 522 Authors' Addresses 524 Hitoshi Asaeda 525 Keio University 526 Graduate School of Media and Governance 527 5322 Endo 528 Fujisawa, Kanagawa 252-0882 529 Japan 531 Email: asaeda@wide.ad.jp 532 URI: http://www.sfc.wide.ad.jp/~asaeda/ 534 Hui Liu 535 Huawei Technologies Co., Ltd. 536 Huawei Bld., No.3 Xinxi Rd. 537 Shang-Di Information Industry Base 538 Hai-Dian Distinct, Beijing 100085 539 China 541 Email: helen.liu@huawei.com 542 Qin Wu 543 Huawei Technologies Co., Ltd. 544 Site B, Floor 12F, Huihong Mansion 545 No.91 Baixia Rd. 546 Nanjing, Jiangsu 21001 547 China 549 Email: bill.wu@huawei.com