Network working group Q. Wu Internet Draft H. Liu Category: Informational Huawei Created: March 22, 2010 Expires: September 2010 Proposal for Tuning IGMPv3/MLDv2 Protocol Behavior in Wireless and Mobile networks draft-wu-multimob-igmp-mld-tuning-00 Abstract This document proposes a variety of optimization approaches for tuning IGMPv3 and MLDv2 in wireless and mobile networks. It intends to provide useful guideline when deploy current IGMP/MLD protocols to support multicast listener mobility in wireless communication. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Wu,et al Expires September 22, 2010 [Page 1] Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior March 2010 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on August 15, 2009. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction..................................................3 2. Impact of wireless and mobility on IGMP/MLD...................3 2.1. Requirement for characteristics of wireless on IGMP/MLD..3 2.2. Evaluation of current versions of IGMP and MLD...........5 3. IGMP/MLD tuning optimization for Wireless or Mobile Network...5 3.1. Optimization Consideration for Report Messages...........6 3.2. Optimization Considerations for Query Messages...........6 3.2.1. Disable Group Specific Queries on leave.............7 3.2.2. Limiting the scope of periodical Queries............7 3.2.3. Conditional Retransmission of Queries on loss.......7 3.2.4. Unicast Query for the lost solicit report...........8 3.2.5. Query Retransmission in incremental interval........8 3.3. Optimization Considerations for Link Type................8 4. Security Considerations.......................................9 5. Acknowledgement...............................................9 6. References...................................................10 6.1. Normative References....................................10 6.2. Informative Referencess.................................10 Authors' Addresses..............................................11 Wu,et al Expires September 22, 2010 [Page 2] Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior March 2010 1. Introduction With the emerging techniques for different wireless networks, IP multicast sees their potentiality to be deployed to support wireless or mobile video service, and also faces great challenges for its efficiency and reliability in the wireless network, e.g. with possibly higher packet loss rate and limited frequency and bandwidth, more prone to congestion, and frequent joining or leaving multicast group due to handover and fast channel change. However as described in [RFC1112], the current versions of IGMP and MLD are only designed for fixed Ethernet model. They are not specified for other type of network like wireless link types. Therefore IGMP/MLD protocol should be enhanced or tuned to adapt to wireless environment to meet the reliability and efficiency requirements in the scenarios described in [REQUIRE]. This memo proposes a variety of optimization approaches for tuning IGMP/MLD protocols in wireless or mobile communication environment. It aims to make the minimum tuning without introducing obvious changes on the protocol behavior. These solutions can also be used in wired network when efficiency and reliability are required. They are discussed in detail in Section 3. 2. Impact of wireless and mobility on IGMP/MLD This section analyzes the impact of wireless and mobility on IGMP/MLD protocols. Also the current versions of IGMP and MLD are evaluated. 2.1. Requirement for characteristics of wireless on IGMP/MLD As mentioned in the section 1, IGMP/MLD faces great challenges for its efficiency and reliability in the wireless network. Due to this impact of wireless and mobility on IGMP/MLD, IGMP and MLD should have the following characteristics when used in wireless and mobile networks [REQUIRE]: o ASM and SSM subscription: SSM [RFC4607]mode is different from ASM for it allows only sources specific multicast delivery. Comparing with ASM mode, it is more secure and applicable to broadcast video service, and must be supported together with SSM mode in practical multicast network. Wu,et al Expires September 22, 2010 [Page 3] Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior March 2010 o Fast Join and Leave: Fast join and leave of a subscriber helps to improve the user's experience during channel join and channel zapping. Fast leave also facilitates releasing of unused network resources quickly. Besides, mobility and handover may cause a user to join and leave a multicast group frequently, which also require fast join and leave to accelerate service activation and to optimize resource usages. o Explicit Tracking: Tracking each member by the router enables a multicast router to explicitly keep track the membership of all multicast hosts in the access network. And because the router has record of each user in its state database, it is possible to simplify the Query mechanism by reducing both the unnecessary Queries and reports generated on a network. o Robustness to packet loss: Wireless link has the characteristic that packet transmission is unreliable due to instable link conditions. For mobile IP network, packets sometimes have to travel between home network and foreign network and have the possibility of being lost due to long distance transmission. These network scenarios have more strict robustness requirement on delivery of IGMP and MLD protocol messages. o Minimum packet transmission: Wireless link resources are usually more precious and limited compared to their wired counterpart. Minimizing packet exchange without degrading general protocol performance should also be emphasized to improve efficiency and increase network capacity. o Avoiding packet burst: Large number of packets generated within a short time interval may have the tendency to deteriorate wireless network conditions. IGMP and MLD when using in wireless and mobile networks should be optimized if their protocol message generation has the potential of introducing packet burst. o Adaptive to different link mode: IGMP and MLD are originally designed for wired Ethernet link and some of their processing are only applicable to shared link model. Wireless and mobile network link type is versatile, including shared, point-to-point, point-to- multipoint, and tunnel interface. Because different link model has different features, IGMP/MLD protocol behavior should be tuned to adapt to different link model. Wu,et al Expires September 22, 2010 [Page 4] Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior March 2010 2.2. Evaluation of current versions of IGMP and MLD IGMPv2 [RFC2236] and MLDv1 [RFC2710] only support ASM communication mode. They do not support SSM subscription and explicit tracking, which limit their widespread deployment in practical multicast network. IGMPv3 [RFC3376] and MLDv2 [RFC3810] and their lightweight version LW-IGMPv3/LW-MLDv2 [RFC5760] support all the features of ASM and SSM communication, and of explicit tracking. They are much better to be candidates for wireless and mobile networks than their previous versions and are the basis of the optimization discussed in this document. IGMPv3/MLDv2 join and leave Reports are sent unsolicitedly when a host intends to join or leave a group. They are closest to user's experience and must be guaranteed to improve service performance and to optimize resource use. Current IGMPv3 and MLDv2 provide the reliability for these messages by simple retransmission, which is not adequate from both the robustness and efficiency aspects[ROBUST]. They are suggested to be enhanced by acknowledgement-retransmission in [IGMP-ACK]. IGMPv3 and MLDv2 do not adopt host suppression mechanism. Their report count in response to a Query is not small, if the number of active receivers on the network is large. Even though the protocols enable the reports on an interface to be merged, further optimizations are still required to improve the efficiency and to reduce bandwidth occupation. To meet the requirements listed in section 2.1, the protocol message of IGMPv3/MLDv2, including the various Queries and Reports, together with their behavior, need to be regulated to adapt to wireless and mobile scenarios. Because an enhancement in one direction might introduce side effects in another one, balances should be taken carefully to avoid defects and improve protocol performance as a whole, as illustrated in section 3. 3. IGMP/MLD tuning optimization for Wireless or Mobile Network As mentioned in section 2, IGMPv3/MLDv2 or LW-IGMPv3/MLDv2 are recommended to be used as the basis for optimization of IGMP/MLD to adapt to wireless and mobile networks. In this section, taking these characteristics requirement into account, we will discuss several optimization approaches for tuning of IGMP and MLD in the wireless environment. The optimizations try to minimize the packet transmission for both the Reports and Queries, and at the meanwhile take the factor of improving reliability into account, with minimum Wu,et al Expires September 22, 2010 [Page 5] Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior March 2010 cost. The different link types are also considered when making the regulations. 3.1. Optimization Consideration for Report Messages Unsolicited reports are generated when hosts' interface state changes, they are sent actively when a user intends to join or leave a group or a source-group. However in some cases, the unsolicited reports are prone to loss due to network conditions degradation or long distance travel. Even the report can be retransmitted for [Robust Variable] times, the packet sent by the host is received by the router can not be guaranteed. Furthermore, Excessive Packet retransmission is the waste of resource. These issue can be addressed by acknowledge-retransmission described in [IGMP-ACK] for an unsolicited IGMPv3/MLDv2 Report. A host after sending an unsolicited report starts a retransmission timer and waits for the acknowledgement (ACK or multicast data) from the router. Upon receiving ACK or multicast data, the host stops the timer and retransmission. If the acknowledgement is not received when the timer expires, another report is retransmitted. A parameter should also be used to limit the maximum retransmission times for the report. Solicited reports are generated in response to Queries and are used to refresh the state database of the host on the router. They are suggested not to be acknowledged in order not to introduce too many report packets on the network, and they are not acknowledged also because the Query-Response to-and-fro itself implies an acknowledgement to some degree. If in some cases a host's solicited report is lost due to unstable transmission condition, there is still some remedy that can tackle this issue, as described in section 3.2.5. 3.2. Optimization Considerations for Query Messages IGMPv3 and MLDv2 have three kinds of Queries: General Query periodically sent to all multicast receivers, Group Specific Query sent when a receiver leaves a (*,G) group, and Source-and-Group Specific Query sent when a receiver leaves an (S,G) group. These Queries have different functional scope. They are used to fetch and refresh the downstream membership information by being responded by solicited reports. This section lists the possible optimization methods for Query messages. The solutions are not intended to be adopted altogether or simultaneously, but can be taken selectively according to the scale and conditions of the operating network. Wu,et al Expires September 22, 2010 [Page 6] Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior March 2010 3.2.1. Disable Group Specific Queries on leave If explicit tracking is used, the router is able to keep states for all active members in reception. The Group Specific and Source-and- Group Specific Queries, which are sent to query other members when a member leaves, are unnecessary because the router knows who are active on the interface. It is possible that when explicit tracking is used, only periodical Query is used. Disable of Group and Source-Group specific Queries in case a member leaves a group will reduce both the number of Query and the number of Report exchanged on the network, which helps to minimize packet number and packet burst when explicit tracking is enabled. 3.2.2. Limiting the scope of periodical Queries General Query is sent by a router periodically to all multicast receivers belonging to all groups and all source-groups and will probably result in burst response and link congestion if the receiver number on the link is large, even if Delay response is used. Therefore large number of reports within a specified time interval should be avoided if the number of the receiver on the link is large. A router can tune the scope of its periodical Queries according to the network conditions and user scale. For example, if the receiver number is small, the periodical General Queries for all multicast receivers is enough. If the number of the multicast receiver on a link is large, the router could choose to periodically send Group Queries to a (*,G) group in different time interval or send Source- Group Specific Queries to an (S,G) group in different time interval. In this case the router tunes its behavior by sending these two Queries periodically instead of triggering them when a member reports its leave. Using periodical Group Specific Queries or Source-Group Specific Queries sent in different time interval has the advantages of avoiding packet bursts and the response report from unrelated group when the receiver number is large. 3.2.3. Conditional Retransmission of Queries on loss A router which keeps track of all its active receivers, if after sending a Query, fails to get any response from any receiver, it could derive that its just-sent Query might have been lost before reaching other end of the link. The router could choose to compensate this situation by sending another Query to solicit its active members. Optionally, the router could resend several Queries in incremental interval as described in section 3.2.5 Wu,et al Expires September 22, 2010 [Page 7] Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior March 2010 3.2.4. Unicast Query for the lost solicit report Unicast Query mechanism is first suggested in [OPTIMIZ] to benefit the battery power consumption on mobile terminals. It is used here to improve the robustness of solicited reports. A router after sending a periodical Query collects successfully all the members' report responses except for one or two which are currently still valid in its database. This may be because the non-respondent ones silently leave the network without any notification, or because their reports are lost due to some unknown reason. The router in this case could choose to unicast a Query respectively to each non- respondent receiver to check whether they are still alive for the multicast reception, without affecting the majority of receivers that have already responded. Optionally, unicast Queries could be resent in incremental interval, as described in section 3.2.5. 3.2.5. Query Retransmission in incremental interval Query Retransmission [ADAPTIVE] can be slowed down when a router can not collect successfully all the members' report responses and network congestion is going to happen. It basis behavior is: the router after sending a Query, if acquires the response from the receiver, refreshes its state database and stop the querying retransmission process, or if after a time interval fails to get the report response, resends a Query in an increasing (e.g. double) interval. This process can be repeated several times, each time the retransmission is arranged in a prolonged time interval, till the router receives the response, or determines the receiver is unreachable and then stops the sending of the Query ultimately. This query retransmission in incremental interval processing enables the router to reduce the packet retransmission in the same time period comparing with unconditional retransmission (i.e. retransmission for multiple times with fixed interval). It is suggested be used to improve the robustness of the solicited report and of the Query as illustrated in section 3.2.3 and 3.2.4. The variable time interval and the termination condition should be configurable and could be set according to actual network arrangement. 3.3. Optimization Considerations for Link Type Wireless access link is characterized as three types as described in [REQUIRE]: shared, Point-to-Point (PTP) and point-to-multipoint (PTMP). Shared network resembles Ethernet as its link is shared among all end users. For PTP link, the communication channel Wu,et al Expires September 22, 2010 [Page 8] Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior March 2010 between users and first-hop routers are dedicated in both uplink (i.e. from the user to the router) and downlink direction. PTMP link represents the link model where the uplink is dedicated while the downlink is shared. For shared wireless networks, the basic mechanism of IGMPv3 and MLDv2 should be applicable, ideally with some efficiency and robustness enhancement when needed. For PTP or PTMP links, some characteristics of IGMP and MLD which are specific for shared network should not be reused if they have additional processing overhead and link burden. For example, Delay Response which is used to prevent bursting of solicited reports, should not be required in PTP and PTMP link, because there is only one receiver reported to the router on each uplink. Without Delayed Response, the report could be responded to the router immediately, and it is faster to implement robust enhancement for a solicited Report (see section 3.2.3) and for a Query (see section 3.2.4), because it'll take less time for the router to make collection of the reports. For the same reason, Group specific Query and Source-and-Group Specific Query, which are used to query other valid members, are not necessary for PTP and PTMP link. Finally, for PTP links, periodical General Query, which is sent separately to each interface, is unnecessary to be sent to all the interfaces but rather only to the hosts which have made the group join and have reception state on the router. This will not only reduce the necessary Queries, but also be desirable for the battery saving for the mobile terminal not involved in the multicast reception for not being frequently awakened when in the sleeping mode. 4. Security Considerations They will be described in the later version of this draft. 5. Acknowledgement The authors would like to thank Liu Yisong and Wei Yong for their valuable comments on the optimization methods. Wu,et al Expires September 22, 2010 [Page 9] Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior March 2010 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to indicate requirement levels", RFC 2119, March 1997. [RFC1112] Deering, S. "Host Extensions for IP Multicasting", RFC1112, August 1989. [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997. [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2(MLDv2) for IPv6", RFC 3810, June 2004. [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006. [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight IGMPv3 and MLDv2 Protocols", RFC5790, February 2010. 6.2. Informative Referencess [REQUIRE] H. Liu, Q. Wu, H. Asaeda and TM. Eubanks, "Mobile and Wireless Multicast Requirements on IGMP/MLD Protocols", draft-liu- multimob-igmp-mld-mobility-req-03.txt, March 2010. [ROBUST] A. Sen Mazumder, "Facilitating Robust Multicast Group Management", NOSSDAV'05, June 13-14, 2005, Stevenson, Washington, USA. [IGMP-ACK] H. Liu, Q, Wu, "Reliable IGMP and MLD Protocols in Wireless Environment", draft-liu-multimob-reliable-igmp-mld-00.txt, February 2010. [OPTIMIZ] H. Asaeda, "Tuning IGMPv3/MLDv2 Protocol Behavior in Wireless and Mobile networks", draft-asaeda-multimob-igmp-mld- optimization-02, work in progress, March 2010. Wu,et al Expires September 22, 2010 [Page 10] Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior March 2010 [ADAPTIVE] I. Romdhani, J. Munoz, H. Bettahar, and A. Bouabdallah, "Adaptive Multicast Membership Management for Mobile Multicast Receivers", IEEE, 2006. Authors' Addresses Qin Wu Huawei Technologies Co., Ltd. Site B, Floor 12, Huihong Mansion,No.91 Baixia Rd. Nanjing, Jiangsu 21001 China Phone: +86-25-84565892 EMail: sunseawq@huawei.com Hui Liu Huawei Technologies Co., Ltd. Huawei Bld., No.3 Xinxi Rd. Shang-Di Information Industry Base Hai-Dian Distinct, Beijing 100085 China EMail: Liuhui47967@huawei.com Wu,et al Expires September 22, 2010 [Page 11]