idnits 2.17.1 draft-wu-multimob-igmp-mld-tuning-03.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 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.) ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 660 has weird spacing: '...10], or could...' == 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 25, 2010) is 4932 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'REQUIRE' is mentioned on line 830, but not defined == Missing Reference: 'RFC 5757' is mentioned on line 123, but not defined == Missing Reference: 'RFC5760' is mentioned on line 353, but not defined == Missing Reference: 'ROBUST' is mentioned on line 834, but not defined == Missing Reference: 'ACK' is mentioned on line 838, but not defined == Missing Reference: 'IGMP-ACK' is mentioned on line 843, but not defined == Missing Reference: 'RFC5757' is mentioned on line 851, but not defined == Missing Reference: 'ADAPTIVE' is mentioned on line 847, but not defined -- Looks like a reference, but probably isn't: '3376' on line 660 -- Looks like a reference, but probably isn't: '3810' on line 660 == Unused Reference: 'RFC1112' is defined on line 806, but no explicit reference was found in the text == Unused Reference: 'RFC4607' is defined on line 822, but no explicit reference was found in the text == Unused Reference: 'RFC5790' is defined on line 825, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 14 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network working group Q. Wu 2 Internet Draft H. Liu 3 Category: Informational Huawei 4 Created: October 25, 2010 5 Expires: April 2011 7 Proposal for Tuning IGMPv3/MLDv2 Protocol Behavior in Wireless and 8 Mobile networks 10 draft-wu-multimob-igmp-mld-tuning-03 12 Abstract 14 This document proposes a variety of optimization approaches for 15 tuning IGMPv3 and MLDv2 protocols. It aims to provide useful 16 guideline to allow efficient multicast communication in wireless and 17 mobile networks using the current IGMP/MLD protocols. 19 Conventions used in this document 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC-2119 [RFC2119]. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with 28 the provisions of BCP 78 and BCP 79. 30 This document may contain material from IETF Documents or IETF 31 Contributions published or made publicly available before November 32 10, 2008. The person(s) controlling the copyright in some of this 33 material may not have granted the IETF Trust the right to allow 34 modifications of such material outside the IETF Standards Process. 35 Without obtaining an adequate license from the person(s) controlling 36 the copyright in such materials, this document may not be modified 37 outside the IETF Standards Process, and derivative works of it may 38 not be created outside the IETF Standards Process, except to format 39 it for publication as an RFC or to translate it into languages other 40 than English. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF), its areas, and its working groups. Note that 44 other groups may also distribute working documents as Internet- 45 Drafts. 47 Internet-Drafts are draft documents valid for a maximum of six 48 months and may be updated, replaced, or obsoleted by other documents 49 at any time. It is inappropriate to use Internet-Drafts as 50 reference material or to cite them other than as "work in progress." 52 The list of current Internet-Drafts can be accessed at 53 http://www.ietf.org/ietf/1id-abstracts.txt 55 The list of Internet-Draft Shadow Directories can be accessed at 56 http://www.ietf.org/shadow.html 58 This Internet-Draft will expire on August 15, 2009. 60 Copyright Notice 62 Copyright (c) 2010 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with 70 respect to this document. 72 Table of Contents 74 1. Introduction..................................................3 75 2. Impact of wireless and mobility on IGMP/MLD...................3 76 2.1. Comparison analysis between wired and wireless multicast.4 77 2.2. Link models analysis for wireless multicast..............5 78 2.3. Requirements of wireless and mobile multicast on IGMP/MLD8 79 3. Evaluation of IGMP/MLD on wireless and mobile multicast.......9 80 4. IGMP/MLD tuning optimization for Wireless or Mobile Network..11 81 4.1. Explicit Tracking and Query Suppression.................11 82 4.2. Report Suppression for the hosts........................13 83 4.3. Query Suppression for the routers.......................13 84 4.4. Minimizing Query Frequency by increasing interval each time 85 ............................................................14 86 4.5. Switching Between Unicast Query and Multicast Query.....15 87 4.6. Using General Query with Unicast Query..................16 88 4.7. Retransmission of General Queries.......................16 89 4.8. General Query Suppression with no receiver..............17 90 4.9. Tuning Response Delay according to link type and status.17 91 4.10. Triggering reports and queries quickly during handover.18 92 5. Security Considerations......................................19 93 6. Acknowledgement..............................................19 94 7. References...................................................19 95 7.1. Normative References...................................19 96 7.2. Informative Referencess................................20 97 Authors' Addresses............................................21 99 1. Introduction 101 Multicasting is more efficient a method of supporting group 102 communication than unicasting. With the wide deployment of 103 different wireless networks, multicast communication over wireless 104 network comes to attract more and more interests from content and 105 service providers, but still faces great challenges when considering 106 dynamic group membership and constant update of delivery path due to 107 node movement, which is highly required in the wireless or mobile 108 network. On the other hand, unlike wired network, some of wireless 109 networks often offer limited reliability, consume more power and 110 cost more transmission overhead, thus in worse case are more prone 111 to loss and congestion. 113 Multicast network is generally constructed by IGMP/MLD group 114 management protocol to track valid receivers and by multicast 115 routing protocol to build multicast delivery paths. This document 116 focuses only on IGMP/MLD protocols, which are used by a mobile user 117 to subscribe a multicast group and are most possibly to be exposed 118 to wireless link to support terminal mobility. As IGMP and MLD are 119 designed for fixed users using wired link, they does not work 120 perfectly for wireless link types. They should be enhanced or tuned 121 to adapt to wireless and mobile environment to meet the reliability 122 and efficiency requirements in the scenarios described in 123 [REQUIRE][RFC 5757]. 125 This memo proposes a variety of optimization approaches for tuning 126 IGMP/MLD protocols in wireless or mobile communication environment. 127 It aims to make the minimum tuning on the protocol behavior without 128 introducing interoperability issues, and to improve the performance 129 of wireless and mobile multicast networks. These solutions can also 130 be used in wired network when efficiency and reliability are 131 required. They are discussed in detail in Section 4. 133 2. Impact of wireless and mobility on IGMP/MLD 135 This section analyzes the impact of wireless or mobility on IGMP/MLD 136 by comparing wireless multicast with wired multicast and comparing 137 different wireless link models. It then gives the requirements of 138 wireless and mobile multicast on IGMP/MLD protocols according to the 139 analysis. 141 2.1. Comparison analysis between wired and wireless multicast 143 Existing multicast support for fixed user can be extended to mobile 144 users in wireless environments. However applying such support to 145 wireless multicast is difficult for the following five reasons. 147 O Limited Bandwidth: In contrast with wired link, wireless link 148 usually has limited bandwidth. This situation will be made even 149 worse if wireless link has to carry high volume video multicast 150 data. Also the bandwidth available in upstream direction and 151 downstream direction may not be equal. 153 O Large packets Loss: In contrast with wired multicast, wireless 154 multicast has packet loss that range between 1% and 30%, based on 155 the links types and conditions. And when packets have to travel 156 between home and access networks e.g. through tunnel, the packets 157 are prone to be lost if the distance between the two networks is 158 long. 160 O Frequent Membership change: In fixed multicast, membership change 161 only happens when a user leave or joins a group while in the 162 mobile multicast, membership changes may also occur when a user 163 changes its location. 165 O Prone to performance degradation: Due to possible unwanted 166 interaction of protocols across layers and user movement, the 167 wireless network may be overwhelmed with more excessive traffic 168 than wired network. In worse case, this may lead to network 169 performance degrading and network connection complete loss. 171 O Increased Leave Latency: Unlike fixed multicast, the leave latency 172 in the mobile multicast will be increased due to user movement. 173 And if the traffic has to be transmitted between access network 174 and the home network, or if the handshake is required between 175 these two networks, the Leave Latency will be increased further 176 more. 178 Figure 1 shows the details for the difference between wired/fixed 179 multicast and wireless/mobile multicast. 181 +--------------+---------------------+----------------------------+ 182 | | Wired or fixed | Wireless/mobile | 183 | Issues | Multicast | multicast | 184 +--------------+---------------------+----------------------------+ 185 | | | Limited and variable | 186 | Bandwidth | Plentiful | possibly asymmetric | 187 +--------------+---------------------+----------------------------+ 188 | | | | 189 | Loss of | Infrequent(<1%) | Frequent and variable | 190 | Packets | | (1%-30% based on links) | 191 +--------------+---------------------+----------------------------+ 192 | | | | 193 | Membership | Only when a user | Also when a user moves | 194 | Changes | leaves and joins | to another location | 195 | | a group | | 196 +--------------+---------------------+----------------------------+ 197 | | | More complex due to | 198 | | Possible use of a | wireless links and user | 199 | Reliability | transport-layer | mobility; possible unwanted| 200 | | protocol(such as the| interaction of protocols | 201 | | Multicast File | at transport and link | 202 | | Transfer Protocol) | layers | 203 +--------------+---------------------+----------------------------+ 204 | | | Increased due to | 205 |Leave Latency | not changed by | user movement | 206 | | user movement | and lost packet | 207 -------------------------------------+---------------------------- 208 Figure 1. Comparison between wired/fixed multicast 209 and wireless/mobile multicast 211 2.2. Link models analysis for wireless multicast 213 There are various types of wireless links, each with different 214 feature and performance. In this document, we according to the 215 transmission mode categorize the wireless link type into three 216 typical link models: 218 O Point To Point (PTP) link model 219 O Point To Multipoint (PTMP) link model 220 O Broadcast link model 222 PTP link model is the model with one dedicated link that connects 223 exactly two communication facilities. For multicast transmission, 224 each PTP link has only one receiver and the bandwidth is dedicated 225 for each receiver. Also one unique prefix or set of unique prefixes 226 will be assigned to each receiver. Such link model can be 227 accomplished by running PPP on the link or having separate VLAN for 228 each receiver. 230 PTMP link model is the model with multipoint link which consists of 231 a series of receivers and one centralized transmitter. Unlike P2P 232 link model, PTMP provide downlink common channels and dedicated 233 uplink channel for each user. Bandwidth and prefix in this model 234 are shared by all the receivers on the same link. Therefore 235 Duplicate Address Detection (DAD) should be performed to check 236 whether the assigned address is used by other receivers. 238 Broadcast link model is the model with the link connecting two or 239 more nodes and supporting broadcast transmission. Such link model is 240 quite similar to fixed Ethernet link model and its link resource is 241 shared in both uplink and downlink directions. The bandwidth and 242 prefix are shared by all the receivers and DAD is required to avoid 243 address collision. 245 Figure 2 shows the details for the difference between different 246 wireless link models. 248 +---------------+-----------------+---------------+---------------+ 249 | Features | PTP | PTMP | Broadcast | 250 | | link model | link model | link model | 251 +---------------+-----------------+---------------+---------------| 252 | | | Common | | 253 | Shared link/ |Dedicated uplink | downlink | | 254 | Dedicated link|and downlink | channels and |common downlink| 255 | |channels for each| dedicated | Channel for | 256 | |user | uplink |each user | 257 | | | channels for | | 258 | | | each | | 259 | | | user | | 260 +---------------+-----------------+---------------+---------------| 261 | | | Prefix shared | Prefix shared | 262 | Shared Prefix | Per Prefix for | by all | by all | 263 | /Dedicated | each receiver | receivers | receivers | 264 | Prefix | No need DAD |DAD is required|DAD is required| 265 +---------------+-----------------+---------------+---------------| 266 | | | | | 267 |Shared Service | | | | 268 | Support | Not Support | Support | Support | 269 | | | | | 270 +---------------+-----------------+---------------+---------------| 271 | | Only one node | Link Layer | Broadcast | 272 | | On the link | Multicast | Support | 273 | | Forward | Support | at L2 | 274 | link layer | multicast | using | using switch | 275 | Broadcast | packets to | Backend | | 276 | Multicast | the only | (e.g.,AR) | IGMP/MLD | 277 | Support | receiver | IGMP/MLD | Snooping | 278 | | on the | Snooping | at switch | 279 | | link | at AR | | 280 +---------------+-----------------+---------------+---------------| 281 | | | | | 282 | | | | Ethernet | 283 | Ethernet | Not support | Not support | Support By | 284 | link Support | | | Implementing | 285 | | | | Bridge | 286 | | | | | 287 +---------------+-----------------+---------------+---------------+ 288 Figure 2. Wireless Link Models Analysis 290 2.3. Requirements of wireless and mobile multicast on IGMP/MLD 292 Due to the characteristics of wireless and mobile multicast 293 described in the section 2.1 and 2.2, it is desirable for IGMP and 294 MLD to have the following characteristics when used in wireless and 295 mobile networks [REQUIRE]: 297 o Adaptive to different link characteristics: IGMP and MLD are 298 originally designed for wired multicast and some of their processing 299 is not applicable to wireless multicast for its asymmetrical link, 300 limited bandwidth, larger packet loss rate, increased leave latency, 301 and etc. Also Wireless network has various link types, each of them 302 has different bandwidth and performance. These require IGMP/MLD 303 protocol behavior should be tuned to adapt to different link model 304 and link conditions. 306 o Minimal Join and Leave Latency: Fast join and leave of a 307 subscriber helps to improve the user's experience during channel 308 join and channel zapping. Fast leave also facilitates releasing of 309 unused network resources quickly. Besides, mobility and handover 310 may cause a user to join and leave a multicast group frequently, 311 which also require fast join and leave to accelerate service 312 activation and to optimize resource usages. 314 o Robustness to packet loss: Wireless link has the characteristic 315 that packet transmission is unreliable due to instable link 316 conditions and limited bandwidth. For mobile IP network, packets 317 sometimes have to travel between home network and foreign network 318 and have the possibility of being lost due to long distance 319 transmission. These network scenarios have more strict robustness 320 requirement on delivery of IGMP and MLD protocol messages. 322 o Minimum packet transmission: Wireless link resources are usually 323 more precious and limited compared to their wired counterpart, and 324 are prone to be congested when carrying high volume multicast stream. 325 Minimizing packet exchange without degrading general protocol 326 performance should also be emphasized to improve efficiency and make 327 good use of network capacity and processing capability. 329 o Avoiding packet burst: Large number of packets generated within a 330 short time interval may have the tendency to deteriorate wireless 331 network conditions. IGMP and MLD when using in wireless and mobile 332 networks should be optimized if their protocol message generation 333 has the potential of introducing packet burst. 335 According to these requirements, in the following parts of the 336 document, current versions of IGMP/MLD protocols are evaluated 337 whether their various protocol aspects are applicable to wireless 338 and mobile multicast communications. They will be optimized to meet 339 these requirements without new features introduced on the wire or 340 link, without new message type defined, and without interoperability 341 issues introduced, which is referred to as "tuning" of IGMP/MLD 342 protocols. 344 3. Evaluation of IGMP/MLD on wireless and mobile multicast 346 This section analyzes the applicability of IGMP and MLD to wireless 347 communication in the following aspects: 349 O General evaluation of different versions: IGMPv2 [RFC2236] and 350 MLDv1 [RFC2710] only support ASM communication mode. They do not 351 support SSM subscription and explicit tracking. IGMPv3 [RFC3376] 352 and MLDv2 [RFC3810] and their lightweight version LW-IGMPv3/LW- 353 MLDv2 [RFC5760] support all the features of ASM/SSM communication 354 modes and explicit tracking. Because SSM is more efficient and 355 secure than ASM for IPTV application, and explicit tracking 356 enables faster channel zapping and better manageability capability, 357 IGMPv3/MLDv2 and LW-IGMPv3/MLDv2 are more promising to be deployed 358 widely than IGMPv2 and MLDv1. 360 O Robustness: IGMP/MLD actively sends unsolicited Report or Leave 361 message to join or leave a group, and solicited Report to respond 362 to Queries. Unsolicited Report and Leave messages are more 363 important for ensuring satisfactory user experience and should be 364 guaranteed to improve service performance. Current IGMP and MLD 365 provide the reliability for these messages by non responsive 366 retransmission, which is not adequate from both the robustness and 367 efficiency aspects when they are used on unreliable wireless link 368 or have to be exchanged over the tunnel between home network and 369 access network separated by long distance [ROBUST][ACK]. For 370 IGMPv3/MLDv2, because unsolicited report and leave messages will 371 not be suppressed by report from other host, it is possible to 372 adopt acknowledgement-retransmission to improve reliability and 373 reduce superfluous packet transmission [IGMP-ACK]. 375 Besides, for IGMPv3/MLDv2, because the router could by explicit 376 tracking establishes membership database recording each valid 377 receiver, it is possible to deduce the possible loss of some 378 protocol messages according to the feedback after their 379 transmission, and to take some remedies (e.g. by retransmission) 380 to enable more reliable transmission of these messages in bad 381 conditions. 383 O Efficiency: IGMPv2 and MLDv1 use host suppression to suppress 384 duplicated membership reports on the link. In IGMPv3 and MLDv2, 385 because host suppression is not adopted, the report count will be 386 numerous if the number of valid receivers on the network is large. 387 IGMPv3 and MLDv2 should be optimized to try to minimize 388 unnecessary packet transmission to compensate this drawback. As an 389 example, because an IGMPv3/MLDv2 router has record of each user in 390 its state database by explicit tracking, it is possible to 391 eliminate the need for query timeouts when receiving leave 392 messages and to improve the efficiency by reducing both the 393 unnecessary Queries and reports generated on a network. 395 And as described in [REQUIRE] and [RFC5757], the default timer 396 values and counter values specified in IGMP and MLD were not 397 designed for the mobility context. This may result in a slow 398 reaction following a client join or leave, in possible packet loss 399 under worse conditions, or in overburdening the wireless link by 400 excessive packets exchange than necessary. These issues can be 401 addressed by tuning these parameters for the expected packet loss on 402 a link to optimize service performance and resource usage. 404 The comparison between IGMPv2/MLDv1 and IGMPv3/MLDv2 is illustrated 405 in figure 3. In summary, it is desirable to choose IGMPv3/MLDv2 or 406 LW-IGMPv3/MLDv2 as the group management protocol for wireless or 407 mobile multicast. They should be optimized to adapt to wireless and 408 mobile networks to meet the efficiency and reliability requirement 409 for these networks. These optimizations range from the tuning of the 410 parameters (e.g. the Query Interval and other variables), to the 411 tuning of protocol behavior without introducing interoperability 412 issues. Considering an enhancement in one direction might introduce 413 side effects in another one, balances should be taken carefully to 414 avoid defects and improve protocol performance as a whole. 416 +---------------------+----------------------+-------------------+ 417 | Issues | IGMPv2/MLDv1 | IGMPv3/MLDv2 | 418 +---------------------+----------------------+-------------------+ 419 |Default Timer and | Not designed for | Not designed for| 420 |Robustness Variable | Mobility context | Mobility context| 421 | | Need to be tuned | Need to be tuned| 422 +---------------------+----------------------+-------------------+ 423 | | | | 424 | Explicit Tracking | Not Support | Support | 425 | | | | 426 +---------------------+----------------------+-------------------+ 427 | ASM and SSM | Only Support ASM | | 428 | Subscription | Subscription | Both Support | 429 +---------------------+----------------------+-------------------+ 430 | | | | 431 | Explicit Join | | | 432 | and Leave | Support | Support | 433 | | | | 434 +---------------------+----------------------+-------------------+ 435 | | | | 436 |Host Suppression | Support | Not Support | 437 +---------------------+----------------------+-------------------+ 438 Figure 3. Comparison between IGMPv2/MLDv1 and IGMPv3/MLDv2 440 4. IGMP/MLD tuning optimization for Wireless or Mobile Network 442 As mentioned in section 2, IGMPv3/MLDv2 or LW-IGMPv3/MLDv2 is 443 recommended to be used as the basis for optimization of IGMP/MLD to 444 adapt to wireless and mobile networks. In this section, taking 445 these characteristics requirement into account, we will discuss 446 several optimization approaches for tuning of IGMPv3 and MLDv2 in 447 wireless environment. The optimizations try to minimize the packet 448 transmission for both the Reports and Queries, and at the meanwhile 449 take the factor of improving reliability into account, with minimum 450 cost. Different link types are also considered for the tuning 451 behavior. 453 4.1. Explicit Tracking and Query Suppression 455 In IGMPv2/MLDv1, the member reports are suppressed if the same 456 report has already been sent by another host in the network which is 457 also referred to as host suppression. As described in the A.2 of 458 [RFC3810], the suppression of multicast listener reports has been 459 removed in MLDv2 due to the following reasons: 461 O Routers may want to track per-host multicast listener status on an 462 interface. This enables the router to track each individual host 463 that is joined to a particular group or channel and allow minimal 464 leave latencies when a host leaves a multicast group or channel. 466 o Multicast Listener Report suppression does not work well on 467 bridged LANs. Many bridges and Layer2/Layer3 switches that 468 implement MLD snooping do not forward MLD messages across LAN 469 segments in order to prevent multicast listener report suppression. 471 o By eliminating multicast listener report suppression, hosts have 472 fewer messages to process; this leads to a simpler state machine 473 implementation. 475 o In MLDv2, a single multicast listener report now bundles multiple 476 multicast address records to decrease the number of packets sent. 477 In comparison, the previous version of MLD required that each 478 multicast address be reported in a separate message. 480 Without host suppression, it is possible to enable explicit tracking 481 on a router by which the local replication can be used by the router 482 to inspect incoming join and leave requests, record or refresh the 483 membership state for each host on the interface, and take 484 appropriate action to each received report. In the meanwhile, the 485 router builds a table to track which channel being forwarded to each 486 port. If the channel being requested to view is already being 487 received at the router, it can replicate the stream and forward to 488 this new requester which ensure good response time. 490 By using the tracking table mentioned above, the router has the 491 capability to learn if a particular multicast address has any 492 members on an attached link or if any of the sources from the 493 specified list for the particular multicast address has any members 494 on an attached link or not. Such capability makes Group specific 495 Query or Source-and-Group Specific Queries, which are sent to query 496 other members when a member leaves, unnecessary to be used because 497 the router has already known who are active on the interface using 498 explicit tracking. Therefore it is desirable that these two Queries 499 are eliminated when explicit tracking is used. But General 500 periodical Query by a router to solicit current state reports to 501 refresh existing membership state database should still be used to 502 prevent incorrectness of the database due to the possible loss of 503 explicit join and leave message in some cases. 505 The main benefits of using explicit tracking without Group specific 506 Query or Source-and-Group Specific Queries are that it provides: 508 O minimizing packet number and packet burst: Elimination of Group and 509 Source-Group specific Queries when a member leaves a group will 510 reduce the number of transmitted Group Specific Queries. And 511 finally the total number of Reports in response to Group Specific 512 Queries can be drastically reduced. 514 O Minimal leave latencies: an IGMPv3/MLDv2 router configured with 515 explicit tracking can immediately stop forwarding traffic if the 516 last host to request to receive traffic from the router indicates 517 its leave from the group. 519 O Faster channel changing: The channel change time of the receiver 520 application depends on the leave latency, that is to say, single 521 host can not receive the new multicast stream before forwarding of 522 the old stream has stopped. 524 O Reducing Power consumption: Due to elimination of the suppression 525 of membership reports, the host does not need to spend processing 526 power to hear and determine if the same report has already been 527 sent by another host in the network, which is beneficial to mobile 528 hosts that do not have enough battery power. 530 4.2. Report Suppression for the hosts 532 The large number of Reports and bad link condition may result in 533 packets burst. This packet burst can be mitigated by having the 534 router aggregate the responses (membership reports) from multiple 535 clients. The router can intercept IGMP/MLD reports coming from hosts, 536 and forwards a summarized version to the upstream router only when 537 necessary. Typically this means that the router will forward IGMP/MLD 538 membership reports as follows: 540 - Unsolicited membership reports (channel change requests) are 541 forwarded only when the first subscriber joins a multicast group, or 542 the last subscriber leaves a multicast group. This tells the upstream 543 router to begin or stop sending this channel to this router. 545 - Solicited membership reports (sent in response to a query) are 546 forwarded once per multicast group. The router may also aggregate 547 multiple responses together into a single membership report. 549 4.3. Query Suppression for the routers 551 The large number of Queries and bad link condition may result in 552 packets burst. This packet burst can be mitigated by having the 553 downstream router stop forwarding IGMP/MLD Queries packets sent to 554 the hosts and respond with report as proxy to the upstream router. 555 Typically this means that the router will: 557 - Never send a specific query to any client, and 559 - Send general queries only to those clients receiving at least one 560 multicast group 562 4.4. Minimizing Query Frequency by increasing interval each time 564 In IGMPv3/MLDv2, Group Specific Queries and Source and Group 565 specific Queries are sent for [Last Member Query Count] times with 566 short fixed [Last Member Query Interval], to learn whether there are 567 valid members from an attached link. If the network is undergoing 568 congestion, the multiple transmissions of the queries may further 569 deteriorate the bad conditions. To eliminate the bad effects for 570 this, these Queries can be slowed down when a router can not collect 571 successfully expected members' report responses in the mean while it 572 detects the network congestion is going to happen. The slowing down 573 process of the Queries could be arranged in a prolonged time 574 interval as described in [ADAPTIVE]. 576 The slow down behavior is: a router after sending a Query, if 577 acquires the expected responses from the receivers, refreshes its 578 state database and stop the querying retransmission process, or if 579 after a time interval fails to get the expected report responses, 580 resends a Query with an increased (e.g. double) interval. This 581 process can be repeated, for each time the retransmission is 582 arranged in a prolonged time interval, till the router receives the 583 expected responses, or determines the receiver is unreachable and 584 then stops the sending of the Query ultimately. The router can make 585 judgment on not getting expected response from the Queries in the 586 following cases: 588 O When Group Specific Query and Source and Group Specific Queries 589 are used to track other numbers, the router can not collect any 590 response from the link. 592 O When all group members leave the group or move out of scope, the 593 General Query sent by the router can not solicit any responses 594 from the link, as mentioned in section 4.9. 596 O When General Query is retransmitted due to possible loss deducing 597 from no responses from valid members in the database. 599 O When General Query is retransmitted by a router on startup 600 [RFC3376][RFC3810], it gets no membership response from the 601 interface. 603 O When unicast Query is sent to solicit a particular receiver, if 604 the router can not get responses from the receiver, as described 605 in section 4.5 and 4.6. 607 In the above cases, if the router fails to get expected response 608 from the network, and if the link condition is bad or in congestion, 609 the router could retransmit the Queries in increased interval. This 610 query retransmission with incremental interval enables the router to 611 reduce the total packet retransmission times in the same time period 612 comparing with retransmission for multiple times with fixed interval, 613 and at the mean time gain some degree of reliability. The variable 614 time interval and the termination condition should be configurable 615 and could be set according to actual network condition, which is out 616 the scope of this document. 618 4.5. Switching Between Unicast Query and Multicast Query 620 IGMP/MLD protocols define the use of multicast Queries whose 621 destination addresses are multicast addresses and also allow use of 622 unicast Queries with unicast destination. The unicast Query is sent 623 only for one destination and has the advantages of not affecting 624 other host on the same link. This is especially desirable for 625 wireless communication because the mobile terminal often has limited 626 battery power. But if the number of valid receivers is large, using 627 unicast Query instead of multicast Query will introduce large number 628 of Queries because each Query will be generated for each member, 629 which will not be an efficient use of link resources. In this case 630 the normal multicast Query will be a good choice because only one 631 Query needs to be sent. On the other hand of the number of receivers 632 to be queried is small, the unicast Query is advantageous over 633 multicast one. 635 The router can choose to switch between unicast and multicast Query 636 according to the practical network conditions. For example, if the 637 receiver number is small, the router could send unicast Queries 638 respectively to each receiver to solicit their membership states, 639 without arousing other host which is in the dormant state. When the 640 receiver number reaches a predefined level, the router could change 641 to use multicast Queries. The router could make the switching 642 flexibly according to practical conditions to improve the efficiency. 644 4.6. Using General Query with Unicast Query 646 Unicast Query also can be used in addition to General Query to 647 improve the robustness of solicited reports when General Query fails 648 to collect its valid members. It requires the explicit tracking to 649 be enabled on the router. Its basic behavior is: a router after 650 sending a periodical Query collects successfully all the members' 651 report responses except for one or two which are currently still 652 valid in its database. This may be because the non-respondent ones 653 silently leave the network without any notification, or because 654 their reports are lost due to some unknown reason. The router in 655 this case could choose to unicast a Query respectively to each non- 656 respondent receiver to check whether they are still alive for the 657 multicast reception, without affecting the majority of receivers 658 that have already responded. Unicast Queries under this condition 659 could be sent for [Last Member Query Count] times, following the 660 same rule of [3376] or [3810], or could be resent in incremental 661 interval, as described in section 4.4. 663 4.7. Retransmission of General Queries 665 In IGMPv3 and MLDv2, apart from the continuously periodical 666 transmission, General Query is also transmitted during a router's 667 startup. It will be transmitted for [Startup Query Count] times with 668 [Startup Query Interval], to improve reliability of General Query 669 during startup. There are some other cases where retransmission of 670 General Query is beneficial which are not covered by current 671 IGMPv3/MLDv2 protocols as shown in the following. 673 For example, a router which keeps track of all its active receivers, 674 if after sending a General Query, may fail to get any response from 675 the receivers which are still valid in its membership database. This 676 may be because all the valid receivers leaves the groups or moves out 677 of the range of the link at the moment, or because all the responses 678 of the receivers are lost, or because the sent Query does not arrive 679 at the other side of the link. If current database indicates the 680 number of the valid receiver is not small, the router could choose to 681 compensate this situation by retransmitting the General Query to 682 solicit its active members. 684 This compensating General Query could be sent several times, if the 685 router can not get any feedback from the receivers which are previous 686 in the database. The repetition of the transmission could in fixed 687 interval such as [Last Member Query Interval], or could in prolonged 688 interval if the link condition is not good. 690 4.8. General Query Suppression with no receiver 692 In IGMPv3 and MLDv2, General Query is multicast sent periodically 693 and continuously without any limitations. It helps solicit the 694 state of current valid member but has influence on all terminals, 695 whether they are valid multicast receivers or not. When there is no 696 receiver on the link, the transmission of the General Query is a 697 waste of resources for both terminals and the router. 699 The IGMPv3/MLDv2 router could suppress its transmission of General 700 Query if there is no valid multicast receiver on the link, e.g. in 701 the following cases: 703 O If the last member reports its leave for a group. This could be 704 judged by an explicit tracking router checking its membership 705 database, or by a non explicit tracking router sending Group and 706 Source Group Specific Queries; 708 O If the only member on a PTP link reports its leaving; 710 O If the router after retransmission of General Queries on startup 711 fails to get any response from any member; 713 O If the router previously has valid members but fails to get any 714 response from any member after several rounds of General Queries 715 or Unicast Queries; 717 In these cases the router could make a decision that no member is on 718 this link and totally stop its transmission of periodical General 719 Queries. If afterwards there is valid multicast receiver joins a 720 group, the router could resume the original cycle of transmission of 721 General Queries. Because General Query has influences on all the 722 terminals on the link, suppressing it when it is not needed is 723 beneficial for both the link efficiency and terminal power saving. 725 4.9. Tuning Response Delay according to link type and status 727 IGMPv3 and MLDv2 use delayed response mechanism to spread Report 728 messages from different hosts over a longer interval which can 729 greatly reduce possibility of packet burstiness. This is implemented 730 by the host responding to a Query in a specific time randomly chosen 731 between 0 and [Maximum Response Delay]. The value of [Maximum 732 Response Delay] parameter is determined by the router and is carried 733 in Query messages to inform the valid hosts to make the selection. 734 A long delay will lessen the burstiness but will increase leave 735 latency (the time between when the last listener stops listening to 736 a source or multicast address and when the traffic stops flowing). 738 In order to avoid burstiness of MLD messages and reduce leave 739 latency, explicit tracking with Group Specific Query eliminated is 740 recommended to be used first to reduce leave latency. Then the 741 Response Delay may be dynamically calculated based on the expected 742 number of Reporters for each Query and link type and link status. 744 O If the expected number of Reporters is large and link condition is 745 bad, the system administrator MUST choose the longer Maximum 746 Response Delay; if the expected number of Reporters is small and 747 the link condition is good, the administrator may choose the 748 smaller Maximum response Delay. In this case, the IGMP/MLD packet 749 burstiness can be reduced. 751 o Another case is if the link type is PTP which means the resource 752 is dedicated for one receiver on each link, then the Maximum 753 Response Delay can be chosen smaller, if the link type is shared 754 medium link or P2MP, then the Maximum Response Delay can be 755 configured larger. 757 The Maximum Response Delay can be configured by the administrator as 758 mentioned above, or be calculated automatically by software tool 759 implemented according to experiential model on different link modes. 760 As the router arrives at a value appropriate for current link type 761 and conditions, it will encode the value in Query messages to inform 762 the host to make the response. The determination of the instant 763 Maximum Response Delay value is out of this document's scope. 765 4.10. Triggering reports and queries quickly during handover 767 As a mobile terminal is moving from one network to another, if it is 768 a multicast receiver from a group, its new access network should try 769 to deliver the content to the receiver without disruption or 770 performance deterioration. For the smooth switching between 771 networks, the terminal's membership should be acquired as quickly as 772 possible by the new access network. 774 For the access router, it could trigger a Query to the terminal as 775 soon as it detects a new terminal on its link. This could be a 776 General Query if the router does not know whether or not the 777 terminal is a valid receiver or if the number of the entering 778 terminals is not small. Or this Query could also be a unicast Query 779 for only a small quantity of terminals to prevent unnecessary action 780 of other terminals in the switching area. 782 For the terminal, it could trigger a report if it is currently in 783 the multicast reception state. This helps establish more quickly 784 the membership states and enable faster multicast stream injection 785 because active report from the host does not requires the router to 786 wait for the query-response round in the passive reporting cases. 788 5. Security Considerations 790 They will be described in the later version of this draft. 792 6. Acknowledgement 794 The authors would like to thank Stig,Venaas, Gorry Fairhurst, Thomas 795 C. Schmidt, Marshall Eubanks, Suresh Krishnan, J.William Atwood, 796 WeeSan Lee, Imed Romdhani, Hitoshi Asaeda, Liu Yisong and Wei Yong 797 for their valuable comments and suggestions on this document. 799 7. References 801 7.1. Normative References 803 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 804 requirement levels", RFC 2119, March 1997. 806 [RFC1112] Deering, S. "Host Extensions for IP Multicasting", RFC1112, 807 August 1989. 809 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 810 2", RFC 2236, November 1997. 812 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 813 Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. 815 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 816 Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 817 3376, October 2002. 819 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 820 Version 2(MLDv2) for IPv6", RFC 3810, June 2004. 822 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 823 IP", RFC 4607, August 2006. 825 [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight IGMPv3 and 826 MLDv2 Protocols", RFC5790, February 2010. 828 7.2. Informative Referencess 830 [REQUIRE] H. Liu, Q. Wu, H. Asaeda and TM. Eubanks, "Mobile and 831 Wireless Multicast Requirements on IGMP/MLD Protocols", draft-liu- 832 multimob-igmp-mld-mobility-req-03.txt, March 2010. 834 [ROBUST] A. Sen Mazumder, "Facilitating Robust Multicast Group 835 Management", NOSSDAV'05, June 13-14, 2005, Stevenson, Washington, 836 USA. 838 [ACK] Nikaein, N. and Bonnet, C. "Wireless multicasting in an IP 839 environment" In Proceedings of the 5th International Workshop on 840 Mobile Multimedia Communication MoMuc'98 (Berlin, Germany, Oct. 12- 841 14). IEEE Computer Society Press, 1998. 843 [IGMP-ACK] H. Liu, Q, Wu, "Reliable IGMP and MLD Protocols in 844 Wireless Environment", draft-liu-multimob-reliable-igmp-mld-00.txt, 845 February 2010. 847 [ADAPTIVE] I. Romdhani, J. Munoz, H. Bettahar, and A. Bouabdallah, 848 "Adaptive Multicast Membership Management for Mobile Multicast 849 Receivers", IEEE, 2006. 851 [RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast 852 Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief 853 Survey", RFC 5757, February 2010. 855 Authors' Addresses 857 Qin Wu 858 Huawei Technologies Co., Ltd. 859 Site B, Floor 12, Huihong Mansion,No.91 Baixia Rd. 860 Nanjing, Jiangsu 21001 861 China 862 Phone: +86-25-84565892 864 EMail: sunseawq@huawei.com 866 Hui Liu 867 Huawei Technologies Co., Ltd. 868 Huawei Bld., No.3 Xinxi Rd. 869 Shang-Di Information Industry Base 870 Hai-Dian Distinct, Beijing 100085 871 China 873 EMail: Liuhui47967@huawei.com