idnits 2.17.00 (12 Aug 2021) /tmp/idnits51160/draft-liu-multimob-igmp-mld-wireless-mobile-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance 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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 22, 2013) is 3374 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Multimob Working Group H. Liu 3 Internet-Draft 4 Intended status: Informational M. McBride 5 Expires: August 26, 2013 Huawei Technologies 6 H. Asaeda 7 NICT 8 February 22, 2013 10 IGMP/MLD Optimizations in Wireless and Mobile Networks 11 draft-liu-multimob-igmp-mld-wireless-mobile-03 13 Abstract 15 This document proposes a variety of optimization approaches for IGMP 16 and MLD in wireless and mobile networks. It aims to provide useful 17 guidelines to allow efficient multicast communication in these 18 networks using IGMP or MLD protocols. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in [RFC2119]. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 26, 2013. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.1. Characteristics of Wireless and Mobile Multicast . . . . . 3 63 2.2. Wireless Link Model . . . . . . . . . . . . . . . . . . . 4 64 2.3. Requirements on IGMP and MLD . . . . . . . . . . . . . . . 5 65 3. IGMP/MLD Optimization for Wireless and Mobile Networks . . . . 6 66 3.1. Switching Between Unicast and Multicast Queries . . . . . 6 67 3.2. General Query Supplemented with Unicast Query . . . . . . 6 68 3.3. Retransmission of Queries . . . . . . . . . . . . . . . . 7 69 3.4. General Query Suppression . . . . . . . . . . . . . . . . 7 70 3.5. Tuning Response Delay According to Link Type and Status . 8 71 3.6. Triggering Reports and Queries Quickly During Handover . . 9 72 4. Applicability and Interoperability Considerations . . . . . . 9 73 5. IGMP/MLD Suspend and Resume . . . . . . . . . . . . . . . . . 10 74 5.1. IGMP/MLD Suspend Request . . . . . . . . . . . . . . . . . 10 75 5.2. IGMP/MLD Resume Request . . . . . . . . . . . . . . . . . 10 76 5.3. IGMP/MLD Suspend Reception . . . . . . . . . . . . . . . . 10 77 5.4. IGMP/MLD Resume Reception . . . . . . . . . . . . . . . . 11 78 6. Timers, Counters, and Their Default Values . . . . . . . . . . 12 79 6.1. IGMP/MLD Suspend Interval Timer . . . . . . . . . . . . . 12 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 85 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 88 1. Introduction 90 The deployments of various wireless access techniques are being 91 combined with the use of video and other applications which rely upon 92 IP Multicast. Wireless and mobile multicast are attracting 93 increasing interest from content and service providers. Multicast 94 faces challenges with dynamic group membership management being under 95 the constant update of delivery paths introduced by node movement. 96 There is a high probability of loss and congestion due to limited 97 reliability and capacity of wireless links. 99 Multicast networks are generally constructed by the IGMP and MLD 100 group management protocols (respectively for IPv4 and IPv6 networks) 101 to track valid receivers and by multicast routing protocol building 102 multicast delivery paths. This document focuses only on IGMP and 103 MLD, the protocols used by a host to subscribe to a multicast group 104 and the protocols that are most likely to be exposed to wireless 105 links when supporting terminal mobility. As IGMP and MLD were 106 designed for fixed users on a wired link, they do not necessarily 107 work well for different wireless link types and mobile scenarios. 108 IGMP/MLD should be enhanced to be more applicable in these mobile/ 109 wireless environments. 111 This memo proposes a variety of optimizations for IGMP and MLD, in 112 wireless and mobile networks, to improve network performance, with 113 minimum changes on the protocol behavior and without introducing 114 interoperability issues. These solutions can also be applied in 115 wired networks when efficiency or reliability is required. 117 For generality, this memo does not put limitations on the type of 118 wireless techniques running below IGMP or MLD. They could be 119 cellular, WiMAX, WiFi and etc, and are modeled as different abstract 120 link models as described in section 2.2. Even though some of them 121 (such as WiFi) have multicast limitations, it is probable that IGMP/ 122 MLD is enabled on the wireless terminal and multicast is supported 123 across the network. The mobile IP protocol adopted on the core side, 124 upstream from the access router, could be PMIP, MIPv4, or MIPv6. 126 2. Requirements 128 2.1. Characteristics of Wireless and Mobile Multicast 130 Several limitations should be considered when supporting IP multicast 131 in wireless and mobile networks, including: 133 O Limited link bandwidth: wireless links usually have limited 134 bandwidth, and the situation will be made even worse if a high volume 135 of video multicast data has to be carried. Additionally, the 136 bandwidth available in the upstream and downstream directions may be 137 asymmetrical. 139 O High loss rate: wireless links usually have packet loss ranging 140 from 1% to 30% according to different links types and conditions. 141 Also when packets have to travel between home and access networks 142 (e.g. through a tunnel), they are prone to loss if the two networks 143 are distant from each other. 145 O Frequent membership change: in fixed multicast, membership change 146 only happens when a user leaves or joins a group, while in mobile 147 scenario membership may also change when a user changes its location. 149 O Prone to performance degradation: the possible increased 150 interaction of protocols across layers for mobility management, and 151 the limitation of link capacity, may lead to network performance 152 degradation and even to complete connection loss. 154 O Increased Leave Latency: the leave latency in mobile multicast 155 might be increased due to user movement, especially if the traffic 156 has to be transmitted between access and home networks, or if there 157 is a handshake between networks. 159 2.2. Wireless Link Model 161 Wireless links can typically be categorized into three models: point- 162 to-point (PTP), point-to- multipoint (PTMP), and broadcast link 163 models. 165 In the PTP model, one link is dedicated for two communication 166 facilities. For multicast transmission, each PTP link normally has 167 only one receiver and the bandwidth is dedicated for that receiver. 168 Such link model may be implemented by running PPP on the link or 169 having separate VLAN assignment for each receiver. In a mobile 170 network, a tunnel between entities of home and foreign networks 171 should be recognized as a PTP link. 173 PTMP is the model for multipoint transmission wherein there is one 174 centralized transmitter and multiple distributed receivers. PTMP 175 provides common downlink channels for all receivers and dedicated 176 uplink channel for each receiver. Bandwidth downstream is shared by 177 all receivers on the same link. 179 Broadcast links can connect two or more nodes and support broadcast 180 transmissions. It is quite similar to fixed Ethernet link model and 181 its link resource is shared in both uplink and downlink directions. 183 2.3. Requirements on IGMP and MLD 185 IGMP and MLD are usually run between mobile or wireless terminals and 186 their first-hop access routers (i.e. home or foreign routers) to 187 subscribe to a IP multicast channel. Currently the version in-use 188 includes IGMPv2 [RFC2236] and its IPv6 counterpart MLDv1 [RFC2710], 189 IGMPv3 [RFC3376] and its IPv6 counterpart MLDv2 [RFC3810], and LW- 190 IGMPv3/MLDv2 [RFC5790]. All these versions have basic group 191 management capability required by a multicast subscription. The 192 differences lie in that IGMPv2 and MLDv1 can only join and leave a 193 non-source-specific group, while IGMPv3 and MLDv2 can select 194 including and excluding specific sources for their join and leave 195 operation, and LW-IGMPv3/MLDv2 simplifies IGMPv3/MLDv2 procedures by 196 discarding excluding-source function. Among these versions, (LW-) 197 IGMPv3/MLDv2 has the capability of explicitly tracking each host 198 member. 200 From the illustration given in section 2.1 and 2.2, it is desirable 201 for IGMP and MLD to have the following characteristics when used in 202 wireless and mobile networks: 204 o Adaptive to link conditions: wireless networks have various link 205 types, each with different bandwidth and performance features. IGMP 206 or MLD should be able to be adaptive to different link models and 207 link conditions to optimize its protocol operation. 209 o Minimal group join/leave latency: because mobility and handover may 210 cause a user to join and leave a multicast group frequently, fast 211 join and leave by the user helps to accelerate service activation and 212 to release unnecessary resources quickly to optimize resource 213 utilization. 215 o Robust to packet loss: the unreliable packet transmission due to 216 instable wireless link conditions and limited bandwidth, or long 217 distance transmission in mobile network put more strict robustness 218 requirement on delivery of IGMP and MLD protocol messages. 220 o Reducing packet exchange: wireless link resources are usually more 221 limited, precious, and congested compared to their wired counterpart. 222 This requires packet exchange be minimized without degrading protocol 223 performance. 225 o Packet burst avoidance: large number of packets generated in a 226 short time interval may have the tendency to deteriorate wireless 227 network conditions. IGMP and MLD should be optimized to reduce the 228 probability of packet burst. 230 3. IGMP/MLD Optimization for Wireless and Mobile Networks 232 This section introduces several optimizations for IGMP and MLD in 233 wireless or mobile environment. The aim is to meet the requirements 234 described in section 2.3. It should be noted that because an 235 enhancement in one direction might result in weakening effect in 236 another, balances should be taken cautiously to realize overall 237 performance elevation. 239 3.1. Switching Between Unicast and Multicast Queries 241 IGMP/MLD protocols use multicast Queries whose destinations are 242 multicast addresses and also allows use of unicast Query with unicast 243 destination to be sent only to one host. Unicast Query has the 244 advantage of not affecting other hosts on the same link, and is 245 desirable for wireless communication because a mobile terminal often 246 has limited battery power [RFC6636]. But if the number of valid 247 receivers is large, using unicast Query for each receiver is 248 inefficient because large number of Unicast Queries have to be 249 generated, in which situation normal multicast Query will be a good 250 choice because only one General Query is needed. If the number of 251 receivers to be queried is small, unicast Query is advantageous over 252 the multicast one. 254 More flexibly, the router can choose to switch between unicast and 255 multicast Queries according to the practical network conditions. For 256 example, if the receiver number is small, the router could send 257 unicast Queries respectively to each receiver, without arousing other 258 non-member terminal which is in dormant state. When the receiver 259 number reaches a predefined level, the router could change to use 260 multicast Queries. To have the knowledge of the number of the valid 261 receivers, a router is required to enable explicit tracking, and 262 because Group-Specific Query and Group-and-Source-Specific Query are 263 usually not used under explicit tracking [RFC6636], the switching 264 operation mostly applies to General Queries. 266 3.2. General Query Supplemented with Unicast Query 268 The Unicast Query can be used in assistance to General Query to 269 improve the robustness of solicited reports when General Query fails 270 to collect all of its valid members. It requires the explicit 271 tracking to be enabled and can be used when a router after sending a 272 periodical General Query collects successfully most of the valid 273 members' responses while losing some of which are still valid in its 274 database. This may be because these reports are not generated or 275 generated but lost for some unknown reasons. The router could choose 276 to unicast a Query respectively to each non-respondent valid receiver 277 to check whether they are still alive for the multicast reception, 278 without affecting the majority of receivers that have already 279 responded. Unicast Queries under this condition could be sent at the 280 end of the [Maximum Response Delay] after posting a General Query, 281 and be retransmitted for [Last Member Query Count] times, at an 282 interval of [Last Member Query Interval]. 284 3.3. Retransmission of Queries 286 In IGMP and MLD, apart from the continuously periodical transmission, 287 General Query is also transmitted during a router's startup. It is 288 transmitted for [Startup Query Count] times by [Startup Query 289 Interval]. There are some other cases where retransmission of 290 General Query is beneficial which are not covered by current IGMP and 291 MLD protocols as shown as following. 293 For example, a router which keeps track of all its active receivers, 294 if after sending a General Query, fails to get any response from the 295 receivers which are still valid in its membership database. This may 296 be because all the responses of the receivers happen to be lost, or 297 the sent Query does not arrive at the other side of the link to the 298 receivers. The router could compensate this situation by 299 retransmitting the General Query to solicit its active members. The 300 retransmission can also be applied to Group-Specific or Group-and- 301 Source-Specific Query on a router without explicit tracking 302 capability, when these Specific Queries cannot collect valid 303 response, to prevent missing valid members caused by lost Queries and 304 Reports. 306 The above compensating Queries could be sent [Last Member Query 307 Count] times, at the interval of [Last Member Query Interval], if the 308 router cannot get any feedback from the receivers. 310 3.4. General Query Suppression 312 In IGMP and MLD, the General Query is sent periodically and 313 continuously without any limitation. It helps soliciting the state 314 of current valid member but has to be processed by all hosts on the 315 link, whether they are valid multicast receivers or not. When there 316 is no receiver, the transmission of the General Query is a waste of 317 resources for both the host and the router. 319 An IGMP/MLD router could suppress its transmission of General Query 320 if it knows there is no valid multicast receiver on an interface, 321 e.g. in the following cases: 323 O When the last member reports its leave for a group. This could be 324 judged by an explicit tracking router checking its membership 325 database, or by a non-explicit-tracking router getting no response 326 after sending Group-Specific or Group-and-Source-Specific Query. 328 O When the only member on a PTP link reports its leaving 330 O When a router after retransmitting General Queries on startup fails 331 to get any response 333 O When a router previously has valid members but fails to get any 334 response after several rounds of General Queries. 336 In these cases the router could make the decision that no member is 337 on the interface and totally stop its transmission of periodical 338 General Queries. If afterwards any valid member joins a group, the 339 router could resume the original cycle of general Querying. Because 340 General Query influences all hosts on a link, suppressing it when it 341 is not needed is beneficial for both the link efficiency and terminal 342 power saving. 344 3.5. Tuning Response Delay According to Link Type and Status 346 IGMP and MLD use delayed response to spread unsolicited Reports from 347 different hosts to reduce possibility of packet burst. This is 348 implemented by a host responding to a Query in a specific time 349 randomly chosen between 0 and [Maximum Response Delay], the latter of 350 which is determined by the router and is carried in Query messages to 351 inform the hosts for calculation of the response delay. A larger 352 value will lessen the burst better but will increase leave latency 353 (the time taken to cease the traffic flowing after the last member 354 requests the escaping of a channel). 356 In order to avoid message burst and reduce leave latency, the 357 Response Delay may be dynamically calculated based on the expected 358 number of responders, and link type and status, as shown in the 359 following: 361 O If the expected number of reporters is large and link condition is 362 bad, longer Maximum Response Delay is recommended; if the expected 363 number of reporters is small and the link condition is good, smaller 364 Maximum response Delay should be set. 366 o If the link type is PTP, the Maximum Response Delay can be chosen 367 smaller, whereas if the link is PTMP or broadcast medium, the Maximum 368 Response Delay can be configured larger. 370 The Maximum Response Delay could be configured by the administrator 371 as mentioned above, or be calculated automatically by a software tool 372 implemented according to experiential model for different link modes. 373 The measures to determine the instant value of Maximum Response Delay 374 are out of this document's scope. 376 3.6. Triggering Reports and Queries Quickly During Handover 378 When a mobile terminal is moving from one network to another, if it 379 is receiving multicast content, its new access network should try to 380 deliver the content to the receiver without disruption or performance 381 deterioration. In order to implement smooth handover between 382 networks, the terminal's membership should be acquired as quickly as 383 possible by the new access network. 385 An access router could trigger a Query to a terminal as soon as it 386 detects the terminal's attaching on its link. This could be a 387 General Query if the number of the entering terminals is not small 388 (e.g when they are simultaneously in a moving train). Or this Query 389 could also be a unicast Query for this incoming terminal to prevent 390 unnecessary action of other terminals in the switching area. 392 For the terminal, it could send a report immediately if it is 393 currently in the multicast reception state, when it begins to connect 394 the new network. This helps establishing more quickly the membership 395 state and enable faster multicast stream injection, because with the 396 active report the router does not need to wait for the query period 397 to acquire the terminal's newest state. 399 4. Applicability and Interoperability Considerations 401 Among the optimizations listed above, 'Switching between unicast and 402 multicast Queries'(3.1) and 'General Query Supplemented with Unicast 403 Query'(3.2) requires a router to know beforehand the valid members 404 connected through an interface, thus require explicit tracking 405 capability. An IGMP/MLD implementation could choose any combination 406 of the methods listed from 3.1 to 3.6 to optimize multicast 407 communication on a specific wireless or mobile network. 409 For example, an explicit-tracking IGMPv3 router, can switch to 410 unicast General Queries if the number of members on a link is small 411 (3.1), can trigger unicast Query to a previously valid receiver if 412 failing to get expected responses from it (3.2), can retransmit a 413 General Query if after the previous one cannot collect reports from 414 all valid members (3.3), and can stop sending a General Query when 415 the last member leaves the group (3.4), and etc. 417 For interoperability, it is required if multiple multicast routers 418 are connected to the same network for redundancy, each router are 419 configured with the same optimization policy to synchronize the 420 membership states among the routers. 422 5. IGMP/MLD Suspend and Resume 424 5.1. IGMP/MLD Suspend Request 426 IGMP/MLD Suspend is an operation triggered by a host that subscribes 427 multicast channels or an IGMP/MLD proxy [refs.Proxy] to which hosts 428 subscribing multicast channels attached. An IGMP/MLD Suspend message 429 requests an adjacent upstream router to suspend forwarding subscribed 430 data, while to keep the subscription state (i.e., not to prune the 431 routing path). It is useful especially in a mobile network. When a 432 mobile host moves from a current network (i.e., a mobile host's point 433 of attachment) to a different network, an IGMP/MLD Suspend message is 434 sent by the host itself (or an IGMP/MLD proxy to which mobile hosts 435 attached). 437 When an IGMP/MLD proxy receives IGMP/MLD Suspend messages on its 438 downstream interface, it forwards the Suspend message to its upstream 439 router via its upstream interface if needed (see Section 5.3. 441 5.2. IGMP/MLD Resume Request 443 When a host that has subscribed multicast channels and sent IGMP/MLD 444 Suspend messages attaches to a new network, it immediately sends 445 IGMP/MLD Resume messages to request its upstream router to resume 446 forwarding the data. The Resume Records specified in the IGMP/MLD 447 Resume message will be the same as that of the Suspend Records the 448 host sent. 450 5.3. IGMP/MLD Suspend Reception 452 When a multicast router receives an IGMP/MLD Suspend message from the 453 downstream member hosts or IGMP/MLD proxy, it examines whether the 454 message sender is the sole member of the reported channels at the 455 downstream link or not. There are two ways to know it. One is done 456 by the Group-Specific or Group-and-Source Specific Queries. The 457 other is done by the explicit tracking function [refs.explicit]. 459 The router sends the Group-Specific or Group-and-Source Specific 460 Queries for all records in the Suspend messages. If the router 461 receives IGMP/MLD reports including some or all of the Suspend 462 Records, it eliminates the reported records from the Suspend Records 463 and keeps forwarding these data. If the router does not receive 464 IGMP/MLD reports for some or all of the Suspend Records, it 465 recognizes that the Suspend message sender is the sole member host 466 for these channels on the link. After the router organizes the new 467 Suspend Records (that eliminate reported records from the original 468 one), it suspends data forwarding for them. 470 The explicit tracking function gives advantage of organizing the new 471 Suspended Records. If a router enables the explicit tracking 472 function, it can recognize whether the message sender host is the 473 sole member without sending the Group-Specific or Group-and-Source 474 Specific Queries. Then the router suspends data forwarding based on 475 the up-to-date Suspend Records. 477 The multicast router maintains Suspend Records until it receives the 478 corresponding IGMP/MLD Resume message (described in the next section) 479 or the IGMP/MLD Suspend Interval timer (described in Section 6.1) is 480 expired. When either the Resume message reception or the timer 481 expiration occurs, the router resume data forwarding for the Suspend 482 Records and discards the Suspend Records. 484 If a multicast router receives an IGMP/MLD Suspend message, which 485 includes Multicast Address Records already suspended, the router 486 restarts the IGMP/MLD Suspend Interval timer for the corresponding 487 Multicast Address Records. 489 When an IGMP/MLD proxy receives an IGMP/MLD Suspend message from a 490 downstream host, it behaves as a multicast router as described above, 491 because the proxy device performs the router portion of the IGMP or 492 MLD protocol on its downstream interfaces. 494 When a mobile node that has sent the IGMP/MLD Suspend message 495 receives the corresponding Group-Specific or Group-and-Source 496 Specific Queries for the Suspend Records, it replies the standard 497 IGMP/MLD Report messages as defined in [refs.IGMPv3][refs.MLDv2]. 499 5.4. IGMP/MLD Resume Reception 501 When a multicast router receives an IGMP/MLD Resume message, the 502 router examines the message sender and an IGMP/MLD Suspend Interval 503 timer. If the router has the Suspend Records given from the Resume 504 message sender, it compares the Suspend Records with the notified 505 Multicast Address Records specified in the Resume message. For the 506 matched Multicast Address Records, the router then removes the 507 entries from the Suspend Records and resumes data forwarding with 508 restarting the group or source timers. For the mismatched Multicast 509 Address Records, the router keeps unchanged (then will be removed by 510 timeout) or explicitly starts the leave (or prune) procedures for the 511 channels, while it depends on the implementation. 513 If either the router does not have the corresponding Suspend Records 514 or the IGMP/MLD Suspend Interval timer has expired, then the router 515 does not take any action. 517 If a router that did not recognize an IGMP/MLD Suspend message (e.g., 518 due to packet loss or some troubles in its transmission) receives an 519 IGMP/MLD Resume message, it will accept the message as a regular 520 Current-State Report IGMP/MLD message. 522 6. Timers, Counters, and Their Default Values 524 6.1. IGMP/MLD Suspend Interval Timer 526 After a multicast router receiving an IGMP/MLD Suspend message will 527 identify the corresponding multicast sessions/channels, it suspends 528 data forwarding and keeps the Suspend Records until the given amount 529 of timer value is expired. This timer is named the "IGMP/MLD Suspend 530 Interval timer", which is a configurable value. 532 The Suspend Interval is used to allow a multicast router to resume 533 the multicast session. Therefore, if the multicast router does not 534 receive the corresponding IGMP/MLD Resume message for the IGMP/MLD 535 Resume operation within the Suspend Interval, it leaves the sessions/ 536 channels recorded in the Suspend Records and discards the Suspend 537 Records. Note that the router does not send any IGMP/MLD Query 538 message for the timeout sessions/channels and immediately leaves from 539 them. 541 7. IANA Considerations 543 This document makes no request of IANA. 545 Note to RFC Editor: this section may be removed on publication as an 546 RFC. 548 8. Security Considerations 550 Since the methods only involve the tuning of protocol behavior by 551 e.g. retransmission, changing delay parameter, or other compensating 552 operations, they do not introduce additional security weaknesses. 553 The security consderations described in [RFC2236], [RFC3376], 554 [RFC2710] and [RFC3810] can be reused. And to achieve some security 555 level in insecure wireless network, it is possible to take stronger 556 security procedures during IGMP/MLD message exchange, which are out 557 of the scope of this memo. 559 9. Acknowledgements 561 The authors would like to thank Behcet Sarikaya, Qin Wu, Stig Venaas, 562 Gorry Fairhurst, Thomas C. Schmidt, Marshall Eubanks, Suresh 563 Krishnan, J.William Atwood, WeeSan Lee, Imed Romdhani, Liu Yisong and 564 Wei Yong for their valuable comments and suggestions on this 565 document. 567 10. References 569 10.1. Normative References 571 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 572 Requirement Levels", BCP 14, RFC 2119, March 1997. 574 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 575 2", RFC 2236, November 1997. 577 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 578 Listener Discovery (MLD) for IPv6", RFC 2710, 579 October 1999. 581 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 582 Thyagarajan, "Internet Group Management Protocol, Version 583 3", RFC 3376, October 2002. 585 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 586 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 588 [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet 589 Group Management Protocol Version 3 (IGMPv3) and Multicast 590 Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, 591 February 2010. 593 [RFC6636] Asaeda, H., Liu, H., and Q. Wu, "Tuning the Behavior of 594 the Internet Group Management Protocol (IGMP) and 595 Multicast Listener Discovery (MLD) for Routers in Mobile 596 and Wireless Networks", RFC 6636, May 2012. 598 [refs.IGMPv1] 599 Deering, S., "Host Extensions for IP Multicasting", 600 RFC 1112, August 1989. 602 [refs.IGMPv2] 603 Fenner, W., "Internet Group Management Protocol, Version 604 2", RFC 2373, July 1997. 606 [refs.IGMPv3] 607 Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 608 Thyagarajan, "Internet Group Management Protocol, Version 609 3", RFC 3376, October 2002. 611 [refs.KEYWORDS] 612 Bradner, S., "Key words for use in RFCs to indicate 613 requirement levels", RFC 2119, March 1997. 615 [refs.LW] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet 616 Group Management Protocol Version 3 (IGMPv3) and Multicast 617 Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, 618 February 2010. 620 [refs.MLDv1] 621 Deering, S., Fenner, W., and B. Haberman, "Multicast 622 Listener Discovery (MLD) for IPv6", RFC 2710, 623 October 1999. 625 [refs.MLDv2] 626 Vida, R. and L. Costa, "Multicast Listener Discovery 627 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 629 [refs.PIM] 630 Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 631 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 632 Protocol Specification (Revised)", RFC 4601, August 2006. 634 [refs.Proxy] 635 Fenner, B., He, H., Haberman, B., and H. Sandick, 636 "Internet Group Management Protocol (IGMP) / Multicast 637 Listener Discovery (MLD)-Based Multicast Forwarding 638 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 640 10.2. Informative References 642 [refs.MIPv6] 643 Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 644 in IPv6", RFC 3775, June 2004. 646 [refs.Noel] 647 Jelger, C. and T. Noel, "Multicast for Mobile Hosts in IP 648 Networks: Progress and Challenges", IEEE Wireless 649 Comm. pp.58-64, October 2002. 651 [refs.PMIPv6] 652 Gundavelli, S, Ed., Leung, K., Devarapalli, V., Chowdhury, 653 K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, 654 August 2008. 656 [refs.explicit] 657 Asaeda, H., "IGMP/MLD-Based Explicit Membership Tracking 658 Function for Multicast Routers", 659 draft-ietf-pim-explicit-tracking-04.txt (work in 660 progress), January 2013. 662 Authors' Addresses 664 Hui Liu 666 Email: liu_helen@126.com 668 Mike McBride 669 Huawei Technologies 670 2330 Central Expressway 671 Santa Clara CA 95050 672 USA 674 Email: michael.mcbride@huawei.com 676 Hitoshi Asaeda 677 National Institute of Information and Communications Technology (NICT) 678 Network Architecture Laboratory 679 4-2-1 Nukui-Kitamachi 680 Koganei, Tokyo 184-8795 681 Japan 683 Email: asaeda@nict.go.jp