idnits 2.17.1 draft-liu-multimob-igmp-mld-mobility-req-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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC2119' on line 71 == Missing Reference: '9' is mentioned on line 657, but not defined == Missing Reference: '10' is mentioned on line 660, but not defined == Missing Reference: '11' is mentioned on line 663, but not defined == Missing Reference: '12' is mentioned on line 667, but not defined -- Looks like a reference, but probably isn't: 'ACK-draft' on line 534 == Missing Reference: '13' is mentioned on line 670, but not defined == Missing Reference: '14' is mentioned on line 674, but not defined == Unused Reference: '1' is defined on line 629, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 648, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network working group H. Liu 2 Internet Draft Q. Wu 3 Category: Informational Huawei Technologies. 4 Created: March 8, 2010 H. Asaeda 5 Expires: September 2010 Keio Universitys 6 TM. Eubanks 7 Iformata Communications 9 Mobile and Wireless Tuning Requirements on IGMP/MLD Protocols 11 draft-liu-multimob-igmp-mld-mobility-req-03 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with 16 the provisions of BCP 78 and BCP 79. 18 This document may contain material from IETF Documents or IETF 19 Contributions published or made publicly available before November 20 10, 2008. The person(s) controlling the copyright in some of this 21 material may not have granted the IETF Trust the right to allow 22 modifications of such material outside the IETF Standards Process. 23 Without obtaining an adequate license from the person(s) controlling 24 the copyright in such materials, this document may not be modified 25 outside the IETF Standards Process, and derivative works of it may 26 not be created outside the IETF Standards Process, except to format 27 it for publication as an RFC or to translate it into languages other 28 than English. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six 36 months and may be updated, replaced, or obsoleted by other documents 37 at any time. It is inappropriate to use Internet-Drafts as 38 reference material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 45 This Internet-Draft will expire on August 15, 2009. 47 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with 57 respect to this document. 59 Abstract 61 This document presents the requirements for IGMP/MLD protocols to 62 allow the deployment of mobile multicast service. It is intended to 63 provide useful guideline when adapting current IGMP/MLD protocols to 64 support terminal mobility. 66 Conventions used in this document 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in RFC-2119 [RFC2119]. 72 Table of Contents 74 1. Introduction................................................. 3 75 2. Problem Statement ........................................... 3 76 3. The Behavior of IGMP and MLD Protocols....................... 5 77 3.1. IGMP Version 1.......................................... 5 78 3.2. IGMP Version 2.......................................... 5 79 3.3. IGMP Version 3.......................................... 6 80 3.4. Multicast Listener Discovery Protocols.................. 7 81 3.5. Lightweight IGMPv3/MLDv2................................ 7 82 4. Requirements for Wireless and Mobile Multicast............... 7 83 4.1. Functional Requirements for Mobile Multicast............ 7 84 4.2. Requirements on Tuning IGMP/MLD Protocol Parameters .... 8 85 4.3. Requirements for Handover............................... 9 86 4.4. Requirements for Wireless Link Types................... 10 87 4.5. Requirements for Explicit Tracking .................... 11 88 5. IGMP/MLD Tuning Requirements for Mobility and Wireless 89 Environment.................................................... 11 90 5.1. Evaluation of Current Features of IGMP and MLD Protocols11 91 5.2. IGMP and MLD Protocol for Wireless or Mobile Network... 12 92 6. Security Considerations..................................... 14 93 7. References.................................................. 14 94 7.1. Normative References................................... 14 95 7.2. Informative Referencess ............................... 15 96 Authors' Addresses............................................. 16 98 1. Introduction 100 IP multicast efficiently distributes data to a number of receiver 101 hosts in IP networks simultaneously thereby saving network and 102 server resources. The receiver hosts use IGMP for IPv4 [2] and MLD 103 for IPv6 [3] to receive or to stop receiving data via multicast 104 (using join/leave or a subscribe/unsubscribe requests). The 105 intermediate routers construct multicast tree between the source and 106 receiver hosts with multicast routing protocols. 108 IGMP and MLD protocols are originally designed to work on wired 109 broadcast shared links (e.g. Ethernet) by taking into account the 110 wired link characteristics. When they are used on a wireless link, 111 it is necessary to consider how to make the protocols better fit the 112 properties of the wireless link. In this document, the requirements 113 for IGMP and MLD protocols that enable mobile multicast services via 114 a wireless link are discussed. The wireless link type could be but 115 should not be restricted to 3GPP, IEEE 802.11 and 802.16, which are 116 or may be popularly adopted in providers' network 118 IGMP or MLD protocol can work with any mobile protocols (e.g., MIPv6 119 [9], PMIPv6 [10], NEMO [11]) independently, if these protocols 120 support multicast. However, context transfer or other procedures to 121 provide seamless handover depend on the mobile protocols. Therefore, 122 this document does not assume mobile protocols that mobile hosts use, 123 and only protocol-independent considerations and requirements 124 regarding how mobile protocols should work with IGMP/MLD for 125 seamless handover are discussed. 127 2. Problem Statement 129 A mobile host usually accesses to a network via a wireless link. 130 When a mobile host wants to join or leave an IP multicast session, 131 it sends IGMP/MLD messages for the request to its upstream equipment. 132 The upstream equipment may be a wireless access router (in case of 133 MIPv6), a mobile router (in case of NEMO), a gateway (in case of 134 PMIPv6), or a switch or router that supporting IGMP/MLD Proxy. In 135 the following part of this document, it is expressed as an "upstream 136 router" or "multicast router". 138 The upstream router should maintain the group membership states 139 indicating which multicast sessions mobile hosts have joined and 140 constructs the multicast tree towards the source with multicast 141 routing protocol procedures. If upstream wireless routers or 142 switches are wireless and do not maintain this group membership 143 states, they will flood all multicast data received onto each 144 wireless link, which is not an efficient use of wireless bandwidth 145 resources. Thus IGMP and MLD protocols are necessary to be 146 supported on the mobile and wireless hosts and their upstream 147 routers. 149 Apart from the above general wireless link characteristic, different 150 wireless technique exhibits different features. For the purpose of 151 generality, this memo does not concentrate on a specific wireless 152 link layer protocol, but rather focus on the popular link model 153 being abstracted from currently in-used wireless techniques, such as 154 IEEE 802.11x, IEEE 802.16x, 3GPP,and etc. 156 According to the properties of a wireless link, bandwidth usage and 157 packet loss should be carefully considered. It is also necessary to 158 take care of battery consumption of a mobile host. These conditions 159 encourage the minimization of exchanged data packets and control 160 messages including IGMP/MLD protocol messages if possible. 162 On the other hand, IGMP and MLD are asymmetric and non-reliable 163 protocols; multicast routers need solicited membership reports by 164 periodical IGMP/MLD Queries, in order to be robust in front of host 165 or link failures and packet loss. It is encouraged that host-and- 166 router communication is effectively coordinated to support limited 167 wireless or terminal resources. 169 When a host receiving multicast data moves from an access link to 170 another one, the host wants to continuously receive the multicast 171 data without any packet loss and session interruption, and the 172 network provider wants to minimize the amount of duplicated 173 multicast traffic. This seemless handover is a necessary component 174 of mobile multicast communication, which introduces additional 175 requirements on IGMP/MLD protocols during handover. Precisely, the 176 moving host's membership information should be transmitted to the 177 new access link as quickly as possible. This procedure reduces the 178 host's join latency. Or, if there is no member host on the access 179 link after the host moves, then the upstream router should leave 180 from the multicast session quickly as well. This contributes to 181 releasing the unnecessary resources. 183 All the above problems stated above together with others are to be 184 discussed in this memo. In the following sections, we briefly 185 introduce the IGMP/MLD protocols, analyze the protocol behavior and 186 the requirements of wireless link characteristic and IP multicast 187 mobile service, and discuss the possibility of the enhancement of 188 the protocols if needed. The illustration below will consider both 189 IPv4 and IPv6 networks. 191 3. The Behavior of IGMP and MLD Protocols 193 A multicast receiving host uses IGMP protocols to join and leave a 194 multicast group on an IPv4 network, and uses MLD protocols on an 195 IPv6 network. 197 3.1. IGMP Version 1 199 IGMP Version 1 [5] defines the basic operating model between a 200 multicast receiving host and its upstream router to determine group 201 membership. The router periodically sends Host Membership Queries 202 to its attached network. A host sends a Host Membership Report to 203 the router when it decides to join a group, or it responds to the 204 Queries passively. The host does not send group leave message 205 explicitly, but rather silently leaves the group by ignoring a Host 206 Membership Query, which causes an undesirably long leave latency. 208 IGMPv1 is an obsolete protocol; hence it is not recommended for 209 mobile hosts to implement IGMPv1, whereas upstream routers may need 210 to support IGMPv1 to keep compatibility with non-upgraded mobile 211 hosts. 213 3.2. IGMP Version 2 215 IGMP Version 2 [6] has the optimizations that an IGMPv2 host can 216 explicitly send a Leave Report when it decides to stop receiving 217 multicast data. This enables faster leave from the multicast group. 218 When a multicast router receives a leave message, it will generate a 219 Group-Specific Query to verify whether there is other receiver for 220 the same group on its network. IGMPv2 also supports the case when 221 multiple multicast routers are connected to the same shared network. 222 In this case, a single Querier is elected by ordering the IP 223 addresses to take on the duty of sending Query packets. 225 Several timers are defined in IGMPv2 and their values are 226 configurable. Query Interval is the interval between General 227 Queries sent by a router, which has influence on the total number of 228 IGMPv2 messages on a link. Query Response Interval is the maximum 229 response time of a report after a host receives the General Query. 230 It will reduce the bursty traffic of the reports on a link. Startup 231 Query Interval is the interval between the queries sent by the 232 Querier in startup. Last Member Query Interval is the maximum 233 response time used by Group-Specific Queries in response to leave 234 from session. This value can be tuned to modify the leave latency 235 of the network. 237 IGMPv2 also introduces timer related counters to make the protocol 238 function more robust. For example, it defines Robustness Variable 239 to quantify the number of reports sent out to prevent packet loss. 240 Last Member Query count is used to set the number of Group-Specific 241 Queries sent before the router assumes there is no local member. 242 Startup Query Count is the number of Queries issued on startup. 243 These values can be tuned according to the expected packet loss on a 244 link. 246 3.3. IGMP Version 3 248 IGMP Version 3 [2] introduces a big enhancement to the previous two 249 versions. It defines INCLUDE and EXCLUDE filter modes on both the 250 host and router side. With these filter modes, a host can specify 251 the desired or undesired source address(es) except for multicast 252 address(es) in IGMP report messages. 254 IGMPv3 router uses filter mode to process the group record properly. 255 The router also maintains a group-timer to indicate the filter mode 256 switch over and a source-timer to time each valid source. A new 257 type of Source-and-Group-Specific Query is utilized to verify there 258 are no receivers desiring to receive traffic from listed sources for 259 a particular group, which has been requested to no longer be 260 forwarded. 262 Another modification is that IGMPv3 does not adopt the report 263 suppression mechanism. Without suppression, the number of report 264 messages may increase greatly on a link. IGMPv3 solves this problem 265 by merging reports or queries into a combined packet. 267 An advantage of eliminating report suppression is that it provides 268 the possibility for the router to keep track of host membership 269 status on a link. This Explicit Tracking [2] consumes memory on the 270 router, but provides feasibility to manage end users on a per-user 271 basis and implements fast leave function. 273 3.4. Multicast Listener Discovery Protocols 275 MLDv1 and MLDv2 are respectively derived from IGMPv2 and IGMPv3 to 276 be applied for IPv6 networks. The important difference between MLD 277 and IGMP is that MLD is a sub-protocol of ICMPv6 and its message 278 types are a subset of ICMPv6 messages. For MLDv1, parts of the 279 message types are renamed to distinguish from those of IGMPv2. 281 3.5. Lightweight IGMPv3/MLDv2 283 IGMPv3 and MLDv2 enable the support of Source-Specific Multicast 284 (SSM) communication [8] by indicating desired sources in the INCLUDE 285 Group Record. Its usage of excluding undesired sources by an 286 EXCLUDE filter mode operation has little practical prototype use and 287 no desired use case. Moreover, when a host requests to join or 288 leave session whose operation changes INCLUDE filter mode to EXCLUDE 289 filter mode or vise versa, both the host and the upstream router 290 will suffer from complex state transition and scalability problems. 292 In [4], simplified version protocols of IGMPv3/MLDv2 are defined to 293 keep the INCLUDE source-filtering characteristics to support SSM 294 communication and remove the EXCLUDE filter mode operation. With 295 the reduced number of report types and and without the filter-mode 296 related processing,the host-side kernel implementation and 297 especially the router's operation are greatly simplified, and less 298 states need to be stored by lightweight router compared to their 299 full IGMPv3/MLDv2 counterpart. These improvements are especially 300 desirable for multicast mobility, as wireless devices typically have 301 limited storage and CPU processing capabilities. 303 4. Requirements for Wireless and Mobile Multicast 305 4.1. Functional Requirements for Mobile Multicast 307 Any-Source Multicast (ASM) is a traditional multicast communication 308 model in which receivers requests all data from a multicast address, 309 which is denoted with (*,G). A host joining a (*,G) session will 310 receive data from all the sources sending to the specified multicast 311 address. On the other hand, in the SSM communication, a host 312 specifies both source and multicast addresses and receives the 313 traffic from the specified source(s). The subscribed source- 314 specific multicast session is denoted by an (S,G) and called a 315 channel. 317 All the versions of IGMP/MLD support the ASM communication. It is 318 not recommended to use IGMPv1 in mobile communications since it does 319 not have a robust mechanism to retransmit report messages, does not 320 provide fast leave, and does not support SSM, as described in 321 Section 2. IGMPv2 and MLDv1 are possible to be used in mobile 322 communications, but they do not support SSM subscription. 324 To enable the SSM communication, a mobile host must use IGMPv3/MLDv2 325 or LW-IGMPv3/LW-MLDv2. As described in [4], there is no functional 326 difference to subscribe (S,G) channels between the full versions of 327 IGMPv3/MLDv2 and the lightweight version protocols. The lightweight 328 version protocols have the advantage of simpler processing. 330 IGMP/MLD protocols (except IGMPv1) protocols themselves implement 331 some fast join and fast leave functions. When a host joins a 332 multicast session, it sends unsolicited join report to its upstream 333 router immediately. The Startup Query Interval has been set to 1/4 334 of the General Query value to enable the faster join at startup. 335 When the host ceases from listening a session, it sends a request to 336 leave the session immediately. The Group-Specific or Source-and- 337 Group-Specific Queries are triggered when an IGMP/MLD router knows 338 that the reception for a group or a source-specific group has been 339 terminated. This helps the router acquire the multicast membership 340 information as fast as possible when all the members as a whole 341 leave a group. The time to complete leaving from a session is 342 referred to as leave latency. Lower leave latency (i.e. fast leave) 343 has the advantage of quickly releasing the network resources. 345 4.2. Requirements on Tuning IGMP/MLD Protocol Parameters 347 Within each protocol's scope, the number of transmitted packets on a 348 wireless link could be further decreased by tuning timer values. 349 For example, Query Interval can be set to a larger value to reduce 350 the packet quantity. The Query Response interval could be widened 351 to avoid the burst of messages. 353 On the other hand, to cover the possibility of a State-Change Report 354 being missed by one or more multicast routers, a host transmits the 355 same State-Change Report [Robustness Variable] times in all [2][3]. 356 However, this manner does not only guarantee that the State-Change 357 Report is reached to the routers, but also increases the number or 358 amount of State-Change Report messages on a wireless link. It is 359 required to tune these values with the good balance of protocol 360 robustness and the amount of traffic. 362 As well, various IGMP/MLD timers should be configurable. If non- 363 default settings are used, they MUST be consistent among all routers 364 on a single network. 366 4.3. Requirements for Handover 368 [12] categorized the diversified mobile IP schemes by their group 369 subscription manner principally as home subscription and remote 370 subscription. These two different subscription has important 371 influences on the handover behaviour. Since different mobile and 372 handover protocols may need different parameters and different 373 optimizations, this document describes the possible scenarios with 374 examples in MIPv6 [9] but only discussed the possible requirements 375 related to the group-subscription related behavior. 377 In home subscription (also referred to tunneled method), the 378 IGMP/MLD message should be encapsulated and tunneled to the home 379 network. The multicast router (e.g., Home Agent) on home network 380 will be responsible for joining and pruning a multicast tree. When 381 a mobile host moves to a new foreign network, it does not need to 382 re-join the multicast group. 384 In the remote subscription approach (also referred to optimal 385 multicast routing), a mobile host joins the group via a local 386 multicast router on the foreign network. The router intercepts the 387 host's report message and joins or prunes the multicast tree on the 388 foreign network. After handover to another foreign network, the 389 host needs to resend new reports to new access routers and the 390 latters will construct the new multicast tree on the new network. 391 If the old multicast branches have been torn down before the new 392 branches being constructed, the host will suffer from packets loss 393 during the handover. 395 To prevent packet loss, a make-before-break mechanism SHOULD be 396 provided. It requires a mobile host to join the group on the new 397 network as soon as possible once it decides to switch to the new 398 network. The host keeps the reception of the "old" multicast data 399 until the traffic from new branches arrives. Then the host begins 400 issuing leave reports to the previous attached multicast router. 402 The possibility of packet loss can be reduced by predicting the 403 movement of a mobile node during handover. The handover can be 404 initiated either by the mobile host or by the network. In the 405 mobile-initiated handover, the host acquires the handover 406 information quickly and can send early reports. In the network- 407 initiated handover, the network entity indicates the possible 408 handover situation and the mobile host does not invoke any process. 410 It may be possible that IGMP and MLD could be extended to carry the 411 handover indication from a previous router to a new router to 412 facilitate the fast join and fast leave. Since IGMP/MLD protocol or 413 message extension may require additional operational costs or 414 interoperability problems, it must be carefully defined. 416 IGMP/MLD hosts and routers can adjust their timer and counter values 417 to make faster join/leave during handover, as described in Section 418 4.2. The adjustment is carried out by the application according to 419 the actual wireless situations and policies of the management. 421 4.4. Requirements for Wireless Link Types 423 Wireless access technique could be categorized to three different 424 types - shared, point-to-point (PTP), and point-to-multipoint (PTMP) 425 links. The shared link (e.g.IEEE802.11) resembles Ethernet that the 426 end-users share the same wireless media. IGMP/MLD should be 427 generally applicable because they are originally designed for the 428 shared Ethernet. 430 For PTP link (e.g.3G GSM, IEEE802.16), different links are separated 431 physically or logically from each other. The standard use of IGMP 432 and MLD requires the multicast router to maintain a separate 433 interface state for each link. It will be inefficient if the number 434 of the receiver becomes large. Considering there is only one 435 receiving host on each link, the operation of IGMP/MLD relating to 436 multiple receivers per interface should be taken out. For example, 437 Host Suppression and Delaying Response are unnecessary. Instead the 438 mobile could respond the reports immediately, which helps 439 implementing faster join and leave capability. Besides, when a host 440 requests its leave from the group, the successive Group-Specific 441 Query or Group-and-Source-Specific Query to inquire other possible 442 receivers is not needed. Finally, the periodic General Query which 443 is sent separately to each mobile host, is unnecessary to be sent to 444 all the links but rather only to the hosts which have made the group 445 join and have reception state on the router. This is desirable for 446 the battery saving for the mobile terminal not involved in the 447 multicast reception will not be frequently awakened when in the 448 sleeping mode. 450 Wireless PTMP links (e.g.3GPP MBMS, and IEEE 802.16) is point-to- 451 multipoint (or shared) in down link direction, but point-to-point in 452 up link direction. The IGMP/MLD protocols should present both 453 shared media and point-to-point media features. Host Suppression 454 and Delaying Response should not be adopted. Group-Specific Query 455 and Group-and-Source-Specific Query triggered by group leave are 456 also unnecessary. And General Query should be multicast to the 457 shared down link, which is the same as the shared link model but 458 different from the PTP link. 460 4.5. Requirements for Explicit Tracking 462 Since the full and lightweight IGMPv3 and MLDv2 protocols disable a 463 report suppression mechanism (described in Section 3.3), multicast 464 routers working with these protocols can choose to implement 465 explicit tracking of mobile hosts [2]. The explicit tracking 466 enables the router to learn the reception state of each receiver, 467 but at the meantime consumes substantial memory resources on the 468 router. 470 The advantage of explicit tracking is that it provides better 471 manageability of mobile receivers. It is unnecessary to issue 472 Group-Specific queries and Source-Specific Queries to stop receiving 473 on subnets whose router keeps track of group and source receivers. 475 5. IGMP/MLD Tuning Requirements for Mobility and Wireless Environment 477 5.1. Evaluation of Current Features of IGMP and MLD Protocols 479 To evaluate whether IGMP and MLD protocols are applicable to 480 wireless communication, their key features should be analyzed 481 regarding their functionality, reliability and efficiency. 483 IGMP/MLD join and leave are sent unsolicitedly when a host intends 484 to join or leave a group. They are closest to user's experience and 485 must be guaranteed. Current IGMP and MLD provide the reliability 486 for these packets by retransmission for [Robustness Variable] times. 487 Retransmission provides reliability to some degree but if in most 488 cases the first packet is a success, the other retransmissions are a 489 waste of resources. In other cases if all the retransmission fail 490 the host has no indication of the situation. Besides, it is 491 troublesome to determine the value of [Robustness Variable], for the 492 wireless link condition may alter from time to time and a host may 493 change its connection from one access network to another. Thus it 494 is required that the transmission reliability for IGMP/MLD join and 495 leave should be enhanced to improve the user experience. 497 IGMPv2 and MLDv1 only support ASM communication mode, but does not 498 support SSM subscription and explicit tracking, which limits their 499 widespread deployment in future multicast network. IGMPv3 and MLDv2 500 (and also LW-IGMP/LW-MLD) support all the features of ASM and SSM 501 communication, and of explicit tracking. They are much better the 502 candidates for wireless and mobile networks than their previous 503 versions. The disadvantage of (LW-) IGMPv3 and MLDv2 is that 504 because host suppression is not available, the report count in 505 response to query is not a small number, if there are many active 506 receivers on the network. Even though the protocols enable a host 507 to utilize combined report to reduce the packet number, further 508 optimization is still required to efficiency the bandwidth usage. 510 As the summary, IGMP and MLD for wireless or mobile network should 511 have the following ideal characteristics: 513 o ASM and SSM mode support 515 o Explicit tracking[2] 517 o Enhanced robustness. 519 O Minimized packet transmission and packet burst 521 5.2. IGMP and MLD Protocol for Wireless or Mobile Network 523 (LW-) IGMPv3/MLDv2 are suggested to be used as the basis for 524 optimization for wireless and mobile networks, because they are more 525 applicable to current multicast scenarios, as illustrated in section 526 5.1. Apart from the parameter tuning (in section 4.2), there are 527 several other measures which are suggested to be used when make this 528 adaption. 530 5.2.1 Robustness Enhancement for unsolicited report 532 For the reasons given in section 5.1, acknowledge-retransmission is 533 suggested to be used for a unsolicited (LW-) IGMPv3/MLDv2 Report 534 [ACK-draft], whose mechanism is commonly deployed in today's 535 protocol design. Its basic protocol behavior is direct and simple. 536 A host after sending a join report starts a retransmission timer and 537 waits for the acknowledgement (ACK) from the router. If the ACK is 538 not received when the timer expires, another report is retransmitted. 539 A parameter should also be used to limit the maximum retransmission 540 times for the report. 542 5.2.2 Efficiency Considerations for Passive Report 543 Passive reports in response to Queries are not acknowledged for not 544 introducing too many report packets on the network, and they are not 545 acknowledged also because the Query-Response to-and-fro implies an 546 acknowledgement to some degree. 548 Further, if the number of the receivers on a network is large, it is 549 suggested that Queries are sent only once, rather than for 550 [Robustness Variable] times. This is because each turn of Query 551 will trigger all active members' response, which is not an efficient 552 usage of bandwidth resources. 554 The passive report manner could also be optimized for PTP and PTMP 555 link types. Because these two types of links are not shared (or 556 exclusive) for the end users, the Delayed Response which prevent 557 report collision on a link is not necessary. Without Delayed 558 Response, the report could be responded to the router immediately, 559 and it is much easier to implement robust enhancement for passive 560 Report and for a Query, as shown in section 5.2.3 and 5.2.5. 562 5.2.3 Robustness Considerations for Passive Report 564 If in some cases a host's response report is lost due to bad 565 transmission condition, there is still some remedy that can tackle 566 this issue. 568 For example, a router after sending a Query collects successfully 569 all the members' report responses except for other one or two which 570 are kept in its database. This may be because the non-response ones 571 silently leave the network without any notification, or because 572 their reports are lost for unreliable transmission. The router in 573 this case could unicast respectively to each non-respondent receiver 574 to check whether they are still alive for the multicast service 575 reception. Unicast Query is different from normal group queries for 576 its destination address is set to the unicast address of a receiver 577 [13]. 579 5.2.4 Efficiency Enhancement of Queries 581 [14] discusses several processing for reducing Queries when mobile 582 receiver is on the foreign network, e.g. attenuating the Queries on 583 the home network when the router on the remote network process the 584 receiver's report, and the stopping or resuming of Queries under 585 specific conditions. Irrespective of the mobile receivers' position, 586 there are still some optimizations that might be usable for 587 minimization the packet transmission. 589 First, if explicit tracking is used, the router is able to keep all 590 active members state for reception. The Group Specific and Source- 591 and-Group Specific Queries, which are sent to query other members 592 when a member leaves a group or a source-specific group, are 593 unnecessary because the router knows who are active on the link 594 through explicit tracking. Thus it is suggested that when explicit 595 tracking is used, only periodical query is sent. 597 Further, to reduce the packet burst on link with large number of 598 receivers, the router can limited its scope of its periodical 599 Queries. For example, if the receiver number is small, the 600 periodical General Queries for all multicast receivers is enough. 601 If the multicast receiver on a link is large, the router could 602 periodically send Group Queries to a group or send Source-Group 603 Specific Queries to a source-group. In this case the router tunes 604 its behavior by sending these two Queries periodically instead of 605 triggering them when a member leaves. 607 5.2.5 Robustness Enhancement of Queries 609 If the Query is tuned for wireless network by sending only once, as 610 shown in section 5.2.2, the reliability of the query behavior is 611 weaker than wired IGMPv3/MLDv2. In fact, this situation could also 612 be improved by tuning a router's behavior. A router which keeps 613 track of all its active receivers, if after sending a Query, fails 614 to get any response from any receiver, it can derive that its just- 615 sent Query might have been lost before reaching other end of the 616 link. The router could choose to compensate this situation by 617 sending another Query to query its members. 619 6. Security Considerations 621 Apart from the security issue of IGMP/MLD, additional requirements 622 should be considered for the features of the wireless link. They 623 will be described in the later version of this draft. 625 7. References 627 7.1. Normative References 629 [1] Bradner, S., "Key words for use in RFCs to indicate requirement 630 levels", RFC 2119, March 1997. 632 [2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 633 Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 634 3376, October 2002. 636 [3] Vida, R. and L. Costa, "Multicast Listener Discovery Version 637 2(MLDv2) for IPv6", RFC 3810, June 2004. 639 [4] Liu, H., Cao, W., and H. Asaeda, "Lightweight IGMPv3 and MLDv2 640 Protocols", RFC5790, September 2008. 642 [5] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, 643 August 1989. 645 [6] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 646 2236, November 1997. 648 [7] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener 649 Discovery (MLD) for IPv6", RFC 2710, October 1999. 651 [8] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", 653 RFC 4607, August 2006. 655 7.2. Informative Referencess 657 [9] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 658 IPv6", RFC 3775, June 2004. 660 [10] Gundavelli, Ed., S., Leung, K., Devarapalli, V., Chowdhury, K., 661 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 663 [11] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 664 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 665 2005. 667 [12] Romdhani, I., Kellil, M., and H. Lach, "IP Mobile Multicast: 668 Challenges and Solutions", IEEE Comm. Surveys 6(1), 2004. 670 [13] H. Asaeda, "IGMP and MLD Optimization for Mobile Hosts and 671 Routers", draft-asaeda-multimob-igmp-mld-optimization-01,work in 672 progress,2010. 674 [14] I. Romdhani, J. Munoz, H. Bettahar, and A. Bouabdallah, 675 "Adaptive Multicast Membership Management for Mobile Multicast 676 Receivers", IEEE, 2006. 678 Authors' Addresses 680 Hui Liu 681 Huawei Technologies Co., Ltd. 682 Huawei Bld., No.3 Xinxi Rd. 683 Shang-Di Information Industry Base 684 Hai-Dian Distinct, Beijing 100085 685 China 687 EMail: Liuhui47967@huawei.com 689 Qin Wu 690 Huawei Technologies Co., Ltd. 691 Site B, Floor 12, Huihong Mansion, No.91 Baixia Rd. 692 Nanjing, Jiangsu 21001 693 China 695 Phone: +86-25-84565892 697 EMail: sunseawq@huawei.com 699 Hitoshi Asaeda 700 Keio University 701 Graduate School of Media and Governance 702 5322 Endo 703 Fujisawa, Kanagawa 252-8520 704 Japan 706 EMail: asaeda@wide.ad.jp 707 URI: http://www.sfc.wide.ad.jp/~asaeda/ 709 T.M. Eubanks 710 Iformata Communications 711 130 W. Second Street 712 Dayton, Ohio 45402 713 USA 715 Phone: +1 703 501 4376 716 EMail: marshall.eubanks@iformata.com 717 URI: http://www.iformata.com/