idnits 2.17.1 draft-ietf-pim-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 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 (August 23, 2013) is 3870 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. -------------------------------------------------------------------------------- 1 PIM Working Group H. Liu 2 Internet-Draft 3 Intended status: Informational M. McBride 4 Expires: February 24, 2014 Huawei Technologies 5 H. Asaeda 6 NICT 7 August 23, 2013 9 IGMP/MLD Optimizations in Wireless and Mobile Networks 10 draft-ietf-pim-igmp-mld-wireless-mobile-00 12 Abstract 14 This document proposes a variety of optimization approaches for IGMP 15 and MLD in wireless and mobile networks. It aims to provide useful 16 guidelines to allow efficient multicast communication in these 17 networks using IGMP or MLD protocols. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in [RFC2119]. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on February 24, 2014. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Characteristics of Wireless and Mobile Multicast . . . . . 3 62 2.2. Wireless Link Model . . . . . . . . . . . . . . . . . . . 4 63 2.3. Requirements on IGMP and MLD . . . . . . . . . . . . . . . 5 64 3. IGMP/MLD Optimization for Wireless and Mobile Networks . . . . 6 65 3.1. Switching Between Unicast and Multicast Queries . . . . . 6 66 3.2. General Query Supplemented with Unicast Query . . . . . . 6 67 3.3. Retransmission of Queries . . . . . . . . . . . . . . . . 7 68 3.4. General Query Suppression . . . . . . . . . . . . . . . . 7 69 3.5. Tuning Response Delay According to Link Type and Status . 8 70 3.6. Triggering Reports and Queries Quickly During Handover . . 9 71 4. Applicability and Interoperability Considerations . . . . . . 9 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 77 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 The deployments of various wireless access techniques are being 83 combined with the use of video and other applications which rely upon 84 IP Multicast. Wireless and mobile multicast are attracting 85 increasing interest from content and service providers. Multicast 86 faces challenges with dynamic group membership management being under 87 the constant update of delivery paths introduced by node movement. 88 There is a high probability of loss and congestion due to limited 89 reliability and capacity of wireless links. 91 Multicast networks are generally constructed by the IGMP and MLD 92 group management protocols (respectively for IPv4 and IPv6 networks) 93 to track valid receivers and by multicast routing protocol building 94 multicast delivery paths. This document focuses only on IGMP and 95 MLD, the protocols used by a host to subscribe to a multicast group 96 and the protocols that are most likely to be exposed to wireless 97 links when supporting terminal mobility. As IGMP and MLD were 98 designed for fixed users on a wired link, they do not necessarily 99 work well for different wireless link types and mobile scenarios. 100 IGMP/MLD should be enhanced to be more applicable in these mobile/ 101 wireless environments. 103 This memo proposes a variety of optimizations for IGMP and MLD, in 104 wireless and mobile networks, to improve network performance, with 105 minimum changes on the protocol behavior and without introducing 106 interoperability issues. These solutions can also be applied in 107 wired networks when efficiency or reliability is required. 109 For generality, this memo does not put limitations on the type of 110 wireless techniques running below IGMP or MLD. They could be 111 cellular, WiMAX, WiFi and etc, and are modeled as different abstract 112 link models as described in section 2.2. Even though some of them 113 (such as WiFi) have multicast limitations, it is probable that IGMP/ 114 MLD is enabled on the wireless terminal and multicast is supported 115 across the network. The mobile IP protocol adopted on the core side, 116 upstream from the access router, could be PMIP, MIPv4, or MIPv6. 118 2. Requirements 120 2.1. Characteristics of Wireless and Mobile Multicast 122 Several limitations should be considered when supporting IP multicast 123 in wireless and mobile networks, including: 125 O Limited link bandwidth: wireless links usually have limited 126 bandwidth, and the situation will be made even worse if a high volume 127 of video multicast data has to be carried. Additionally, the 128 bandwidth available in the upstream and downstream directions may be 129 asymmetrical. 131 O High loss rate: wireless links usually have packet loss ranging 132 from 1% to 30% according to different links types and conditions. 133 Also when packets have to travel between home and access networks 134 (e.g. through a tunnel), they are prone to loss if the two networks 135 are distant from each other. 137 O Frequent membership change: in fixed multicast, membership change 138 only happens when a user leaves or joins a group, while in mobile 139 scenario membership may also change when a user changes its location. 141 O Prone to performance degradation: the possible increased 142 interaction of protocols across layers for mobility management, and 143 the limitation of link capacity, may lead to network performance 144 degradation and even to complete connection loss. 146 O Increased Leave Latency: the leave latency in mobile multicast 147 might be increased due to user movement, especially if the traffic 148 has to be transmitted between access and home networks, or if there 149 is a handshake between networks. 151 2.2. Wireless Link Model 153 Wireless links can typically be categorized into three models: point- 154 to-point (PTP), point-to- multipoint (PTMP), and broadcast link 155 models. 157 In the PTP model, one link is dedicated for two communication 158 facilities. For multicast transmission, each PTP link normally has 159 only one receiver and the bandwidth is dedicated for that receiver. 160 Such link model may be implemented by running PPP on the link or 161 having separate VLAN assignment for each receiver. In a mobile 162 network, a tunnel between entities of home and foreign networks 163 should be recognized as a PTP link. 165 PTMP is the model for multipoint transmission wherein there is one 166 centralized transmitter and multiple distributed receivers. PTMP 167 provides common downlink channels for all receivers and dedicated 168 uplink channel for each receiver. Bandwidth downstream is shared by 169 all receivers on the same link. 171 Broadcast links can connect two or more nodes and support broadcast 172 transmissions. It is quite similar to fixed Ethernet link model and 173 its link resource is shared in both uplink and downlink directions. 175 2.3. Requirements on IGMP and MLD 177 IGMP and MLD are usually run between mobile or wireless terminals and 178 their first-hop access routers (i.e. home or foreign routers) to 179 subscribe to a IP multicast channel. Currently the version in-use 180 includes IGMPv2 [RFC2236] and its IPv6 counterpart MLDv1 [RFC2710], 181 IGMPv3 [RFC3376] and its IPv6 counterpart MLDv2 [RFC3810], and LW- 182 IGMPv3/MLDv2 [RFC5790]. All these versions have basic group 183 management capability required by a multicast subscription. The 184 differences lie in that IGMPv2 and MLDv1 can only join and leave a 185 non-source-specific group, while IGMPv3 and MLDv2 can select 186 including and excluding specific sources for their join and leave 187 operation, and LW-IGMPv3/MLDv2 simplifies IGMPv3/MLDv2 procedures by 188 discarding excluding-source function. Among these versions, (LW-) 189 IGMPv3/MLDv2 has the capability of explicitly tracking each host 190 member. 192 From the illustration given in section 2.1 and 2.2, it is desirable 193 for IGMP and MLD to have the following characteristics when used in 194 wireless and mobile networks: 196 o Adaptive to link conditions: wireless networks have various link 197 types, each with different bandwidth and performance features. IGMP 198 or MLD should be able to be adaptive to different link models and 199 link conditions to optimize its protocol operation. 201 o Minimal group join/leave latency: because mobility and handover may 202 cause a user to join and leave a multicast group frequently, fast 203 join and leave by the user helps to accelerate service activation and 204 to release unnecessary resources quickly to optimize resource 205 utilization. 207 o Robust to packet loss: the unreliable packet transmission due to 208 instable wireless link conditions and limited bandwidth, or long 209 distance transmission in mobile network put more strict robustness 210 requirement on delivery of IGMP and MLD protocol messages. 212 o Reducing packet exchange: wireless link resources are usually more 213 limited, precious, and congested compared to their wired counterpart. 214 This requires packet exchange be minimized without degrading protocol 215 performance. 217 o Packet burst avoidance: large number of packets generated in a 218 short time interval may have the tendency to deteriorate wireless 219 network conditions. IGMP and MLD should be optimized to reduce the 220 probability of packet burst. 222 3. IGMP/MLD Optimization for Wireless and Mobile Networks 224 This section introduces several optimizations for IGMP and MLD in 225 wireless or mobile environment. The aim is to meet the requirements 226 described in section 2.3. It should be noted that because an 227 enhancement in one direction might result in weakening effect in 228 another, balances should be taken cautiously to realize overall 229 performance elevation. 231 3.1. Switching Between Unicast and Multicast Queries 233 IGMP/MLD protocols use multicast Queries whose destinations are 234 multicast addresses and also allows use of unicast Query with unicast 235 destination to be sent only to one host. Unicast Query has the 236 advantage of not affecting other hosts on the same link, and is 237 desirable for wireless communication because a mobile terminal often 238 has limited battery power [RFC6636]. But if the number of valid 239 receivers is large, using unicast Query for each receiver is 240 inefficient because large number of Unicast Queries have to be 241 generated, in which situation normal multicast Query will be a good 242 choice because only one General Query is needed. If the number of 243 receivers to be queried is small, unicast Query is advantageous over 244 the multicast one. 246 More flexibly, the router can choose to switch between unicast and 247 multicast Queries according to the practical network conditions. For 248 example, if the receiver number is small, the router could send 249 unicast Queries respectively to each receiver, without arousing other 250 non-member terminal which is in dormant state. When the receiver 251 number reaches a predefined level, the router could change to use 252 multicast Queries. To have the knowledge of the number of the valid 253 receivers, a router is required to enable explicit tracking, and 254 because Group-Specific Query and Group-and-Source-Specific Query are 255 usually not used under explicit tracking [RFC6636], the switching 256 operation mostly applies to General Queries. 258 3.2. General Query Supplemented with Unicast Query 260 The Unicast Query can be used in assistance to General Query to 261 improve the robustness of solicited reports when General Query fails 262 to collect all of its valid members. It requires the explicit 263 tracking to be enabled and can be used when a router after sending a 264 periodical General Query collects successfully most of the valid 265 members' responses while losing some of which are still valid in its 266 database. This may be because these reports are not generated or 267 generated but lost for some unknown reasons. The router could choose 268 to unicast a Query respectively to each non-respondent valid receiver 269 to check whether they are still alive for the multicast reception, 270 without affecting the majority of receivers that have already 271 responded. Unicast Queries under this condition could be sent at the 272 end of the [Maximum Response Delay] after posting a General Query, 273 and be retransmitted for [Last Member Query Count] times, at an 274 interval of [Last Member Query Interval]. 276 3.3. Retransmission of Queries 278 In IGMP and MLD, apart from the continuously periodical transmission, 279 General Query is also transmitted during a router's startup. It is 280 transmitted for [Startup Query Count] times by [Startup Query 281 Interval]. There are some other cases where retransmission of 282 General Query is beneficial which are not covered by current IGMP and 283 MLD protocols as shown as following. 285 For example, a router which keeps track of all its active receivers, 286 if after sending a General Query, fails to get any response from the 287 receivers which are still valid in its membership database. This may 288 be because all the responses of the receivers happen to be lost, or 289 the sent Query does not arrive at the other side of the link to the 290 receivers. The router could compensate this situation by 291 retransmitting the General Query to solicit its active members. The 292 retransmission can also be applied to Group-Specific or Group-and- 293 Source-Specific Query on a router without explicit tracking 294 capability, when these Specific Queries cannot collect valid 295 response, to prevent missing valid members caused by lost Queries and 296 Reports. 298 The above compensating Queries could be sent [Last Member Query 299 Count] times, at the interval of [Last Member Query Interval], if the 300 router cannot get any feedback from the receivers. 302 3.4. General Query Suppression 304 In IGMP and MLD, the General Query is sent periodically and 305 continuously without any limitation. It helps soliciting the state 306 of current valid member but has to be processed by all hosts on the 307 link, whether they are valid multicast receivers or not. When there 308 is no receiver, the transmission of the General Query is a waste of 309 resources for both the host 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 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 any valid member joins a group, the 331 router could resume the original cycle of general Querying. Because 332 General Query influences all hosts on a link, suppressing it when it 333 is not needed is beneficial for both the link efficiency and terminal 334 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 latter of 342 which is determined by the router and is carried in Query messages to 343 inform the hosts for calculation of the response delay. A larger 344 value will lessen the burst better but will increase leave latency 345 (the time taken to cease the traffic flowing after the last member 346 requests the escaping of a channel). 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, longer Maximum Response Delay is recommended; if the expected 355 number of reporters is small and the link condition is good, smaller 356 Maximum response Delay should be set. 358 o If the link type is PTP, the Maximum Response Delay can be chosen 359 smaller, whereas if the link is PTMP or broadcast medium, the Maximum 360 Response Delay can be configured larger. 362 The Maximum Response Delay could be configured by the administrator 363 as mentioned above, or be calculated automatically by a software tool 364 implemented according to experiential model for different link modes. 365 The measures to determine the instant value of Maximum Response Delay 366 are out of this document's scope. 368 3.6. Triggering Reports and Queries Quickly During Handover 370 When a mobile terminal is moving from one network to another, if it 371 is receiving multicast content, its new access network should try to 372 deliver the content to the receiver without disruption or performance 373 deterioration. In order to implement smooth handover between 374 networks, the terminal's membership should be acquired as quickly as 375 possible by the new access network. 377 An access router could trigger a Query to a terminal as soon as it 378 detects the terminal's attaching on its link. This could be a 379 General Query if the number of the entering terminals is not small 380 (e.g when they are simultaneously in a moving train). 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) requires 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 Since the methods only involve the tuning of protocol behavior by 424 e.g. retransmission, changing delay parameter, or other compensating 425 operations, they do not introduce additional security weaknesses. 426 The security consderations described in [RFC2236], [RFC3376], 427 [RFC2710] and [RFC3810] can be reused. And to achieve some security 428 level in insecure wireless network, it is possible to take stronger 429 security procedures during IGMP/MLD message exchange, which are out 430 of the scope of this memo. 432 7. Acknowledgements 434 The authors would like to thank Behcet Sarikaya, Qin Wu, Stig Venaas, 435 Gorry Fairhurst, Thomas C. Schmidt, Marshall Eubanks, Suresh 436 Krishnan, J.William Atwood, WeeSan Lee, Imed Romdhani, Liu Yisong and 437 Wei Yong for their valuable comments and suggestions on this 438 document. 440 8. References 442 8.1. Normative References 444 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 445 Requirement Levels", BCP 14, RFC 2119, March 1997. 447 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 448 2", RFC 2236, November 1997. 450 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 451 Listener Discovery (MLD) for IPv6", RFC 2710, 452 October 1999. 454 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 455 Thyagarajan, "Internet Group Management Protocol, Version 456 3", RFC 3376, October 2002. 458 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 459 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 461 [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet 462 Group Management Protocol Version 3 (IGMPv3) and Multicast 463 Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, 464 February 2010. 466 [RFC6636] Asaeda, H., Liu, H., and Q. Wu, "Tuning the Behavior of 467 the Internet Group Management Protocol (IGMP) and 468 Multicast Listener Discovery (MLD) for Routers in Mobile 469 and Wireless Networks", RFC 6636, May 2012. 471 [refs.IGMPv1] 472 Deering, S., "Host Extensions for IP Multicasting", 473 RFC 1112, August 1989. 475 [refs.IGMPv2] 476 Fenner, W., "Internet Group Management Protocol, Version 477 2", RFC 2373, July 1997. 479 [refs.IGMPv3] 480 Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 481 Thyagarajan, "Internet Group Management Protocol, Version 482 3", RFC 3376, October 2002. 484 [refs.KEYWORDS] 485 Bradner, S., "Key words for use in RFCs to indicate 486 requirement levels", RFC 2119, March 1997. 488 [refs.LW] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet 489 Group Management Protocol Version 3 (IGMPv3) and Multicast 490 Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, 491 February 2010. 493 [refs.MLDv1] 494 Deering, S., Fenner, W., and B. Haberman, "Multicast 495 Listener Discovery (MLD) for IPv6", RFC 2710, 496 October 1999. 498 [refs.MLDv2] 499 Vida, R. and L. Costa, "Multicast Listener Discovery 500 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 502 [refs.PIM] 503 Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 504 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 505 Protocol Specification (Revised)", RFC 4601, August 2006. 507 [refs.Proxy] 508 Fenner, B., He, H., Haberman, B., and H. Sandick, 509 "Internet Group Management Protocol (IGMP) / Multicast 510 Listener Discovery (MLD)-Based Multicast Forwarding 511 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 513 8.2. Informative References 515 [refs.MIPv6] 516 Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 517 in IPv6", RFC 3775, June 2004. 519 [refs.Noel] 520 Jelger, C. and T. Noel, "Multicast for Mobile Hosts in IP 521 Networks: Progress and Challenges", IEEE Wireless 522 Comm. pp.58-64, October 2002. 524 [refs.PMIPv6] 525 Gundavelli, S, Ed., Leung, K., Devarapalli, V., Chowdhury, 526 K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, 527 August 2008. 529 [refs.explicit] 530 Asaeda, H., "IGMP/MLD-Based Explicit Membership Tracking 531 Function for Multicast Routers", 532 draft-ietf-pim-explicit-tracking-04.txt (work in 533 progress), January 2013. 535 Authors' Addresses 537 Hui Liu 539 Email: liu_helen@126.com 541 Mike McBride 542 Huawei Technologies 543 2330 Central Expressway 544 Santa Clara CA 95050 545 USA 547 Email: michael.mcbride@huawei.com 548 Hitoshi Asaeda 549 National Institute of Information and Communications Technology (NICT) 550 Network Architecture Laboratory 551 4-2-1 Nukui-Kitamachi 552 Koganei, Tokyo 184-8795 553 Japan 555 Email: asaeda@nict.go.jp