Multimob Working Group H. Liu Internet-Draft M. McBride Intended status: Informational Huawei Technologies Expires: September 3, 2012 March 2, 2012 IGMP/MLD Optimization in Wireless and Mobile Networks draft-liu-multimob-igmp-mld-wireless-mobile-00 Abstract This document proposes a variety of optimization approaches for IGMP and MLD in wireless and mobile networks. It aims to provide useful guideline to allow efficient multicast communication in these networks using IGMP or MLD protocols. Requirements Language 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 in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on September 3, 2012. Copyright Notice Copyright (c) 2012 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 Liu & McBride Expires September 3, 2012 [Page 1] Internet-Draft IGMP/MLD in wireless/mobile network March 2012 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Characteristics of Wireless and mobile Multicast . . . . . 3 2.2. Wireless Link Model . . . . . . . . . . . . . . . . . . . 4 2.3. Requirements on IGMP and MLD . . . . . . . . . . . . . . . 4 3. IGMP/MLD optimization for Wireless and Mobile Network . . . . 5 3.1. Minimizing Query Frequency by increasing intervals . . . . 6 3.2. Switching Between Unicast and Multicast Queries . . . . . 7 3.3. General Query Supplemented with Unicast Query . . . . . . 7 3.4. Retransmission of General Query . . . . . . . . . . . . . 8 3.5. General Query Supplemented with Unicast Query . . . . . . 8 3.6. Tuning Response Delay according to link type and status . 9 3.7. Triggering Reports and Queries quickly during handover . . 10 4. Applicability and interoperability considerations . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Liu & McBride Expires September 3, 2012 [Page 2] Internet-Draft IGMP/MLD in wireless/mobile network March 2012 1. Introduction With the wide deployment of various wireless access techniques and the tendency to support video applications on these networks, wireless and mobile multicast come to attract more and more interests from content and service providers, but still face great challenges when considering dynamic group membership management and constant update of delivery path introduced by node movement, and high probability of loss and congestion due to limited reliability and capacity of wireless links. Multicast network is generally constructed by IGMP and MLD group management protocol (respectively for IPv4 and IPv6 networks) to track valid receivers and by multicast routing protocol to build multicast delivery paths. This document focuses only on IGMP and MLD, which are used by a host to subscribe a multicast group and are most possibly to be exposed to wireless link to support terminal mobility. As IGMP and MLD were designed for fixed users using wired link, they do not necessarily work well for all kinds of wireless link types and mobile scenarios, thus should be enhanced to be adapted to these environment. This memo proposes a variety of optimizations for IGMP and MLD in wireless and mobile networks to improve network performance, with minimum changes on the protocol behavior while without introducing interoperability issues. These solutions can also be applied in wired network when efficiency or reliability is required. 2. Requirements 2.1. Characteristics of Wireless and mobile Multicast Several aspects should be considered when supporting IP multicast in wireless and mobile networks, including: O Limited link bandwidth: wireless link usually has limited bandwidth, and the situation will be made even worse if high volume video multicast data has to be carried. Also the bandwidth available in the upstream and downstream directions may be asymmetrical. O High loss rate: wireless link usually has packet loss ranging from 1% to 30% according to different links types and conditions. Also when packets have to travel between home and access networks (e.g. through tunnel), they are prone to loss if the two networks are distant from each other. O Frequent membership change: in fixed multicast, membership change Liu & McBride Expires September 3, 2012 [Page 3] Internet-Draft IGMP/MLD in wireless/mobile network March 2012 only happens when a user leaves or joins a group, while in mobile scenario membership may also change when a user changes its location. O Prone to performance degradation: the possible increased interaction of protocols across layers for mobility management, and the limitation of link capacity, may lead to network performance degradation and even to complete connection loss. O Increased Leave Latency: the leave latency in mobile multicast might be increased due to user movement, especially if the traffic has to be transmitted between access and home networks, or if there is a handshake between networks. 2.2. Wireless Link Model Wireless links can be categorized by their different transmission modes into three typical models: point-to-point (PTP), point-to- multipoint (PTMP), and broadcast link models. In PTP model, one link is dedicated for two communication facilities. For multicast transmission, each PTP link normally has only one receiver and the bandwidth is dedicated for that receiver. Such link model may be implemented by running PPP on the link or having separate VLAN assignment for each receiver. In mobile network, tunnel between entities of home and foreign networks should be recognized as a PTP link. PTMP is the model for multipoint transmission wherein there is one centralized transmitter and multiple distributed receivers. PTMP provides common downlink channels for all receivers and dedicated uplink channel for each receiver. Bandwidth downstream is shared by all receivers on the same link. Broadcast link can connect two or more nodes and supports broadcast transmission. It is quite similar to fixed Ethernet link model and its link resource is shared in both uplink and downlink directions. 2.3. Requirements on IGMP and MLD IGMP and MLD are usually run between mobile or wireless terminals and their first-hop access routers (i.e.home or foreign routers) to subscribe an IP multicast channel, and sometimes run between home router and access router (in PMIP case [RFC6224]) to proxy IGMP/MLD in mobile network the summarized IGMP/MLD reports from the latter to the former. Currently the version in-use includes IGMPv2 [RFC2236] and its IPv6 counterpart MLDv1 [RFC2710], IGMPv3 [RFC3376] and its IPv6 counterpart MLDv2 [RFC3810], and lightweight IGMPv3/MLDv2 [RFC5790]. All these versions have basic group management capability Liu & McBride Expires September 3, 2012 [Page 4] Internet-Draft IGMP/MLD in wireless/mobile network March 2012 required by a multicast subscription. The differences lie in that IGMPv2 and MLDv1 can only join and leave a non-source specific group, while IGMPv3 and MLDv2 can select including and excluding specific sources for their join and leave operation, and LW-IGMPv3/MLDv2 simplifies IGMPv3/MLDv2 procedures by discarding useless excluding- source function. Among these versions, (LW-) IGMPv3/MLDv2 has the capability of explicit track each host member. From the illustration given in section 2.1 and 2.2, it is desirable for IGMP and MLD to have the following characteristics when used in wireless and mobile networks: o Adaptive to link conditions: wireless network has various link types, each with different bandwidth and performance features. IGMP or MLD should be able to be adaptive to different link model and link conditions to optimize its protocol operation. o Minimal group Join/Leave latency: because mobility and handover may cause a user to join and leave a multicast group frequently, fast join and leave by the user helps to accelerate service activation and to release unnecessary resources quickly to optimize resource utilization. o Robust to packet loss: the unreliable packet transmission due to instable wireless link conditions and limited bandwidth, or long distance transmission in mobile network put more strict robustness requirement on delivery of IGMP and MLD protocol messages. o Reducing packet exchange: wireless link resources are usually more limited, precious, and congested compared to their wired counterpart. This requires packet exchange be minimized without degrading protocol performance. o Packet burst avoidance: large number of packets generated within a short time interval may have the tendency to deteriorate wireless network conditions. IGMP and MLD should be optimized if their protocol message generation has the potential of introducing packet burst. 3. IGMP/MLD optimization for Wireless and Mobile Network This section introduces several optimization methods for IGMP and MLD in wireless or mobile environment. The aim is to meet the requirements described in section 2.3. These measures could be applied between host and access routers in mobile or wireless network, and in mobile PMIPv6 [RFC6224] case, could also be used between access and home routers. It should be noted that because an Liu & McBride Expires September 3, 2012 [Page 5] Internet-Draft IGMP/MLD in wireless/mobile network March 2012 enhancement in one direction might result in weakening effect in another, balances should be taken cautiously to realize overall performance elevation. 3.1. Minimizing Query Frequency by increasing intervals In IGMP and MLD, Group-Specific Query and Group-and-Source-Specific Query are triggered on reception of a Leave message, and are sent for [Last Member Query Count] times with fixed [Last Member Query Interval], to learn whether there are valid members from an attached link. If a network is undergoing congestion, multiple transmissions of the Queries as above may further deteriorate the conditions. To avoid congestion or make remedy during congestion, these Queries can be slowed down when a router cannot collect successfully expected responses. The slowing down process of the Queries could be arranged in a prolonged time interval as described in [ADAPTIVE]. The slowdown process should be: a router after sending a Query, if acquires the expected responses from the receivers, refreshes its state database and optionally stop the querying retransmission process, or if after a time interval fails to get the expected report responses, resends a Query with an increased (e.g. double) interval. This process can be repeated, each time the retransmission is arranged in a progressively prolonged time interval, till the router receives the expected responses, or determines the receiver is unreachable and stops the sending of the Query. Query slowdown can be applied in the cases as listed in the following examples: O When Group-Specific Query and Group-and-Source-Specific Query are used to track other members but cannot get any response. O When all group members leave a group or move out of scope, the General Query sent by the router cannot solicit any response on a network, as illustrated in section 3.4. O When General Query is retransmitted due to possible loss or congestion deducing from no responses from valid members in the database, on the primes that explicit tracking is used. O When General Query is retransmitted by a router on startup but no response can be acquired. O When unicast Query is sent to query a particular valid receiver, from whom no response could be collected, as described in section 3.2 and 3.3. This requires explicit tracking to be enabled. Liu & McBride Expires September 3, 2012 [Page 6] Internet-Draft IGMP/MLD in wireless/mobile network March 2012 Query retransmission with incremental interval enables the router to reduce the total query-response times and consequently the packet count. The variable time interval and the termination condition of retransmission should be configurable and could be set according to actual network condition, which is out the scope of this document. 3.2. Switching Between Unicast and Multicast Queries IGMP/MLD protocols use multicast Queries whose destination addresses are multicast addresses and also allow use of unicast Query with unicast destination to be sent only for one destination. Unicast Query has the advantage of not affecting other hosts on the same link, and is desirable for wireless communication because a mobile terminal often has limited battery power. But if the number of valid receivers is large, using unicast Query for each receiver is inefficient because large number of Unicast Queries have to be generated, in which situation normal multicast Query will be a good choice because only one General Query is needed. If the number of receivers to be queried is small, unicast Query is advantageous over the multicast one. More flexibly, the router can choose to switch between unicast and multicast Query according to the practical network conditions. For example, if the receiver number is small, the router could send unicast Queries respectively to each receiver, without arousing other non-member host which is in the dormant state. When the receiver number reaches a predefined level, the router could change to use multicast Queries. To have the knowledge of the number of the valid receivers, a router is required to enable explicit tracking, and because Group-Specific Query and Group-and-Source-Specific Query are usually not used under explicit tracking, the switching only applies to General Queries. 3.3. General Query Supplemented with Unicast Query Unicast Query also can be used in assistance to General Query to improve the robustness of solicited reports when General Query fails to collect all of its valid members. It requires the explicit tracking to be enabled and can be used when a router after sending a periodical General Query collects successfully most of the valid members' responses while losing some of which are 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 for some unknown reasons. The router could choose to unicast a Query respectively to each non-respondent valid receiver to check whether they are still alive for the multicast reception, without affecting the majority of receivers that have already responded. Unicast Queries under this condition could be sent at the end of the Liu & McBride Expires September 3, 2012 [Page 7] Internet-Draft IGMP/MLD in wireless/mobile network March 2012 [Maximum Response Delay] after posting a General Query, and be retransmitted for [Last Member Query Count] times, at a constant interval, or at incremental interval as described in section 3.1. 3.4. Retransmission of General Query In IGMP and MLD, apart from the continuously periodical transmission, General Query is also transmitted during a router's startup. It is transmitted for [Startup Query Count] times by [Startup Query Interval]. There are some other cases where retransmission of General Query is beneficial which are not covered by current IGMP and MLD protocols as shown as following. For example, a router which keeps track of all its active receivers, if after sending a General Query, fails to get any response from the receivers which are still valid in its membership database. This may be because all these valid receivers have left the group silently or moved out of range, or all the responses of the receivers happen to be lost, or the sent Query does not arrive at the other side of the link to the receivers. The router could compensate this situation by retransmitting the General Query to solicit its active members. This compensating General Query could be sent several times, if the router cannot get any feedback from the receivers which are valid in the database. The repetition of the transmission could be in fixed interval, or in prolonged interval as described in section 3.1. The method can also be applied to router without explicit tracking enabled, in which case General Query is retransmitted if no valid response can be collected for a group or source-specific group which previously has valid reception state. 3.5. General Query Supplemented with Unicast Query In IGMP and MLD, General Query is sent periodically and continuously without any limitation. It helps soliciting the state of current valid member but has to be processed by all terminals on the link, whether they are valid multicast receivers or not. When there is no receiver, the transmission of the General Query is a waste of resources for both the terminals and the router. An IGMP/MLD router could suppress its transmission of General Query if it knows there is no valid multicast receiver on an interface, e.g. in the following cases: O When the last member reports its leave for a group. This could be judged by an explicit tracking router checking its membership database, or by a non-explicit-tracking router getting no response after sending Group-Specific Query or Group-and-Source-Specific Query Liu & McBride Expires September 3, 2012 [Page 8] Internet-Draft IGMP/MLD in wireless/mobile network March 2012 O When the only member on a PTP link reports its leaving O When a router after retransmitting General Queries on startup fails to get any response O When a router previously has valid members but fails to get any response after several rounds of General Queries. In these cases the router could make the decision that no member is on the interface and totally stop its transmission of periodical General Queries. If afterwards there is any valid member joins a group, the router could resume the original cycle of general Querying. Because General Query has influences on all terminals on a link, suppressing it when it is not needed is beneficial for both the link efficiency and terminal power saving. 3.6. Tuning Response Delay according to link type and status IGMP and MLD use delayed response to spread unsolicited Reports from different hosts to reduce possibility of packet burst. This is implemented by a host responding to a Query in a specific time randomly chosen between 0 and [Maximum Response Delay]. The value of [Maximum Response Delay] is determined by the router and is carried in Query messages to inform the hosts for the calculation. A larger value will lessen the burst better but will increase leave latency (the time between the last listener request escaping a channel and the traffic actually ceases flowing). In order to avoid message burst and reduce leave latency, the Response Delay may be dynamically calculated based on the expected number of responders, and link type and status, as shown in the following: O If the expected number of reporters is large and link condition is bad, the system administrator MUST choose the longer Maximum Response Delay; if the expected number of reporters is small and the link condition is good, smaller Maximum response Delay should be set. In this way, the IGMP/MLD packet burst can be reduced. o If the link type is PTP, the Maximum Response Delay can be chosen smaller, whereas if the link is PTMP or broadcast medium, the Maximum Response Delay can be configured larger. The Maximum Response Delay could be configured by the administrator as mentioned above, or be calculated automatically by a software tool implemented according to experiential model for different link modes. How to determine the instant value of Maximum Response Delay is out of this document's scope. Liu & McBride Expires September 3, 2012 [Page 9] Internet-Draft IGMP/MLD in wireless/mobile network March 2012 3.7. Triggering Reports and Queries quickly during handover When a mobile terminal is moving from one network to another, if it is receiving multicast content, its new access network should try to deliver the content to the receiver without disruption or performance deterioration. In order to implement smooth handover between networks, the terminal's membership should be acquired as quickly as possible by the new access network. The access router could trigger a Query to the terminal as soon as it detects a new terminal on its link. This could be a General Query if the number of the entering terminals is not small. Or this Query could also be a unicast Query for this incoming terminal to prevent unnecessary action of other terminals in the switching area. For the terminal, it could send a report immediately if it is currently in the multicast reception state, when it begins to connect the new network. This helps establishing more quickly the membership state and enable faster multicast stream injection, because with the active report the router does not need to wait for the query period to acquire the terminal's newest state. 4. Applicability and interoperability considerations Among the optimizations listed above, 'Switching between unicast and multicast Queries'(3.2) and 'General Query Supplemented with Unicast Query'(3.3) require a router to know beforehand the valid members connected through an interface, thus require explicit tracking capability. "Minimizing Query Frequency by increasing intervals" (3.1) is only meaningful when for the same network condition the retransmission count for a fixed interval is not small (more than the default value of 2). An IGMP/MLD implementation could choose any combination of the methods listed from 3.1 to 3.7 to optimize multicast communication on a specific wireless or mobile network. For example, an explicit-tracking IGMPv3 router, can switch to unicast General Query if the number of members on a link is small (3.3), can trigger unicast Query to a previously valid receiver if failing to get expected responses from it (3.3), can retransmit a General Query if after the previous one cannot collect reports from valid members (3.4), and can stop sending a General Query when the last member leaves the group (3.5), and etc. For interoperability, it is suggested if multiple multicast routers are connected to the same network for redundancy, each router are configured with the same optimization policy to synchronize the membership states among the routers.. Liu & McBride Expires September 3, 2012 [Page 10] Internet-Draft IGMP/MLD in wireless/mobile network March 2012 5. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 6. Security Considerations They will be described in the later version of this draft. 7. Acknowledgements The authors would like to thank Qin Wu, Stig Venaas, Gorry Fairhurst, Thomas C. Schmidt, Marshall Eubanks, Suresh Krishnan, J.William Atwood, WeeSan Lee, Imed Romdhani, Hitoshi Asaeda, Liu Yisong and Wei Yong for their valuable comments and suggestions on this document. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, February 2010. [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base Liu & McBride Expires September 3, 2012 [Page 11] Internet-Draft IGMP/MLD in wireless/mobile network March 2012 Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains", RFC 6224, April 2011. 8.2. Informative References [ADAPTIVE] Romdhani, I., Bettahar, H., and A. Bouabdallah, "Adaptive Multicast Membership Management for Mobile Multicast Receivers", IEEE , 2000. Authors' Addresses Hui Liu Huawei Technologies Building Q14, No.156, Beiqing Rd. Beijing 100095 China Email: helen.liu@huawei.com Mike McBride Huawei Technologies 2330 Central Expressway Santa Clara CA 95050 USA Email: michael.mcbride@huawei.com Liu & McBride Expires September 3, 2012 [Page 12]