idnits 2.17.00 (12 Aug 2021) /tmp/idnits52390/draft-liu-multimob-igmp-mld-wireless-mobile-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 : ---------------------------------------------------------------------------- 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 2, 2012) is 3731 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: September 3, 2012 March 2, 2012 7 IGMP/MLD Optimization in Wireless and Mobile Networks 8 draft-liu-multimob-igmp-mld-wireless-mobile-00 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 3, 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 . . . . . . . . . . . . . . . 4 62 3. IGMP/MLD optimization for Wireless and Mobile Network . . . . 5 63 3.1. Minimizing Query Frequency by increasing intervals . . . . 6 64 3.2. Switching Between Unicast and Multicast Queries . . . . . 7 65 3.3. General Query Supplemented with Unicast Query . . . . . . 7 66 3.4. Retransmission of General Query . . . . . . . . . . . . . 8 67 3.5. General Query Supplemented with Unicast Query . . . . . . 8 68 3.6. Tuning Response Delay according to link type and status . 9 69 3.7. Triggering Reports and Queries quickly during handover . . 10 70 4. Applicability and interoperability considerations . . . . . . 10 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 With the wide deployment of various wireless access techniques and 82 the tendency to support video applications on these networks, 83 wireless and mobile multicast come to attract more and more interests 84 from content and service providers, but still face great challenges 85 when considering dynamic group membership management and constant 86 update of delivery path introduced by node movement, and high 87 probability of loss and congestion due to limited reliability and 88 capacity of wireless links. 90 Multicast network is generally constructed by IGMP and MLD group 91 management protocol (respectively for IPv4 and IPv6 networks) to 92 track valid receivers and by multicast routing protocol to build 93 multicast delivery paths. This document focuses only on IGMP and 94 MLD, which are used by a host to subscribe a multicast group and are 95 most possibly to be exposed to wireless link to support terminal 96 mobility. As IGMP and MLD were designed for fixed users using wired 97 link, they do not necessarily work well for all kinds of wireless 98 link types and mobile scenarios, thus should be enhanced to be 99 adapted to these environment. 101 This memo proposes a variety of optimizations for IGMP and MLD in 102 wireless and mobile networks to improve network performance, with 103 minimum changes on the protocol behavior while without introducing 104 interoperability issues. These solutions can also be applied in 105 wired network when efficiency or reliability is required. 107 2. Requirements 109 2.1. Characteristics of Wireless and mobile Multicast 111 Several aspects should be considered when supporting IP multicast in 112 wireless and mobile networks, including: 114 O Limited link bandwidth: wireless link usually has limited 115 bandwidth, and the situation will be made even worse if high volume 116 video multicast data has to be carried. Also the bandwidth available 117 in the upstream and downstream directions may be asymmetrical. 119 O High loss rate: wireless link usually has packet loss ranging from 120 1% to 30% according to different links types and conditions. Also 121 when packets have to travel between home and access networks (e.g. 122 through tunnel), they are prone to loss if the two networks are 123 distant from each other. 125 O Frequent membership change: in fixed multicast, membership change 126 only happens when a user leaves or joins a group, while in mobile 127 scenario membership may also change when a user changes its location. 129 O Prone to performance degradation: the possible increased 130 interaction of protocols across layers for mobility management, and 131 the limitation of link capacity, may lead to network performance 132 degradation and even to complete connection loss. 134 O Increased Leave Latency: the leave latency in mobile multicast 135 might be increased due to user movement, especially if the traffic 136 has to be transmitted between access and home networks, or if there 137 is a handshake between networks. 139 2.2. Wireless Link Model 141 Wireless links can be categorized by their different transmission 142 modes into three typical models: point-to-point (PTP), point-to- 143 multipoint (PTMP), and broadcast link models. 145 In PTP model, one link is dedicated for two communication facilities. 146 For multicast transmission, each PTP link normally has only one 147 receiver and the bandwidth is dedicated for that receiver. Such link 148 model may be implemented by running PPP on the link or having 149 separate VLAN assignment for each receiver. In mobile network, 150 tunnel between entities of home and foreign networks should be 151 recognized as a PTP link. 153 PTMP is the model for multipoint transmission wherein there is one 154 centralized transmitter and multiple distributed receivers. PTMP 155 provides common downlink channels for all receivers and dedicated 156 uplink channel for each receiver. Bandwidth downstream is shared by 157 all receivers on the same link. 159 Broadcast link can connect two or more nodes and supports broadcast 160 transmission. It is quite similar to fixed Ethernet link model and 161 its link resource is shared in both uplink and downlink directions. 163 2.3. Requirements on IGMP and MLD 165 IGMP and MLD are usually run between mobile or wireless terminals and 166 their first-hop access routers (i.e.home or foreign routers) to 167 subscribe an IP multicast channel, and sometimes run between home 168 router and access router (in PMIP case [RFC6224]) to proxy IGMP/MLD 169 in mobile network the summarized IGMP/MLD reports from the latter to 170 the former. Currently the version in-use includes IGMPv2 [RFC2236] 171 and its IPv6 counterpart MLDv1 [RFC2710], IGMPv3 [RFC3376] and its 172 IPv6 counterpart MLDv2 [RFC3810], and lightweight IGMPv3/MLDv2 173 [RFC5790]. All these versions have basic group management capability 174 required by a multicast subscription. The differences lie in that 175 IGMPv2 and MLDv1 can only join and leave a non-source specific group, 176 while IGMPv3 and MLDv2 can select including and excluding specific 177 sources for their join and leave operation, and LW-IGMPv3/MLDv2 178 simplifies IGMPv3/MLDv2 procedures by discarding useless excluding- 179 source function. Among these versions, (LW-) IGMPv3/MLDv2 has the 180 capability of explicit track each host member. 182 From the illustration given in section 2.1 and 2.2, it is desirable 183 for IGMP and MLD to have the following characteristics when used in 184 wireless and mobile networks: 186 o Adaptive to link conditions: wireless network has various link 187 types, each with different bandwidth and performance features. IGMP 188 or MLD should be able to be adaptive to different link model and link 189 conditions to optimize its protocol operation. 191 o Minimal group Join/Leave latency: because mobility and handover may 192 cause a user to join and leave a multicast group frequently, fast 193 join and leave by the user helps to accelerate service activation and 194 to release unnecessary resources quickly to optimize resource 195 utilization. 197 o Robust to packet loss: the unreliable packet transmission due to 198 instable wireless link conditions and limited bandwidth, or long 199 distance transmission in mobile network put more strict robustness 200 requirement on delivery of IGMP and MLD protocol messages. 202 o Reducing packet exchange: wireless link resources are usually more 203 limited, precious, and congested compared to their wired counterpart. 204 This requires packet exchange be minimized without degrading protocol 205 performance. 207 o Packet burst avoidance: large number of packets generated within a 208 short time interval may have the tendency to deteriorate wireless 209 network conditions. IGMP and MLD should be optimized if their 210 protocol message generation has the potential of introducing packet 211 burst. 213 3. IGMP/MLD optimization for Wireless and Mobile Network 215 This section introduces several optimization methods for IGMP and MLD 216 in wireless or mobile environment. The aim is to meet the 217 requirements described in section 2.3. These measures could be 218 applied between host and access routers in mobile or wireless 219 network, and in mobile PMIPv6 [RFC6224] case, could also be used 220 between access and home routers. It should be noted that because an 221 enhancement in one direction might result in weakening effect in 222 another, balances should be taken cautiously to realize overall 223 performance elevation. 225 3.1. Minimizing Query Frequency by increasing intervals 227 In IGMP and MLD, Group-Specific Query and Group-and-Source-Specific 228 Query are triggered on reception of a Leave message, and are sent for 229 [Last Member Query Count] times with fixed [Last Member Query 230 Interval], to learn whether there are valid members from an attached 231 link. If a network is undergoing congestion, multiple transmissions 232 of the Queries as above may further deteriorate the conditions. To 233 avoid congestion or make remedy during congestion, these Queries can 234 be slowed down when a router cannot collect successfully expected 235 responses. 237 The slowing down process of the Queries could be arranged in a 238 prolonged time interval as described in [ADAPTIVE]. The slowdown 239 process should be: a router after sending a Query, if acquires the 240 expected responses from the receivers, refreshes its state database 241 and optionally stop the querying retransmission process, or if after 242 a time interval fails to get the expected report responses, resends a 243 Query with an increased (e.g. double) interval. This process can be 244 repeated, each time the retransmission is arranged in a progressively 245 prolonged time interval, till the router receives the expected 246 responses, or determines the receiver is unreachable and stops the 247 sending of the Query. 249 Query slowdown can be applied in the cases as listed in the following 250 examples: 252 O When Group-Specific Query and Group-and-Source-Specific Query are 253 used to track other members but cannot get any response. 255 O When all group members leave a group or move out of scope, the 256 General Query sent by the router cannot solicit any response on a 257 network, as illustrated in section 3.4. 259 O When General Query is retransmitted due to possible loss or 260 congestion deducing from no responses from valid members in the 261 database, on the primes that explicit tracking is used. 263 O When General Query is retransmitted by a router on startup but no 264 response can be acquired. 266 O When unicast Query is sent to query a particular valid receiver, 267 from whom no response could be collected, as described in section 3.2 268 and 3.3. This requires explicit tracking to be enabled. 270 Query retransmission with incremental interval enables the router to 271 reduce the total query-response times and consequently the packet 272 count. The variable time interval and the termination condition of 273 retransmission should be configurable and could be set according to 274 actual network condition, which is out the scope of this document. 276 3.2. Switching Between Unicast and Multicast Queries 278 IGMP/MLD protocols use multicast Queries whose destination addresses 279 are multicast addresses and also allow use of unicast Query with 280 unicast destination to be sent only for one destination. Unicast 281 Query has the advantage of not affecting other hosts on the same 282 link, and is desirable for wireless communication because a mobile 283 terminal often has limited battery power. But if the number of valid 284 receivers is large, using unicast Query for each receiver is 285 inefficient because large number of Unicast Queries have to be 286 generated, in which situation normal multicast Query will be a good 287 choice because only one General Query is needed. If the number of 288 receivers to be queried is small, unicast Query is advantageous over 289 the multicast one. 291 More flexibly, the router can choose to switch between unicast and 292 multicast Query according to the practical network conditions. For 293 example, if the receiver number is small, the router could send 294 unicast Queries respectively to each receiver, without arousing other 295 non-member host which is in the dormant state. When the receiver 296 number reaches a predefined level, the router could change to use 297 multicast Queries. To have the knowledge of the number of the valid 298 receivers, a router is required to enable explicit tracking, and 299 because Group-Specific Query and Group-and-Source-Specific Query are 300 usually not used under explicit tracking, the switching only applies 301 to General Queries. 303 3.3. General Query Supplemented with Unicast Query 305 Unicast Query also can be used in assistance to General Query to 306 improve the robustness of solicited reports when General Query fails 307 to collect all of its valid members. It requires the explicit 308 tracking to be enabled and can be used when a router after sending a 309 periodical General Query collects successfully most of the valid 310 members' responses while losing some of which are still valid in its 311 database. This may be because the non-respondent ones silently leave 312 the network without any notification, or because their reports are 313 lost for some unknown reasons. The router could choose to unicast a 314 Query respectively to each non-respondent valid receiver to check 315 whether they are still alive for the multicast reception, without 316 affecting the majority of receivers that have already responded. 317 Unicast Queries under this condition could be sent at the end of the 319 [Maximum Response Delay] after posting a General Query, and be 320 retransmitted for [Last Member Query Count] times, at a constant 321 interval, or at incremental interval as described in section 3.1. 323 3.4. Retransmission of General Query 325 In IGMP and MLD, apart from the continuously periodical transmission, 326 General Query is also transmitted during a router's startup. It is 327 transmitted for [Startup Query Count] times by [Startup Query 328 Interval]. There are some other cases where retransmission of 329 General Query is beneficial which are not covered by current IGMP and 330 MLD protocols as shown as following. 332 For example, a router which keeps track of all its active receivers, 333 if after sending a General Query, fails to get any response from the 334 receivers which are still valid in its membership database. This may 335 be because all these valid receivers have left the group silently or 336 moved out of range, or all the responses of the receivers happen to 337 be lost, or the sent Query does not arrive at the other side of the 338 link to the receivers. The router could compensate this situation by 339 retransmitting the General Query to solicit its active members. 341 This compensating General Query could be sent several times, if the 342 router cannot get any feedback from the receivers which are valid in 343 the database. The repetition of the transmission could be in fixed 344 interval, or in prolonged interval as described in section 3.1. The 345 method can also be applied to router without explicit tracking 346 enabled, in which case General Query is retransmitted if no valid 347 response can be collected for a group or source-specific group which 348 previously has valid reception state. 350 3.5. General Query Supplemented with Unicast Query 352 In IGMP and MLD, General Query is sent periodically and continuously 353 without any limitation. It helps soliciting the state of current 354 valid member but has to be processed by all terminals on the link, 355 whether they are valid multicast receivers or not. When there is no 356 receiver, the transmission of the General Query is a waste of 357 resources for both the terminals and the router. 359 An IGMP/MLD router could suppress its transmission of General Query 360 if it knows there is no valid multicast receiver on an interface, 361 e.g. in the following cases: 363 O When the last member reports its leave for a group. This could be 364 judged by an explicit tracking router checking its membership 365 database, or by a non-explicit-tracking router getting no response 366 after sending Group-Specific Query or Group-and-Source-Specific Query 367 O When the only member on a PTP link reports its leaving 369 O When a router after retransmitting General Queries on startup fails 370 to get any response 372 O When a router previously has valid members but fails to get any 373 response after several rounds of General Queries. 375 In these cases the router could make the decision that no member is 376 on the interface and totally stop its transmission of periodical 377 General Queries. If afterwards there is any valid member joins a 378 group, the router could resume the original cycle of general 379 Querying. Because General Query has influences on all terminals on a 380 link, suppressing it when it is not needed is beneficial for both the 381 link efficiency and terminal power saving. 383 3.6. Tuning Response Delay according to link type and status 385 IGMP and MLD use delayed response to spread unsolicited Reports from 386 different hosts to reduce possibility of packet burst. This is 387 implemented by a host responding to a Query in a specific time 388 randomly chosen between 0 and [Maximum Response Delay]. The value of 389 [Maximum Response Delay] is determined by the router and is carried 390 in Query messages to inform the hosts for the calculation. A larger 391 value will lessen the burst better but will increase leave latency 392 (the time between the last listener request escaping a channel and 393 the traffic actually ceases flowing). 395 In order to avoid message burst and reduce leave latency, the 396 Response Delay may be dynamically calculated based on the expected 397 number of responders, and link type and status, as shown in the 398 following: 400 O If the expected number of reporters is large and link condition is 401 bad, the system administrator MUST choose the longer Maximum Response 402 Delay; if the expected number of reporters is small and the link 403 condition is good, smaller Maximum response Delay should be set. In 404 this way, the IGMP/MLD packet burst can be reduced. 406 o If the link type is PTP, the Maximum Response Delay can be chosen 407 smaller, whereas if the link is PTMP or broadcast medium, the Maximum 408 Response Delay can be configured larger. 410 The Maximum Response Delay could be configured by the administrator 411 as mentioned above, or be calculated automatically by a software tool 412 implemented according to experiential model for different link modes. 413 How to determine the instant value of Maximum Response Delay is out 414 of this document's scope. 416 3.7. Triggering Reports and Queries quickly during handover 418 When a mobile terminal is moving from one network to another, if it 419 is receiving multicast content, its new access network should try to 420 deliver the content to the receiver without disruption or performance 421 deterioration. In order to implement smooth handover between 422 networks, the terminal's membership should be acquired as quickly as 423 possible by the new access network. 425 The access router could trigger a Query to the terminal as soon as it 426 detects a new terminal on its link. This could be a General Query if 427 the number of the entering terminals is not small. Or this Query 428 could also be a unicast Query for this incoming terminal to prevent 429 unnecessary action of other terminals in the switching area. 431 For the terminal, it could send a report immediately if it is 432 currently in the multicast reception state, when it begins to connect 433 the new network. This helps establishing more quickly the membership 434 state and enable faster multicast stream injection, because with the 435 active report the router does not need to wait for the query period 436 to acquire the terminal's newest state. 438 4. Applicability and interoperability considerations 440 Among the optimizations listed above, 'Switching between unicast and 441 multicast Queries'(3.2) and 'General Query Supplemented with Unicast 442 Query'(3.3) require a router to know beforehand the valid members 443 connected through an interface, thus require explicit tracking 444 capability. "Minimizing Query Frequency by increasing intervals" 445 (3.1) is only meaningful when for the same network condition the 446 retransmission count for a fixed interval is not small (more than the 447 default value of 2). An IGMP/MLD implementation could choose any 448 combination of the methods listed from 3.1 to 3.7 to optimize 449 multicast communication on a specific wireless or mobile network. 451 For example, an explicit-tracking IGMPv3 router, can switch to 452 unicast General Query if the number of members on a link is small 453 (3.3), can trigger unicast Query to a previously valid receiver if 454 failing to get expected responses from it (3.3), can retransmit a 455 General Query if after the previous one cannot collect reports from 456 valid members (3.4), and can stop sending a General Query when the 457 last member leaves the group (3.5), and etc. 459 For interoperability, it is suggested if multiple multicast routers 460 are connected to the same network for redundancy, each router are 461 configured with the same optimization policy to synchronize the 462 membership states among the routers.. 464 5. IANA Considerations 466 This document makes no request of IANA. 468 Note to RFC Editor: this section may be removed on publication as an 469 RFC. 471 6. Security Considerations 473 They will be described in the later version of this draft. 475 7. Acknowledgements 477 The authors would like to thank Qin Wu, Stig Venaas, Gorry Fairhurst, 478 Thomas C. Schmidt, Marshall Eubanks, Suresh Krishnan, J.William 479 Atwood, WeeSan Lee, Imed Romdhani, Hitoshi Asaeda, Liu Yisong and Wei 480 Yong for their valuable comments and suggestions on this document. 482 8. References 484 8.1. Normative References 486 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 487 Requirement Levels", BCP 14, RFC 2119, March 1997. 489 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 490 2", RFC 2236, November 1997. 492 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 493 Listener Discovery (MLD) for IPv6", RFC 2710, 494 October 1999. 496 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 497 Thyagarajan, "Internet Group Management Protocol, Version 498 3", RFC 3376, October 2002. 500 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 501 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 503 [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet 504 Group Management Protocol Version 3 (IGMPv3) and Multicast 505 Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, 506 February 2010. 508 [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base 509 Deployment for Multicast Listener Support in Proxy Mobile 510 IPv6 (PMIPv6) Domains", RFC 6224, April 2011. 512 8.2. Informative References 514 [ADAPTIVE] 515 Romdhani, I., Bettahar, H., and A. Bouabdallah, "Adaptive 516 Multicast Membership Management for Mobile Multicast 517 Receivers", IEEE , 2000. 519 Authors' Addresses 521 Hui Liu 522 Huawei Technologies 523 Building Q14, No.156, Beiqing Rd. 524 Beijing 100095 525 China 527 Email: helen.liu@huawei.com 529 Mike McBride 530 Huawei Technologies 531 2330 Central Expressway 532 Santa Clara CA 95050 533 USA 535 Email: michael.mcbride@huawei.com