idnits 2.17.1 draft-liu-multimob-igmp-mld-wireless-mobile-02.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 : ---------------------------------------------------------------------------- No issues found here. 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 (July 12, 2012) is 4299 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Multimob Working Group H. Liu 3 Internet-Draft M. McBride 4 Intended status: Informational Huawei Technologies 5 Expires: January 13, 2013 July 12, 2012 7 IGMP/MLD Optimizations in Wireless and Mobile Networks 8 draft-liu-multimob-igmp-mld-wireless-mobile-02 10 Abstract 12 This document proposes a variety of optimization approaches for IGMP 13 and MLD in wireless and mobile networks. It aims to provide useful 14 guideline to allow efficient multicast communication in these 15 networks using IGMP or MLD protocols. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in [RFC2119]. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 13, 2013. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Characteristics of Wireless and Mobile Multicast . . . . . 3 60 2.2. Wireless Link Model . . . . . . . . . . . . . . . . . . . 4 61 2.3. Requirements on IGMP and MLD . . . . . . . . . . . . . . . 5 62 3. IGMP/MLD Optimization for Wireless and Mobile Networks . . . . 6 63 3.1. Switching Between Unicast and Multicast Queries . . . . . 6 64 3.2. General Query Supplemented with Unicast Query . . . . . . 6 65 3.3. Retransmission of Queries . . . . . . . . . . . . . . . . 7 66 3.4. General Query Suppression . . . . . . . . . . . . . . . . 7 67 3.5. Tuning Response Delay According to Link Type and Status . 8 68 3.6. Triggering Reports and Queries Quickly During Handover . . 9 69 4. Applicability and Interoperability Considerations . . . . . . 9 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 73 8. Normative References . . . . . . . . . . . . . . . . . . . . . 10 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 76 1. Introduction 78 With the wide deployment of various wireless access techniques and 79 the tendency to support video applications on wireless networks, 80 wireless and mobile multicast come to attract more and more interests 81 from content and service providers, but still face great challenges 82 when considering dynamic group membership management under constant 83 update of delivery path introduced by node movement, and high 84 probability of loss and congestion due to limited reliability and 85 capacity of wireless links. 87 Multicast network is generally constructed by IGMP and MLD group 88 management protocol (respectively for IPv4 and IPv6 networks) to 89 track valid receivers and by multicast routing protocol to build 90 multicast delivery paths. This document focuses only on IGMP and 91 MLD, which are used by a host to subscribe a multicast group and are 92 most possibly to be exposed to wireless link to support terminal 93 mobility. As IGMP and MLD were designed for fixed users using wired 94 link, they do not necessarily work well for different wireless link 95 types and mobile scenarios, thus should be considered to be enhanced 96 to be more applicable in these environments. 98 This memo proposes a variety of optimizations for IGMP and MLD in 99 wireless and mobile networks to improve network performance, with 100 minimum changes on the protocol behavior and without introducing 101 interoperability issues. These solutions can also be applied in 102 wired network when efficiency or reliability is required. 104 For generality, this memo does not put limitations on the type of 105 wireless techniques running below IGMP or MLD. They could be 106 cellular, WiMAX, WiFi and etc, and are modeled as different abstract 107 link models as described in section 2.2. Even though some of them 108 (such as WiFi) have multicast limitations, it is probable that IGMP/ 109 MLD is enabled on the wireless terminal and multicast is supported 110 across the network. The mobile IP protocol adopted on the core side, 111 upstream from the access router, could be PMIP, MIPv4, or MIPv6. 113 2. Requirements 115 2.1. Characteristics of Wireless and Mobile Multicast 117 Several limitations should be considered when supporting IP multicast 118 in wireless and mobile networks, including: 120 O Limited link bandwidth: wireless link usually has limited 121 bandwidth, and the situation will be made even worse if high volume 122 video multicast data has to be carried. Also the bandwidth available 123 in the upstream and downstream directions may be asymmetrical. 125 O High loss rate: wireless link usually has packet loss ranging from 126 1% to 30% according to different links types and conditions. Also 127 when packets have to travel between home and access networks (e.g. 128 through tunnel), they are prone to loss if the two networks are 129 distant from each other. 131 O Frequent membership change: in fixed multicast, membership change 132 only happens when a user leaves or joins a group, while in mobile 133 scenario membership may also change when a user changes its location. 135 O Prone to performance degradation: the possible increased 136 interaction of protocols across layers for mobility management, and 137 the limitation of link capacity, may lead to network performance 138 degradation and even to complete connection loss. 140 O Increased Leave Latency: the leave latency in mobile multicast 141 might be increased due to user movement, especially if the traffic 142 has to be transmitted between access and home networks, or if there 143 is a handshake between networks. 145 2.2. Wireless Link Model 147 Wireless links can be categorized by their different transmission 148 modes into three typical models: point-to-point (PTP), point-to- 149 multipoint (PTMP), and broadcast link models. 151 In PTP model, one link is dedicated for two communication facilities. 152 For multicast transmission, each PTP link normally has only one 153 receiver and the bandwidth is dedicated for that receiver. Such link 154 model may be implemented by running PPP on the link or having 155 separate VLAN assignment for each receiver. In mobile network, 156 tunnel between entities of home and foreign networks should be 157 recognized as a PTP link. 159 PTMP is the model for multipoint transmission wherein there is one 160 centralized transmitter and multiple distributed receivers. PTMP 161 provides common downlink channels for all receivers and dedicated 162 uplink channel for each receiver. Bandwidth downstream is shared by 163 all receivers on the same link. 165 Broadcast link can connect two or more nodes and supports broadcast 166 transmission. It is quite similar to fixed Ethernet link model and 167 its link resource is shared in both uplink and downlink directions. 169 2.3. Requirements on IGMP and MLD 171 IGMP and MLD are usually run between mobile or wireless terminals and 172 their first-hop access routers (i.e. home or foreign routers) to 173 subscribe an IP multicast channel. Currently the version in-use 174 includes IGMPv2 [RFC2236] and its IPv6 counterpart MLDv1 [RFC2710], 175 IGMPv3 [RFC3376] and its IPv6 counterpart MLDv2 [RFC3810], and LW- 176 IGMPv3/MLDv2 [RFC5790]. All these versions have basic group 177 management capability required by a multicast subscription. The 178 differences lie in that IGMPv2 and MLDv1 can only join and leave a 179 non-source-specific group, while IGMPv3 and MLDv2 can select 180 including and excluding specific sources for their join and leave 181 operation, and LW-IGMPv3/MLDv2 simplifies IGMPv3/MLDv2 procedures by 182 discarding excluding-source function. Among these versions, (LW-) 183 IGMPv3/MLDv2 has the capability of explicitly tracking each host 184 member. 186 From the illustration given in section 2.1 and 2.2, it is desirable 187 for IGMP and MLD to have the following characteristics when used in 188 wireless and mobile networks: 190 o Adaptive to link conditions: wireless network has various link 191 types, each with different bandwidth and performance features. IGMP 192 or MLD should be able to be adaptive to different link model and link 193 conditions to optimize its protocol operation. 195 o Minimal group join/leave latency: because mobility and handover may 196 cause a user to join and leave a multicast group frequently, fast 197 join and leave by the user helps to accelerate service activation and 198 to release unnecessary resources quickly to optimize resource 199 utilization. 201 o Robust to packet loss: the unreliable packet transmission due to 202 instable wireless link conditions and limited bandwidth, or long 203 distance transmission in mobile network put more strict robustness 204 requirement on delivery of IGMP and MLD protocol messages. 206 o Reducing packet exchange: wireless link resources are usually more 207 limited, precious, and congested compared to their wired counterpart. 208 This requires packet exchange be minimized without degrading protocol 209 performance. 211 o Packet burst avoidance: large number of packets generated in a 212 short time interval may have the tendency to deteriorate wireless 213 network conditions. IGMP and MLD should be optimized to reduce the 214 probability of packet burst. 216 3. IGMP/MLD Optimization for Wireless and Mobile Networks 218 This section introduces several optimization methods for IGMP and MLD 219 in wireless or mobile environment. The aim is to meet the 220 requirements described in section 2.3. It should be noted that 221 because an enhancement in one direction might result in weakening 222 effect in another, balances should be taken cautiously to realize 223 overall performance elevation. 225 3.1. Switching Between Unicast and Multicast Queries 227 IGMP/MLD protocol uses multicast Queries whose destinations are 228 multicast addresses and also allows use of unicast Query with unicast 229 destination to be sent only to one host. Unicast Query has the 230 advantage of not affecting other hosts on the same link, and is 231 desirable for wireless communication because a mobile terminal often 232 has limited battery power [RFC6636]. But if the number of valid 233 receivers is large, using unicast Query for each receiver is 234 inefficient because large number of Unicast Queries have to be 235 generated, in which situation normal multicast Query will be a good 236 choice because only one General Query is needed. If the number of 237 receivers to be queried is small, unicast Query is advantageous over 238 the multicast one. 240 More flexibly, the router can choose to switch between unicast and 241 multicast Queries according to the practical network conditions. For 242 example, if the receiver number is small, the router could send 243 unicast Queries respectively to each receiver, without arousing other 244 non-member terminal which is in dormant state. When the receiver 245 number reaches a predefined level, the router could change to use 246 multicast Queries. To have the knowledge of the number of the valid 247 receivers, a router is required to enable explicit tracking, and 248 because Group-Specific Query and Group-and-Source-Specific Query are 249 usually not used under explicit tracking [RFC6636], the switching 250 operation mostly applies to General Queries. 252 3.2. General Query Supplemented with Unicast Query 254 Unicast Query also can be used in assistance to General Query to 255 improve the robustness of solicited reports when General Query fails 256 to collect all of its valid members. It requires the explicit 257 tracking to be enabled and can be used when a router after sending a 258 periodical General Query collects successfully most of the valid 259 members' responses while losing some of which are still valid in its 260 database. This may be because these reports are not generated or 261 generated but lost for some unknown reasons. The router could choose 262 to unicast a Query respectively to each non-respondent valid receiver 263 to check whether they are still alive for the multicast reception, 264 without affecting the majority of receivers that have already 265 responded. Unicast Queries under this condition could be sent at the 266 end of the [Maximum Response Delay] after posting a General Query, 267 and be retransmitted for [Last Member Query Count] times, at an 268 interval of [Last Member Query Interval]. 270 3.3. Retransmission of Queries 272 In IGMP and MLD, apart from the continuously periodical transmission, 273 General Query is also transmitted during a router's startup. It is 274 transmitted for [Startup Query Count] times by [Startup Query 275 Interval]. There are some other cases where retransmission of 276 General Query is beneficial which are not covered by current IGMP and 277 MLD protocols as shown as following. 279 For example, a router which keeps track of all its active receivers, 280 if after sending a General Query, fails to get any response from the 281 receivers which are still valid in its membership database. This may 282 be because all the responses of the receivers happen to be lost, or 283 the sent Query does not arrive at the other side of the link to the 284 receivers. The router could compensate this situation by 285 retransmitting the General Query to solicit its active members. The 286 retransmission can also be applied to Group-Specific or Group-and- 287 Source-Specific Query on a router without explicit tracking 288 capability, when these Specific Queries cannot collect valid 289 response, to prevent missing valid members caused by lost Queries and 290 Reports. 292 The above compensating Queries could be sent [Last Member Query 293 Count] times, at the interval of [Last Member Query Interval], if the 294 router cannot get any feedback from the receivers. 296 3.4. General Query Suppression 298 In IGMP and MLD, General Query is sent periodically and continuously 299 without any limitation. It helps soliciting the state of current 300 valid member but has to be processed by all hosts on the link, 301 whether they are valid multicast receivers or not. When there is no 302 receiver, the transmission of the General Query is a waste of 303 resources for both the host and the router. 305 An IGMP/MLD router could suppress its transmission of General Query 306 if it knows there is no valid multicast receiver on an interface, 307 e.g. in the following cases: 309 O When the last member reports its leave for a group. This could be 310 judged by an explicit tracking router checking its membership 311 database, or by a non-explicit-tracking router getting no response 312 after sending Group-Specific or Group-and-Source-Specific Query. 314 O When the only member on a PTP link reports its leaving 316 O When a router after retransmitting General Queries on startup fails 317 to get any response 319 O When a router previously has valid members but fails to get any 320 response after several rounds of General Queries. 322 In these cases the router could make the decision that no member is 323 on the interface and totally stop its transmission of periodical 324 General Queries. If afterwards there is any valid member joins a 325 group, the router could resume the original cycle of general 326 Querying. Because General Query has influences on all hosts on a 327 link, suppressing it when it is not needed is beneficial for both the 328 link efficiency and terminal power saving. 330 3.5. Tuning Response Delay According to Link Type and Status 332 IGMP and MLD use delayed response to spread unsolicited Reports from 333 different hosts to reduce possibility of packet burst. This is 334 implemented by a host responding to a Query in a specific time 335 randomly chosen between 0 and [Maximum Response Delay], the latter of 336 which is determined by the router and is carried in Query messages to 337 inform the hosts for calculation of the response delay. A larger 338 value will lessen the burst better but will increase leave latency 339 (the time taken to cease the traffic flowing after the last member 340 requests the escaping of a channel). 342 In order to avoid message burst and reduce leave latency, the 343 Response Delay may be dynamically calculated based on the expected 344 number of responders, and link type and status, as shown in the 345 following: 347 O If the expected number of reporters is large and link condition is 348 bad, longer Maximum Response Delay is recommended; if the expected 349 number of reporters is small and the link condition is good, smaller 350 Maximum response Delay should be set. 352 o If the link type is PTP, the Maximum Response Delay can be chosen 353 smaller, whereas if the link is PTMP or broadcast medium, the Maximum 354 Response Delay can be configured larger. 356 The Maximum Response Delay could be configured by the administrator 357 as mentioned above, or be calculated automatically by a software tool 358 implemented according to experiential model for different link modes. 359 The measures to determine the instant value of Maximum Response Delay 360 are out of this document's scope. 362 3.6. Triggering Reports and Queries Quickly During Handover 364 When a mobile terminal is moving from one network to another, if it 365 is receiving multicast content, its new access network should try to 366 deliver the content to the receiver without disruption or performance 367 deterioration. In order to implement smooth handover between 368 networks, the terminal's membership should be acquired as quickly as 369 possible by the new access network. 371 An access router could trigger a Query to a terminal as soon as it 372 detects the terminal's attaching on its link. This could be a 373 General Query if the number of the entering terminals is not small 374 (e.g when they are simultaneously in a moving train). Or this Query 375 could also be a unicast Query for this incoming terminal to prevent 376 unnecessary action of other terminals in the switching area. 378 For the terminal, it could send a report immediately if it is 379 currently in the multicast reception state, when it begins to connect 380 the new network. This helps establishing more quickly the membership 381 state and enable faster multicast stream injection, because with the 382 active report the router does not need to wait for the query period 383 to acquire the terminal's newest state. 385 4. Applicability and Interoperability Considerations 387 Among the optimizations listed above, 'Switching between unicast and 388 multicast Queries'(3.1) and 'General Query Supplemented with Unicast 389 Query'(3.2) require a router to know beforehand the valid members 390 connected through an interface, thus require explicit tracking 391 capability. An IGMP/MLD implementation could choose any combination 392 of the methods listed from 3.1 to 3.6 to optimize multicast 393 communication on a specific wireless or mobile network. 395 For example, an explicit-tracking IGMPv3 router, can switch to 396 unicast General Queries if the number of members on a link is small 397 (3.1), can trigger unicast Query to a previously valid receiver if 398 failing to get expected responses from it (3.2), can retransmit a 399 General Query if after the previous one cannot collect reports from 400 all valid members (3.3), and can stop sending a General Query when 401 the last member leaves the group (3.4), and etc. 403 For interoperability, it is required if multiple multicast routers 404 are connected to the same network for redundancy, each router are 405 configured with the same optimization policy to synchronize the 406 membership states among the routers. 408 5. IANA Considerations 410 This document makes no request of IANA. 412 Note to RFC Editor: this section may be removed on publication as an 413 RFC. 415 6. Security Considerations 417 Since the methods only involve the tuning of protocol behavior by 418 e.g. retransmission, changing delay parameter, or other compensating 419 operations, they do not introduce additional security weaknesses. 420 The security consderations described in [RFC2236], [RFC3376], 421 [RFC2710] and [RFC3810] can be reused. And to achieve some security 422 level in insecure wireless network, it is possible to take stronger 423 security procedures during IGMP/MLD message exchange, which are out 424 of the scope of this memo. 426 7. Acknowledgements 428 The authors would like to thank Qin Wu, Stig Venaas, Gorry Fairhurst, 429 Thomas C. Schmidt, Marshall Eubanks, Suresh Krishnan, J.William 430 Atwood, WeeSan Lee, Imed Romdhani, Hitoshi Asaeda, Liu Yisong and Wei 431 Yong for their valuable comments and suggestions on this document. 433 8. Normative References 435 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 436 Requirement Levels", BCP 14, RFC 2119, March 1997. 438 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 439 2", RFC 2236, November 1997. 441 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 442 Listener Discovery (MLD) for IPv6", RFC 2710, 443 October 1999. 445 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 446 Thyagarajan, "Internet Group Management Protocol, Version 447 3", RFC 3376, October 2002. 449 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 450 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 452 [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet 453 Group Management Protocol Version 3 (IGMPv3) and Multicast 454 Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, 455 February 2010. 457 [RFC6636] Asaeda, H., Liu, H., and Q. Wu, "Tuning the Behavior of 458 the Internet Group Management Protocol (IGMP) and 459 Multicast Listener Discovery (MLD) for Routers in Mobile 460 and Wireless Networks", RFC 6636, May 2012. 462 Authors' Addresses 464 Hui Liu 465 Huawei Technologies 466 Building Q14, No.156, Beiqing Rd. 467 Beijing 100095 468 China 470 Email: helen.liu@huawei.com 472 Mike McBride 473 Huawei Technologies 474 2330 Central Expressway 475 Santa Clara CA 95050 476 USA 478 Email: michael.mcbride@huawei.com