idnits 2.17.00 (12 Aug 2021) /tmp/idnits51410/draft-liu-multimob-igmp-mld-wireless-mobile-01.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 'Intended status' indicated for this document; assuming Proposed Standard 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 date (March 12, 2012) is 3721 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) == Unused Reference: 'RFC6224' is defined on line 458, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 6224 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 M. McBride 4 Intended status Huawei Technologies 5 Expires: September 13, 2012 March 12, 2012 7 IGMP/MLD Optimization in Wireless and Mobile Networks 8 draft-liu-multimob-igmp-mld-wireless-mobile-01 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 RFC 2119 [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 September 13, 2012. 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. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 75 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. Introduction 80 With the wide deployment of various wireless access techniques and 81 the tendency to support video applications on these networks, 82 wireless and mobile multicast come to attract more and more interests 83 from content and service providers, but still face great challenges 84 when considering dynamic group membership management and constant 85 update of delivery path introduced by node movement, and high 86 probability of loss and congestion due to limited reliability and 87 capacity of wireless links. 89 Multicast network is generally constructed by IGMP and MLD group 90 management protocol (respectively for IPv4 and IPv6 networks) to 91 track valid receivers and by multicast routing protocol to build 92 multicast delivery paths. This document focuses only on IGMP and 93 MLD, which are used by a host to subscribe a multicast group and are 94 most possibly to be exposed to wireless link to support terminal 95 mobility. As IGMP and MLD were designed for fixed users using wired 96 link, they do not necessarily work well for all kinds of wireless 97 link types and mobile scenarios, thus should be enhanced to be 98 adapted to these environments. 100 This memo proposes a variety of optimizations for IGMP and MLD in 101 wireless and mobile networks to improve network performance, with 102 minimum changes on the protocol behavior and without introducing 103 interoperability issues. These solutions can also be applied in 104 wired network when efficiency or reliability is required. 106 For generality, this memo does not put any limitation on the type of 107 wireless techniques running below IGMP or MLD. They could be 108 cellular, WiMAX, WiFi and etc, and are modeled as different abstract 109 link models as described in section 2.2. Even though some over the 110 air techniques (such as WiFi) have multicast limitations, it is 111 probable that IGMP/MLD is enabled on the wireless terminal and 112 multicast needs to be supported across the network. The mobile IP 113 protocol adopted on the core side, upstream from the access router, 114 could either be PMIP, MIPv4, or MIPv6. 116 2. Requirements 118 2.1. Characteristics of Wireless and Mobile Multicast 120 Several aspects should be considered when supporting IP multicast in 121 wireless and mobile networks, including: 123 O Limited link bandwidth: wireless link usually has limited 124 bandwidth, and the situation will be made even worse if high volume 125 video multicast data has to be carried. Also the bandwidth available 126 in the upstream and downstream directions may be asymmetrical. 128 O High loss rate: wireless link usually has packet loss ranging from 129 1% to 30% according to different links types and conditions. Also 130 when packets have to travel between home and access networks (e.g. 131 through tunnel), they are prone to loss if the two networks are 132 distant from each other. 134 O Frequent membership change: in fixed multicast, membership change 135 only happens when a user leaves or joins a group, while in mobile 136 scenario membership may also change when a user changes its location. 138 O Prone to performance degradation: the possible increased 139 interaction of protocols across layers for mobility management, and 140 the limitation of link capacity, may lead to network performance 141 degradation and even to complete connection loss. 143 O Increased Leave Latency: the leave latency in mobile multicast 144 might be increased due to user movement, especially if the traffic 145 has to be transmitted between access and home networks, or if there 146 is a handshake between networks. 148 2.2. Wireless Link Model 150 Wireless links can be categorized by their different transmission 151 modes into three typical models: point-to-point (PTP), point-to- 152 multipoint (PTMP), and broadcast link models. 154 In PTP model, one link is dedicated for two communication facilities. 155 For multicast transmission, each PTP link normally has only one 156 receiver and the bandwidth is dedicated for that receiver. Such link 157 model may be implemented by running PPP on the link or having 158 separate VLAN assignment for each receiver. In mobile network, 159 tunnel between entities of home and foreign networks should be 160 recognized as a PTP link. 162 PTMP is the model for multipoint transmission wherein there is one 163 centralized transmitter and multiple distributed receivers. PTMP 164 provides common downlink channels for all receivers and dedicated 165 uplink channel for each receiver. Bandwidth downstream is shared by 166 all receivers on the same link. 168 Broadcast link can connect two or more nodes and supports broadcast 169 transmission. It is quite similar to fixed Ethernet link model and 170 its link resource is shared in both uplink and downlink directions. 172 2.3. Requirements on IGMP and MLD 174 IGMP and MLD are usually run between mobile or wireless terminals and 175 their first-hop access routers (i.e. home or foreign routers) to 176 subscribe an IP multicast channel. Currently the version in-use 177 includes IGMPv2 [RFC2236] and its IPv6 counterpart MLDv1 [RFC2710], 178 IGMPv3 [RFC3376] and its IPv6 counterpart MLDv2 [RFC3810], and LW- 179 IGMPv3/MLDv2 [RFC5790]. All these versions have basic group 180 management capability required by a multicast subscription. The 181 differences lie in that IGMPv2 and MLDv1 can only join and leave a 182 non-source specific group, while IGMPv3 and MLDv2 can select 183 including and excluding specific sources for their join and leave 184 operation, and LW-IGMPv3/MLDv2 simplifies IGMPv3/MLDv2 procedures by 185 discarding excluding-source function. Among these versions, (LW-) 186 IGMPv3/MLDv2 has the capability of explicit track each host member. 188 From the illustration given in section 2.1 and 2.2, it is desirable 189 for IGMP and MLD to have the following characteristics when used in 190 wireless and mobile networks: 192 o Adaptive to link conditions: wireless network has various link 193 types, each with different bandwidth and performance features. IGMP 194 or MLD should be able to be adaptive to different link model and link 195 conditions to optimize its protocol operation. 197 o Minimal group Join/Leave latency: because mobility and handover may 198 cause a user to join and leave a multicast group frequently, fast 199 join and leave by the user helps to accelerate service activation and 200 to release unnecessary resources quickly to optimize resource 201 utilization. 203 o Robust to packet loss: the unreliable packet transmission due to 204 instable wireless link conditions and limited bandwidth, or long 205 distance transmission in mobile network put more strict robustness 206 requirement on delivery of IGMP and MLD protocol messages. 208 o Reducing packet exchange: wireless link resources are usually more 209 limited, precious, and congested compared to their wired counterpart. 210 This requires packet exchange be minimized without degrading protocol 211 performance. 213 o Packet burst avoidance: large number of packets generated within a 214 short time interval may have the tendency to deteriorate wireless 215 network conditions. IGMP and MLD should be optimized if their 216 protocol message generation has the potential of introducing packet 217 burst. 219 3. IGMP/MLD Optimization for Wireless and Mobile Networks 221 This section introduces several optimization methods for IGMP and MLD 222 in wireless or mobile environment. The aim is to meet the 223 requirements described in section 2.3. These measures could be 224 applied between host and access routers in mobile or wireless 225 network. It should be noted that because an enhancement in one 226 direction might result in weakening effect in another, balances 227 should be taken cautiously to realize overall performance elevation. 229 3.1. Switching Between Unicast and Multicast Queries 231 IGMP/MLD protocols use multicast Queries whose destination addresses 232 are multicast addresses and also allow use of unicast Query with 233 unicast destination to be sent only for one destination. Unicast 234 Query has the advantage of not affecting other hosts on the same 235 link, and is desirable for wireless communication because a mobile 236 terminal often has limited battery power. But if the number of valid 237 receivers is large, using unicast Query for each receiver is 238 inefficient because large number of Unicast Queries have to be 239 generated, in which situation normal multicast Query will be a good 240 choice because only one General Query is needed. If the number of 241 receivers to be queried is small, unicast Query is advantageous over 242 the multicast one. 244 More flexibly, the router can choose to switch between unicast and 245 multicast Query according to the practical network conditions. For 246 example, if the receiver number is small, the router could send 247 unicast Queries respectively to each receiver, without arousing other 248 non-member host which is in dormant state. When the receiver number 249 reaches a predefined level, the router could change to use multicast 250 Queries. To have the knowledge of the number of the valid receivers, 251 a router is required to enable explicit tracking, and because Group- 252 Specific Query and Group-and-Source-Specific Query are usually not 253 used under explicit tracking, the switching mostly applies to General 254 Queries. 256 3.2. General Query Supplemented with Unicast Query 258 Unicast Query also can be used in assistance to General Query to 259 improve the robustness of solicited reports when General Query fails 260 to collect all of its valid members. It requires the explicit 261 tracking to be enabled and can be used when a router after sending a 262 periodical General Query collects successfully most of the valid 263 members' responses while losing some of which are still valid in its 264 database. This may be because the non-respondent ones silently leave 265 the network without any notification, or because their reports are 266 lost for some unknown reasons. The router could choose to unicast a 267 Query respectively to each non-respondent valid receiver to check 268 whether they are still alive for the multicast reception, without 269 affecting the majority of receivers that have already responded. 270 Unicast Queries under this condition could be sent at the end of the 271 [Maximum Response Delay] after posting a General Query, and be 272 retransmitted for [Last Member Query Count] times, at a constant 273 interval or at incremental interval as described [ADAPTIVE]. 275 3.3. Retransmission of Queries 277 In IGMP and MLD, apart from the continuously periodical transmission, 278 General Query is also transmitted during a router's startup. It is 279 transmitted for [Startup Query Count] times by [Startup Query 280 Interval]. There are some other cases where retransmission of 281 General Query is beneficial which are not covered by current IGMP and 282 MLD protocols as shown as following. 284 For example, a router which keeps track of all its active receivers, 285 if after sending a General Query, fails to get any response from the 286 receivers which are still valid in its membership database. This may 287 be because all these valid receivers have left the group silently or 288 moved out of range, or all the responses of the receivers happen to 289 be lost, or the sent Query does not arrive at the other side of the 290 link to the receivers. The router could compensate this situation by 291 retransmitting the General Query to solicit its active members. The 292 retransmission can also be used to group or source-specific group 293 Queries on a router without explicit tracking capability, when the 294 Queries cannot collect valid response, to prevent missing valid 295 memebers caused by lost Queries and Reports. 297 The compensating Queries could be sent several times, if the router 298 cannot get any feedback from the receivers. The repetition of the 299 transmission could be in fixed interval, or in prolonged interval as 300 described [ADAPTIVE]. 302 3.4. General Query Suppression 304 In IGMP and MLD, General Query is sent periodically and continuously 305 without any limitation. It helps soliciting the state of current 306 valid member but has to be processed by all terminals on the link, 307 whether they are valid multicast receivers or not. When there is no 308 receiver, the transmission of the General Query is a waste of 309 resources for both the terminals and the router. 311 An IGMP/MLD router could suppress its transmission of General Query 312 if it knows there is no valid multicast receiver on an interface, 313 e.g. in the following cases: 315 O When the last member reports its leave for a group. This could be 316 judged by an explicit tracking router checking its membership 317 database, or by a non-explicit-tracking router getting no response 318 after sending Group-Specific Query or Group-and-Source-Specific Query 320 O When the only member on a PTP link reports its leaving 322 O When a router after retransmitting General Queries on startup fails 323 to get any response 325 O When a router previously has valid members but fails to get any 326 response after several rounds of General Queries. 328 In these cases the router could make the decision that no member is 329 on the interface and totally stop its transmission of periodical 330 General Queries. If afterwards there is any valid member joins a 331 group, the router could resume the original cycle of general 332 Querying. Because General Query has influences on all terminals on a 333 link, suppressing it when it is not needed is beneficial for both the 334 link efficiency and terminal power saving. 336 3.5. Tuning Response Delay According to Link Type and Status 338 IGMP and MLD use delayed response to spread unsolicited Reports from 339 different hosts to reduce possibility of packet burst. This is 340 implemented by a host responding to a Query in a specific time 341 randomly chosen between 0 and [Maximum Response Delay]. The value of 342 [Maximum Response Delay] is determined by the router and is carried 343 in Query messages to inform the hosts for the calculation. A larger 344 value will lessen the burst better but will increase leave latency 345 (the time between the last listener request escaping a channel and 346 the traffic actually ceases flowing). 348 In order to avoid message burst and reduce leave latency, the 349 Response Delay may be dynamically calculated based on the expected 350 number of responders, and link type and status, as shown in the 351 following: 353 O If the expected number of reporters is large and link condition is 354 bad, the system administrator MUST choose the longer Maximum Response 355 Delay; if the expected number of reporters is small and the link 356 condition is good, smaller Maximum response Delay should be set. In 357 this way, the IGMP/MLD packet burst can be reduced. 359 o If the link type is PTP, the Maximum Response Delay can be chosen 360 smaller, whereas if the link is PTMP or broadcast medium, the Maximum 361 Response Delay can be configured larger. 363 The Maximum Response Delay could be configured by the administrator 364 as mentioned above, or be calculated automatically by a software tool 365 implemented according to experiential model for different link modes. 366 How to determine the instant value of Maximum Response Delay is out 367 of this document's scope. 369 3.6. Triggering Reports and Queries Quickly During Handover 371 When a mobile terminal is moving from one network to another, if it 372 is receiving multicast content, its new access network should try to 373 deliver the content to the receiver without disruption or performance 374 deterioration. In order to implement smooth handover between 375 networks, the terminal's membership should be acquired as quickly as 376 possible by the new access network. 378 The access router could trigger a Query to the terminal as soon as it 379 detects a new terminal on its link. This could be a General Query if 380 the number of the entering terminals is not small. Or this Query 381 could also be a unicast Query for this incoming terminal to prevent 382 unnecessary action of other terminals in the switching area. 384 For the terminal, it could send a report immediately if it is 385 currently in the multicast reception state, when it begins to connect 386 the new network. This helps establishing more quickly the membership 387 state and enable faster multicast stream injection, because with the 388 active report the router does not need to wait for the query period 389 to acquire the terminal's newest state. 391 4. Applicability and Interoperability Considerations 393 Among the optimizations listed above, 'Switching between unicast and 394 multicast Queries'(3.1) and 'General Query Supplemented with Unicast 395 Query'(3.2) require a router to know beforehand the valid members 396 connected through an interface, thus require explicit tracking 397 capability. An IGMP/MLD implementation could choose any combination 398 of the methods listed from 3.1 to 3.6 to optimize multicast 399 communication on a specific wireless or mobile network. 401 For example, an explicit-tracking IGMPv3 router, can switch to 402 unicast General Queries if the number of members on a link is small 403 (3.1), can trigger unicast Query to a previously valid receiver if 404 failing to get expected responses from it (3.2), can retransmit a 405 General Query if after the previous one cannot collect reports from 406 all valid members (3.3), and can stop sending a General Query when 407 the last member leaves the group (3.4), and etc. 409 For interoperability, it is required if multiple multicast routers 410 are connected to the same network for redundancy, each router are 411 configured with the same optimization policy to synchronize the 412 membership states among the routers. 414 5. IANA Considerations 416 This document makes no request of IANA. 418 Note to RFC Editor: this section may be removed on publication as an 419 RFC. 421 6. Security Considerations 423 They will be described in the later version of this draft. 425 7. Acknowledgements 427 The authors would like to thank Qin Wu, Stig Venaas, Gorry Fairhurst, 428 Thomas C. Schmidt, Marshall Eubanks, Suresh Krishnan, J.William 429 Atwood, WeeSan Lee, Imed Romdhani, Hitoshi Asaeda, Liu Yisong and Wei 430 Yong for their valuable comments and suggestions on this document. 432 8. References 434 8.1. Normative References 436 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 437 Requirement Levels", BCP 14, RFC 2119, March 1997. 439 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 440 2", RFC 2236, November 1997. 442 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 443 Listener Discovery (MLD) for IPv6", RFC 2710, 444 October 1999. 446 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 447 Thyagarajan, "Internet Group Management Protocol, Version 448 3", RFC 3376, October 2002. 450 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 451 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 453 [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet 454 Group Management Protocol Version 3 (IGMPv3) and Multicast 455 Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, 456 February 2010. 458 [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base 459 Deployment for Multicast Listener Support in Proxy Mobile 460 IPv6 (PMIPv6) Domains", RFC 6224, April 2011. 462 8.2. Informative References 464 [ADAPTIVE] 465 Romdhani, I., Bettahar, H., and A. Bouabdallah, "Adaptive 466 Multicast Membership Management for Mobile Multicast 467 Receivers", IEEE , 2000. 469 Authors' Addresses 471 Hui Liu 472 Huawei Technologies 473 Building Q14, No.156, Beiqing Rd. 474 Beijing 100095 475 China 477 Email: helen.liu@huawei.com 479 Mike McBride 480 Huawei Technologies 481 2330 Central Expressway 482 Santa Clara CA 95050 483 USA 485 Email: michael.mcbride@huawei.com