idnits 2.17.00 (12 Aug 2021) /tmp/idnits32112/draft-liu-multimob-reliable-igmp-mld-00.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, 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 (March 1, 2010) is 4457 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '1' is mentioned on line 471, but not defined == Missing Reference: '2' is mentioned on line 474, but not defined == Missing Reference: '3' is mentioned on line 477, but not defined == Missing Reference: '4' is mentioned on line 480, but not defined == Missing Reference: '5' is mentioned on line 483, but not defined -- Looks like a reference, but probably isn't: 'M' on line 351 == Missing Reference: '6' is mentioned on line 486, but not defined == Missing Reference: '7' is mentioned on line 490, but not defined == Outdated reference: A later version (-03) exists of draft-liu-multimob-igmp-mld-mobility-req-02 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Multimob Group H. Liu 2 Internet Draft Q. Wu 3 Category: Standard Track Huawei Technologies 4 Expires: September 2010 March 1, 2010 6 Reliable IGMP and MLD Protocols in Wireless Environment 8 draft-liu-multimob-reliable-igmp-mld-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with 13 the provisions of BCP 78 and BCP 79. 15 This document may contain material from IETF Documents or IETF 16 Contributions published or made publicly available before November 17 10, 2008. The person(s) controlling the copyright in some of this 18 material may not have granted the IETF Trust the right to allow 19 modifications of such material outside the IETF Standards Process. 20 Without obtaining an adequate license from the person(s) controlling 21 the copyright in such materials, this document may not be modified 22 outside the IETF Standards Process, and derivative works of it may 23 not be created outside the IETF Standards Process, except to format 24 it for publication as an RFC or to translate it into languages other 25 than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other documents 34 at any time. It is inappropriate to use Internet-Drafts as 35 reference material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 This Internet-Draft will expire on September 1, 2010. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with 55 respect to this document. 57 Abstract 59 This memo specifies the reliability enhancement of IGMP and MLD 60 group management protocol, which is intended to be used in wireless 61 and/or mobile network environment. The reliability is simply 62 achieved by providing acknowledgment to IGMP/MLD join messages. 64 Table of Contents 66 1. Introduction.................................................2 67 2. General Discussions..........................................3 68 3. Protocol Behavior Description................................4 69 3.1. Group Member Operations.................................5 70 3.2. Multicast Router Operations.............................6 71 4. Message Format...............................................6 72 5. Interoperability Considerations.............................11 73 6. New Parameters Defined......................................12 74 7. Security Considerations.....................................13 75 8. References..................................................13 76 8.1. Normal References......................................13 77 8.2. Informative References.................................14 78 Authors' Addresses.............................................14 80 1. Introduction 82 IGMP (Internet Group Management Protocol) was originally designed 83 according to wired shared-medium Ethernet network model. It has 84 several versions (IGMPv1/v2/v3 [1][2][3], MLDv1/v2[4][5]) which are 85 evolved with new features added to meet the increased requirements 86 but they all keep on the original shared Ethernet model. 88 With the emerging of wireless network and techniques, mobile or 89 wireless IP multicast sees their potentiality to be deployed to 90 enable efficient delivery of mobile video service. Because the 91 networking conditions in these scenarios are different from that of 92 fixed Ethernet, e.g. with possibly higher packet loss rate, current 93 versions of IGMP and MLD are somewhat inadequate and there is the 94 demand that IGMP/MLD protocol should be enhanced to meet the 95 reliability requirements in these scenarios [8][9]. 97 This memo introduces the reliability enhancement of group management 98 protocol on wireless or mobile IP networks. The reliability is 99 enhanced by providing acknowledgement for group join request 100 messages. The document is arranged as follows: section 2 discusses 101 the general issues including the requirements and basic mechanism. 102 Section 3 describes the protocol behavior on both the host and the 103 router part. Section 4 defines the message format and Section 5 104 discusses interoperability issue with the earlier deployed versions. 105 Section 6 defines the timer and counter parameters. The state- 106 machine of the new protocol will be included in the later version of 107 draft. 109 2. General Discussions 111 Wireless network has the characteristics that its packet delivery is 112 sometimes unreliable (e.g. with much higher packet loss rate) due to 113 its unstable media transmission conditions. And in some mobile IP 114 multicast designs, the IGMP/MLD messages have to be sent from 115 foreign network to home network. In these two cases, IGMP and MLD 116 reports are prone to loss due to network conditions degradation or 117 long distance travel. 119 IGMP and MLD (except for IGMPv1) define a retransmission parameter 120 [Robustness Variable] which determines the transmission times the 121 report was sent. It improves the reliability to some degree but is 122 inadequate for several reasons. First, because the value for the 123 variable is constant, if the network is in good condition, the 124 packet retransmission is a waste of resources. Secondly, on lossy 125 network, even multiple packets are sent, all of them may be lost, 126 thus robustness can not be guaranteed. Finally, if the link 127 condition changes from time to time, or if the host moves from one 128 network or link to another, it is difficult to arrange a reasonable 129 value for the parameter. 131 This memo suggests adopting acknowledgement-retransmission mechanism, 132 which is commonly deployed in today's protocol design, to enhance 133 the reliable delivery of IGMP/MLD join report. Its basic protocol 134 behavior is direct and simple. IGMP or MLD host after sending a 135 join report, starts a retransmission timer and waits for the 136 acknowledgement (ACK) message from the router. If the ACK is not 137 received when the timer expires, another report is retransmitted. 138 The protocol should also use a parameter [RETRANS_COUNT]), to limit 139 the maximum retransmission times when make the joining. 141 The acknowledgment mechanism was proposed in an earlier work [8] 142 which suggests providing feedback for the group join messages 143 instead of periodical Queries on point-to-point network. Draft [10] 144 discusses another feedback method when group join can not be 145 processed normally by the router. It can be seen that 146 acknowledgment to join is not a rare thought related to group 147 management protocol. Retransmission enhanced with acknowledgment is 148 more efficient because if a report is successfully acknowledged, its 149 retransmission is not needed. 151 3. Protocol Behavior Description 153 The reliable group management protocol does not change the general 154 protocol behavior prescribed in previous IGMP and MLD. The 155 difference lies in the use of ACK message, which are sent in 156 response to the join report that require acknowledgement. 158 There are two kinds of report generated by an IGMP/MLD host - 159 unsolicited reports when host initially join a group to request 160 reception of the multicast data, and passive report in response to 161 router's Queries to refresh the state database of the host on the 162 router. Because unsolicited reports have direct effects on user' 163 experience, their reliability requirements are stronger than those 164 of the passive ones. It is suggested that only unsolicited report 165 is acknowledged by the router, while the passive report is not 166 acknowledged because in IGMP/MLD they are generated continuously, 167 the acknowledgement on them will produce too many extra packets on 168 the network. 170 For some mobile IP multicast networks, IGMP/MLD reports, which may 171 be generated by a host or a router, have to travel from foreign 172 network to home network. These reports can be acknowledged by the 173 router on the home network to improve reliability. 175 To differentiate whether an IGMP/MLD report should be acknowledged 176 or not, an ACK flag can be set in the report message. The router on 177 receiving a report message decides whether to feedback an ACK 178 message or not according to this flag, which can be set in the 179 reserved field of an IGMP/MLD message. In this memo the extension 180 is made based on IGMPv2 and MLDv2 messages. 182 For unacknowledged reports, the process of the host and router on 183 them are the same as the fixed IGMP/MLD protocols. That is, the 184 host sends the report without the ACK flag, for [Robustness Variable] 185 times. The router will not generate ACK message in reception of 186 this report. 188 The definition of the timers and counters aforementioned will be 189 described later in this memo. Their names will appear in square 190 brackets. 192 3.1. Group Member Operations 194 Host actively sends IGMP or MLD Report to the attached router when 195 it wants to join a multicast group or a source-group channel, which 196 will be confirmed by the router by an IGMP or MLD Acknowledgment 197 (ACK) message. If after an [RETRANS_INTERVAL] interval the ACK is 198 not received, the host should resend the report and wait another ACK. 199 Host stops its retransmission attempt as the retransmission number 200 reach the [RETRANS_COUNT]. 202 There is the possibility that the ACK message for a report is sent 203 by a router but lost. Because in this case the router will forward 204 the multicast traffic after the acknowledgment, the multicast data 205 received by the host can be used to make the acknowledgement by the 206 host. Thus if a host receives the multicast data it asks for, it 207 will stop retransmitting report even though ACK message is not 208 received. 210 The host also sends reports on receiving the Queries from the router. 211 In this case, it does not wait for the acknowledgement of the router 212 and the host's behavior is the same as those defined in its fixed 213 IGMP/MLD versions. 215 When IGMP/MLD reports have to travel from one part of the network to 216 another, they can also be acknowledged because they have more 217 possibilities of being lost. These reports could be produced by 218 either a host or router, depending on the arrangement of a mobile 219 network. The acknowledgement and retransmission method for the 220 report is the same as that of unsolicited report. 222 3.2. Multicast Router Operations 224 The router according to the ACK flag decides whether to provide 225 acknowledgment to the received report. The destination address of 226 ACK packet is set to the unicast address of the host to be 227 acknowledged. The router after acknowledging the unsolicited report 228 will create the state for this receiver and start to send the 229 multicast data toward the receiver. 231 In some situations the router has already created states for the 232 report sender (which may be an attached host or a remote 233 host/router). When the router still receive the sender's report 234 requesting ACK, it will still provide acknowledgement to the sender. 236 Other protocol behavior on the router should be same as the those 237 described in fixed network IGMPv3 and MLDv2 versions [3][5]. 239 4. Message Format 241 For convenience of illustration, we refer to the IGMP/MLD defined in 242 this version as Wireless IGMP/WMLD (WIGMP/WMLD) protocols, whose 243 suggested message formats are constructed based on IGMPv3/MLDv2 244 messages. The differences between the message sets of WIGMP/WMLD 245 and IGMPv3/MLDv2 are that WIGMP/WMLD report uses an additional flag 246 to indicate whether the message is to be acknowledged or not, and an 247 ACK message is introduced, as shown in figure 1 to 6. The formats 248 of Queries are the same as those of IGMPv3 and MLDv2 messages, which 249 are not illustrated here. For WIGMP the length of multicast group 250 address and source address should be 32 bits and for WMLD their 251 length should be 128 bits. 253 For the quick processing by the router, this memo recommends an 254 unsolicited WIGMP/WMLD report not to be merged with other reports 255 when generated on an interface, thus only *one* Group Record is 256 present in its message. A new 'flag' field is introduced in the 257 header to denote ACK flag, as respectively shown in Figure 1, and 2. 259 0 1 2 3 260 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Type = 0x22 | Reserved |A| Checksum | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Reserved | Number of Group Records (M)= 1| 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | | 267 . . 268 . Group Record . 269 . . 270 | | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 Figure 1. WIGMP active Report message format with ACK flag 274 set (A=1), sent when the host joins a group 276 0 1 2 3 277 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Type = 0x22 | Reserved |A| Checksum | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Reserved | Number of Group Records (M) | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | | 284 . . 285 . Group Record [1] . 286 . . 287 | | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | | 290 . . 291 . Group Record [2] . 292 . . 293 | | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | . | 296 . . . 297 | . | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | | 300 . . 301 . Group Record [M] . 302 . . 303 | | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 Figure 2. WIGMP passive Report message format without ACK flag set 307 (A=0), sent in response to a Query 309 0 1 2 3 310 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Type = 0x8F | Reserved |A| Checksum | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Reserved |Nr of Mcast Addr. Records(M)= 1| 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | | 317 . . 318 . Multicast Address Record . 319 . . 320 | | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Figure 3. WMLD active Report message format with ACK flag set (A=1), 324 sent when host joins a group 326 0 1 2 3 327 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Type = 0x8F | Reserved |A| Checksum | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Reserved |Nr of Mcast Address Records (M)| 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | | 334 . . 335 . Multicast Address Record [1] . 336 . . 337 | | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | | 340 . . 341 . Multicast Address Record [2] . 342 . . 343 | | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | . | 346 . . . 347 | . | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | | 350 . . 351 . Multicast Address Record [M] . 352 . . 353 | | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 Figure 4. WMLD passive Report message format without ACK flag set 357 (A=0), sent in response to a Query 359 The format of the Group Records and Multicast Address Record in 360 figure 1, 2, 3 and 4 are defined in [3] and [5]. 362 The ACK message for WIGMP and WMLD are newly introduced. It is 363 unicast sent from a multicast router to a host. There are two 364 options to define ACK messages: one is to reuse current Report 365 message format with a flag for identification for ACK message, the 366 other is to define a new message type. The former has the advantage 367 that it requires no IANA assignment and is more compatible with 368 original IGMP and MLD protocols. The definition of the two message 369 type are shown in figure 5 and 6 370 0 1 2 3 371 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Type = 0x22 | Reserved |K|0| Checksum | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Reserved | Number of Group Records (M)= 1| 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | | 378 . . 379 . Group Record . 380 . . 381 | | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 Figure 5. WIGMP ACK message format 385 0 1 2 3 386 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Type = 0x8F | Reserved |K|0| Checksum | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Reserved | Number of Group Records (M)= 1| 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | | 393 . . 394 . Multicast Address Record [1] . 395 . . 396 | | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 Figure 6. WMLD ACK message format 400 In the second option, new messages chould be defined (e.g Type = 401 0x33 for WIGMP ACK and Type = 0x99 for WMLD ACK) the other part of 402 the message format are same as figure 1 and figure 2. 404 5. Interoperability Considerations 406 Only interoperability of WIGMP is discussed and that for WMLD is 407 similar thus is omitted for simplicity. 409 If a WIGMP/WMLD host connects to an IGMPv3/MLDv2 router, the router 410 can not process the ACK flag in the report and might do not provide 411 acknowledgement to the report. To enable communication in this 412 scenario, if the router can not process the report and if the host 413 recognizes the version from the Queries, the host should send report 414 without ACK flag and do not wait for the ACK message. The 415 retransmission times could be identified by the [ROBUST_VARIABLE] 416 parameter. The communication should be done without the 417 confirmation of reports, which is the same as IGMPv3/MLD protocols. 419 If a WIGMP/WMLD router faces an IGMPv3/MLDv2 host, the router need 420 not provide feedback on the host's unsolicited report. The WIGMP 421 router must behave as the version used by the host and it must not 422 acknowledge the report sent by the host. 424 The interaction with PIM protocol is that the interface with PIM 425 protocol could be created by the router before or after the ACK- 426 flagged report is acknowledged according to the implementation 427 considerations. 429 For an IGMP/MLD snooping switch, to simplify the processing, the 430 forwarding port is required to be created by snooping the Report 431 message instead of by snooping the ACK message. If the report is 432 acknowledged by the ACK message or the multicast traffic, the switch 433 will normally forward the multicast traffic on this port. Otherwise 434 if the forwarding port was created without the successful 435 acknowledgement of the router, the switch will timeout this port 436 because it could not receive multicast traffic from the router. 437 Thus no special processing is required on the switch when IGMP/MLD 438 is enhanced with ACK mechanism. 440 For IGMP/MLD proxy, the processing is the same as the requirements 441 given by WIGMP/WMLD host and router. The host interface could send 442 a report with or without an ACK flag, and the router interface 443 decide to acknowledge the report message or not according to the ACK 444 flag. 446 6. New Parameters Defined 448 [RETRANS_INTERVAL]: The time interval between repetitions of a 449 host's report of membership in a group when ACK flag is set. For a 450 unsolicited report, this interval could be set to the same value as 451 [Unsolicited Report Interval] defined in IGMPv3 and MLDv2, whose 452 default value is 1 second. 454 [RETRANS_COUNT]: The maximum retransmission number of ACK-flagged 455 report. When the retransmission number reaches this value, the host 456 stops the retransmission efforts even if the ACK message is not 457 received. Default value: 2. 459 Other timer and counter parameter value should be the same as those 460 defined in IGMPv3 and MLDv2. They will not be re-illustrated in 461 this memo. 463 7. Security Considerations 465 Security will be considered in the future version of this memo. 467 8. References 469 8.1. Normal References 471 [1] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 472 1112, August 1989 474 [2] Fenner, W., "Internet Group Management Protocol, Version2", RFC 475 2236, November 1997. 477 [3] B. Cain, "Internet Group Management Protocol, Version 3", RFC 478 3376, October 2002. 480 [4] S. Deering, "Multicast Listener Discovery (MLD) for IPv6", RFC 481 2710, October 1999. 483 [5] R. Vida, "Multicast Listener Discovery Version 2 (MLDv2) for 484 IPv6", RFC 3810, June 2004. 486 [6] M. Christensen, "Considerations for Internet Group Management 487 Protocol (IGMP) and Multicast Listener Discovery (MLD) 488 Snooping Switches", RFC4541, May 2006. 490 [7] Fenner, "Internet Group Management Protocol (IGMP)/Multicast 491 Listener Discovery (MLD)-Based Multicast Forwarding 492 ("IGMP/MLD Proxying")", RFC 4605, August 2006 494 8.2. Informative References 496 [8] A. Sen Mazumder, "Facilitating Robust Multicast Group 497 Management", NOSSDAV'05, June 13-14, 2005, Stevenson, 498 Washington, USA. 500 [9] H. Liu, "Mobile and Wireless Multicast Requirements on IGMP/MLD 501 Protocols", draft-liu-multimob-igmp-mld-mobility-req- 502 02.txt, July 2009. 504 [10] T. Morin, "IGMP/MLD Error Feedback", draft-morin-mboned- 505 igmpmld-error-feedback-02, May 2009. 507 Authors' Addresses 509 Hui Liu 511 Huawei Technologies Co., Ltd. 513 Huawei Bld., No.3 Xinxi Rd. 515 Shang-Di Information Industry Base 517 Hai-Dian Distinct, Beijing 100085 519 China 521 EMail: Liuhui47967@huawei.com 523 Qin Wu 525 Huawei Technologies Co., Ltd. 527 Site B, Floor 12, Huihong Mansion, No.91 Baixia Rd. 529 Nanjing, Jiangsu 21001 531 China 532 Phone: +86-25-84565892 534 EMail: sunseawq@huawei.com