Network working group H. Liu Internet Draft Huawei Technologies Co., Ltd. Category: Informational H. Asaeda Created: July 13, 2009 Keio Universitys Expires: January 2010 TM. Eubanks Iformata Communications Mobile and Wireless Multicast Requirements on IGMP/MLD Protocols draft-liu-multimob-igmp-mld-mobility-req-02 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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. 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) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Liu and etc. Expires January 13, 2010 [Page 1] Internet-Draft IGMP and MLD Requirements for Mobility July 2009 Abstract This document presents the requirements for IGMP/MLD protocols to allow the deployment of mobile multicast service. It is intended to provide useful guideline when adapting current IGMP/MLD protocols to support terminal mobility. 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]. Table of Contents 1. Introduction..................................................2 2. Problem Statement.............................................3 3. The Behavior of IGMP and MLD Protocols........................4 3.1. IGMP Version 1...........................................5 3.2. IGMP Version 2...........................................5 3.3. IGMP Version 3...........................................6 3.4. Multicast Listener Discovery Protocols...................6 3.5. Lightweight IGMPv3/MLDv2.................................6 4. Requirements for Wireless and Mobile Multicast................7 4.1. Functional Requirements for Mobile Multicast.............7 4.2. Requirements on Tuning IGMP/MLD Protocol Parameters......8 4.3. Requirements for Handover................................8 4.4. Requirements for Wireless Link Types.....................9 4.5. Requirements for Explicit Tracking......................10 5. Security Considerations......................................11 6. References...................................................11 6.1. Normative References....................................11 6.2. Informative Referencess.................................11 Authors' Addresses..............................................12 1. Introduction IP multicast efficiently distributes data to a number of receiver hosts in IP networks simultaneously thereby saving network and server resources. The receiver hosts use IGMP for IPv4 [2] and MLD for IPv6 [3] to receive or to stop receiving data via multicast (using join/leave or a subscribe/unsubscribe requests). The intermediate routers construct multicast tree between the source and receiver hosts with multicast routing protocols. Liu and Etc. Expires January 13, 2010 [Page 2] Internet-Draft IGMP and MLD Requirements for Mobility July 2009 IGMP and MLD protocols are originally designed to work on wired broadcast shared links (e.g. Ethernet) by taking into account the wired link characteristics. When they are used on a wireless link, it is necessary to consider how to make the protocols better fit the properties of the wireless link. In this document, the requirements for IGMP and MLD protocols that enable mobile multicast services via a wireless link are discussed. The wireless link type could be but should not be restricted to 3GPP, IEEE 802.11 and 802.16, which are or may be popularly adopted in providers' network IGMP or MLD protocol can work with any mobile protocols (e.g., MIPv6 [9], PMIPv6 [10], NEMO [11]) independently, if these protocols support multicast. However, context transfer or other procedures to provide seamless handover depend on the mobile protocols. Therefore, this document does not assume mobile protocols that mobile hosts use, and only protocol-independent considerations and requirements regarding how mobile protocols should work with IGMP/MLD for seamless handover are discussed. 2. Problem Statement A mobile host usually accesses to a network via a wireless link. When a mobile host wants to join or leave an IP multicast session, it sends IGMP/MLD messages for the request to its upstream equipment. The upstream equipment may be a wireless access router (in case of MIPv6), a mobile router (in case of NEMO), a gateway (in case of PMIPv6), or a switch or router that supporting IGMP/MLD Proxy. In the following part of this document, it is expressed as an "upstream router" or "multicast router". The upstream router should maintain the group membership states indicating which multicast sessions mobile hosts have joined and constructs the multicast tree towards the source with multicast routing protocol procedures. If upstream wireless routers or switches are wireless and do not maintain this group membership states, they will flood all multicast data received onto each wireless link, which is not an efficient use of wireless bandwidth resources. Thus IGMP and MLD protocols are necessary to be supported on the mobile and wireless hosts and their upstream routers. Apart from the above general wireless link characteristic, different wireless technique exhibits different features. For the purpose of generality, this memo does not concentrate on a specific wireless link layer protocol, but rather focus on the popular link model Liu and Etc. Expires January 13, 2010 [Page 3] Internet-Draft IGMP and MLD Requirements for Mobility July 2009 being abstracted from currently in-used wireless techniques, such as IEEE 802.11x, IEEE 802.16x, 3GPP,and etc. According to the properties of a wireless link, bandwidth usage and packet loss should be carefully considered. It is also necessary to take care of battery consumption of a mobile host. These conditions encourage the minimization of exchanged data packets and control messages including IGMP/MLD protocol messages if possible. On the other hand, IGMP and MLD are asymmetric and non-reliable protocols; multicast routers need solicited membership reports by periodical IGMP/MLD Queries, in order to be robust in front of host or link failures and packet loss. It is encouraged that host-and- router communication is effectively coordinated to support limited wireless or terminal resources. When a host receiving multicast data moves from an access link to another one, the host wants to continuously receive the multicast data without any packet loss and session interruption, and the network provider wants to minimize the amount of duplicated multicast traffic. This seemless handover is a necessary component of mobile multicast communication, which introduces additional requirements on IGMP/MLD protocols during handover. Precisely, the moving host's membership information should be transmitted to the new access link as quickly as possible. This procedure reduces the host's join latency. Or, if there is no member host on the access link after the host moves, then the upstream router should leave from the multicast session quickly as well. This contributes to releasing the unnecessary resources. All the above problems stated above together with others are to be discussed in this memo. In the following sections, we briefly introduce the IGMP/MLD protocols, analyze the protocol behavior and the requirements of wireless link characteristic and IP multicast mobile service, and discuss the possibility of the enhancement of the protocols if needed. The illustration below will consider both IPv4 and IPv6 networks. 3. The Behavior of IGMP and MLD Protocols A multicast receiving host uses IGMP protocols to join and leave a multicast group on an IPv4 network, and uses MLD protocols on an IPv6 network. Liu and Etc. Expires January 13, 2010 [Page 4] Internet-Draft IGMP and MLD Requirements for Mobility July 2009 3.1. IGMP Version 1 IGMP Version 1 [5] defines the basic operating model between a multicast receiving host and its upstream router to determine group membership. The router periodically sends Host Membership Queries to its attached network. A host sends a Host Membership Report to the router when it decides to join a group, or it responds to the Queries passively. The host does not send group leave message explicitly, but rather silently leaves the group by ignoring a Host Membership Query, which causes an undesirably long leave latency. IGMPv1 is an obsolete protocol; hence it is not recommended for mobile hosts to implement IGMPv1, whereas upstream routers may need to support IGMPv1 to keep compatibility with non-upgraded mobile hosts. 3.2. IGMP Version 2 IGMP Version 2 [6] has the optimizations that an IGMPv2 host can explicitly send a Leave Report when it decides to stop receiving multicast data. This enables faster leave from the multicast group. When a multicast router receives a leave message, it will generate a Group-Specific Query to verify whether there is other receiver for the same group on its network. IGMPv2 also supports the case when multiple multicast routers are connected to the same shared network. In this case, a single Querier is elected by ordering the IP addresses to take on the duty of sending Query packets. Several timers are defined in IGMPv2 and their values are configurable. Query Interval is the interval between General Queries sent by a router, which has influence on the total number of IGMPv2 messages on a link. Query Response Interval is the maximum response time of a report after a host receives the General Query. It will reduce the bursty traffic of the reports on a link. Startup Query Interval is the interval between the queries sent by the Querier in startup. Last Member Query Interval is the maximum response time used by Group-Specific Queries in response to leave from session. This value can be tuned to modify the leave latency of the network. IGMPv2 also introduces timer related counters to make the protocol function more robust. For example, it defines Robustness Variable to quantify the number of reports sent out to prevent packet loss. Last Member Query count is used to set the number of Group-Specific Queries sent before the router assumes there is no local member. Startup Query Count is the number of Queries issued on startup. Liu and Etc. Expires January 13, 2010 [Page 5] Internet-Draft IGMP and MLD Requirements for Mobility July 2009 These values can be tuned according to the expected packet loss on a link. 3.3. IGMP Version 3 IGMP Version 3 [2] introduces a big enhancement to the previous two versions. It defines INCLUDE and EXCLUDE filter modes on both the host and router side. With these filter modes, a host can specify the desired or undesired source address(es) except for multicast address(es) in IGMP report messages. IGMPv3 router uses filter mode to process the group record properly. The router also maintains a group-timer to indicate the filter mode switch over and a source-timer to time each valid source. A new type of Source-and-Group-Specific Query is utilized to verify there are no receivers desiring to receive traffic from listed sources for a particular group, which has been requested to no longer be forwarded. Another modification is that IGMPv3 does not adopt the report suppression mechanism. Without suppression, the number of report messages may increase greatly on a link. IGMPv3 solves this problem by merging reports or queries into a combined packet. An advantage of eliminating report suppression is that it provides the possibility for the router to keep track of host membership status on a link. This Explicit Tracking consumes memory on the router, but provides feasibility to manage end users on a per-user basis and implements fast leave function. 3.4. Multicast Listener Discovery Protocols MLDv1 and MLDv2 are respectively derived from IGMPv2 and IGMPv3 to be applied for IPv6 networks. The important difference between MLD and IGMP is that MLD is a sub-protocol of ICMPv6 and its message types are a subset of ICMPv6 messages. For MLDv1, parts of the message types are renamed to distinguish from those of IGMPv2. 3.5. Lightweight IGMPv3/MLDv2 IGMPv3 and MLDv2 enable the support of Source-Specific Multicast (SSM) communication [8] by indicating desired sources in the INCLUDE Group Record. Its usage of excluding undesired sources by an EXCLUDE filter mode operation has little practical prototype use and no desired use case. Moreover, when a host requests to join or leave session whose operation changes INCLUDE filter mode to EXCLUDE Liu and Etc. Expires January 13, 2010 [Page 6] Internet-Draft IGMP and MLD Requirements for Mobility July 2009 filter mode or vise versa, both the host and the upstream router will suffer from complex state transition and scalability problems. In [4], simplified version protocols of IGMPv3/MLDv2 are defined to keep the INCLUDE source-filtering characteristics to support SSM communication and remove the EXCLUDE filter mode operation. With the reduced number of report types and and without the filter-mode related processing,the host-side kernel implementation and especially the router's operation are greatly simplified, and less states need to be stored by lightweight router compared to their full IGMPv3/MLDv2 counterpart. These improvements are especially desirable for multicast mobility, as wireless devices typically have limited storage and CPU processing capabilities. 4. Requirements for Wireless and Mobile Multicast 4.1. Functional Requirements for Mobile Multicast Any-Source Multicast (ASM) is a traditional multicast communication model in which receivers requests all data from a multicast address, which is denoted with (*,G). A host joining a (*,G) session will receive data from all the sources sending to the specified multicast address. On the other hand, in the SSM communication, a host specifies both source and multicast addresses and receives the traffic from the specified source(s). The subscribed source- specific multicast session is denoted by an (S,G) and called a channel. All the versions of IGMP/MLD support the ASM communication. It is not recommended to use IGMPv1 in mobile communications since it does not have a robust mechanism to retransmit report messages, does not provide fast leave, and does not support SSM, as described in Section 2. IGMPv2 and MLDv1 are possible to be used in mobile communications, but they do not support SSM subscription. To enable the SSM communication, a mobile host must use IGMPv3/MLDv2 or LW-IGMPv3/LW-MLDv2. As described in [4], there is no functional difference to subscribe (S,G) channels between the full versions of IGMPv3/MLDv2 and the lightweight version protocols. The lightweight version protocols have the advantage of simpler processing. IGMP/MLD protocols (except IGMPv1) protocols themselves implement some fast join and fast leave functions. When a host joins a multicast session, it sends unsolicited join report to its upstream router immediately. The Startup Query Interval has been set to 1/4 of the General Query value to enable the faster join at startup. Liu and Etc. Expires January 13, 2010 [Page 7] Internet-Draft IGMP and MLD Requirements for Mobility July 2009 When the host ceases from listening a session, it sends a request to leave the session immediately. The Group-Specific or Source-and- Group-Specific Queries are triggered when an IGMP/MLD router knows that the reception for a group or a source-specific group has been terminated. This helps the router acquire the multicast membership information as fast as possible when all the members as a whole leave a group. The time to complete leaving from a session is referred to as leave latency. Lower leave latency (i.e. fast leave) has the advantage of quickly releasing the network resources. 4.2. Requirements on Tuning IGMP/MLD Protocol Parameters Within each protocol's scope, the number of transmitted packets on a wireless link could be further decreased by tuning timer values. For example, Query Interval can be set to a larger value to reduce the packet quantity. The Query Response interval could be widened to avoid the burst of messages. On the other hand, to cover the possibility of a State-Change Report being missed by one or more multicast routers, a host transmits the same State-Change Report [Robustness Variable] times in all [2][3]. However, this manner does not only guarantee that the State-Change Report is reached to the routers, but also increases the number or amount of State-Change Report messages on a wireless link. It is required to tune these values with the good balance of protocol robustness and the amount of traffic. As well, various IGMP/MLD timers should be configurable. If non- default settings are used, they MUST be consistent among all routers on a single network. 4.3. Requirements for Handover [12] categorized the diversified mobile IP schemes by their group subscription manner principally as home subscription and remote subscription. These two different subscription has important influences on the handover behaviour. Since different mobile and handover protocols may need different parameters and different optimizations, this document describes the possible scenarios with examples in MIPv6 [9] but only discussed the possible requirements related to the group-subscription related behavior. In home subscription (also referred to tunneled method), the IGMP/MLD message should be encapsulated and tunneled to the home network. The multicast router (e.g., Home Agent) on home network will be responsible for joining and pruning a multicast tree. When Liu and Etc. Expires January 13, 2010 [Page 8] Internet-Draft IGMP and MLD Requirements for Mobility July 2009 a mobile host moves to a new foreign network, it does not need to re-join the multicast group. In the remote subscription approach (also referred to optimal multicast routing), a mobile host joins the group via a local multicast router on the foreign network. The router intercepts the host's report message and joins or prunes the multicast tree on the foreign network. After handover to another foreign network, the host needs to resend new reports to new access routers and the latters will construct the new multicast tree on the new network. If the old multicast branches have been torn down before the new branches being constructed, the host will suffer from packets loss during the handover. To prevent packet loss, a make-before-break mechanism SHOULD be provided. It requires a mobile host to join the group on the new network as soon as possible once it decides to switch to the new network. The host keeps the reception of the "old" multicast data until the traffic from new branches arrives. Then the host begins issuing leave reports to the previous attached multicast router. The possibility of packet loss can be reduced by predicting the movement of a mobile node during handover. The handover can be initiated either by the mobile host or by the network. In the mobile-initiated handover, the host acquires the handover information quickly and can send early reports. In the network- initiated handover, the network entity indicates the possible handover situation and the mobile host does not invoke any process. It may be possible that IGMP and MLD could be extended to carry the handover indication from a previous router to a new router to facilitate the fast join and fast leave. Since IGMP/MLD protocol or message extension may require additional operational costs or interoperability problems, it must be carefully defined. IGMP/MLD hosts and routers can adjust their timer and counter values to make faster join/leave during handover, as described in Section 4.2. The adjustment is carried out by the application according to the actual wireless situations and policies of the management. 4.4. Requirements for Wireless Link Types Wireless access technique could be categorized to three different types - shared, point-to-point (PTP), and point-to-multipoint (PTMP) links. The shared link (e.g.IEEE802.11) resembles Ethernet that the end-users share the same wireless media. IGMP/MLD should be Liu and Etc. Expires January 13, 2010 [Page 9] Internet-Draft IGMP and MLD Requirements for Mobility July 2009 generally applicable because they are originally designed for the shared Ethernet. For PTP link (e.g.3G GSM, IEEE802.16), different links are separated physically or logically from each other. The standard use of IGMP and MLD requires the multicast router to maintain a separate interface state for each link. It will be inefficient if the number of the receiver becomes large. Considering there is only one receiving host on each link, the operation of IGMP/MLD relating to multiple receivers per interface should be taken out. For example, Host Suppression and Delaying Response are unnecessary. Instead the mobile could respond the reports immediately, which helps implementing faster join and leave capability. Besides, when a host requests its leave from the group, the successive Group-Specific Query or Group-and-Source-Specific Query to inquire other possible receivers is not needed. Finally, the periodic General Query which is sent separately to each mobile host, is unnecessary to be sent to all the links but rather only to the hosts which have made the group join and have reception state on the router. This is desirable for the battery saving for the mobile terminal not involved in the multicast reception will not be frequently awakened when in the sleeping mode. Wireless PTMP links (e.g.3GPP MBMS, and IEEE 802.16) is point-to- multipoint (or shared) in down link direction, but point-to-point in up link direction. The IGMP/MLD protocols should present both shared media and point-to-point media features. Host Suppression and Delaying Response should not be adopted. Group-Specific Query and Group-and-Source-Specific Query triggered by group leave are also unnecessary. And General Query should be multicast to the shared down link, which is the same as the shared link model but different from the PTP link. 4.5. Requirements for Explicit Tracking Since the full and lightweight IGMPv3 and MLDv2 protocols disable a report suppression mechanism (described in Section 3.3), multicast routers working with these protocols can choose to implement explicit tracking of mobile hosts. The explicit tracking enables the router to learn the reception state of each receiver, but at the meantime consumes substantial memory resources on the router. The advantage of explicit tracking is that it provides better manageability of mobile receivers. It is unnecessary to issue Group-Specific queries and Source-Specific Queries to stop receiving on subnets whose router keeps track of group and source receivers. Liu and Etc. Expires January 13, 2010 [Page 10] Internet-Draft IGMP and MLD Requirements for Mobility July 2009 5. Security Considerations Apart from the security issue of IGMP/MLD, additional requirements should be considered for the features of the wireless link. They will be described in the later version of this draft. 6. References 6.1. Normative References [1] Bradner, S., "Key words for use in RFCs to indicate requirement levels", RFC 2119, March 1997. [2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [3] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2(MLDv2) for IPv6", RFC 3810, June 2004. [4] Liu, H., Cao, W., and H. Asaeda, "Lightweight IGMPv3 and MLDv2 Protocols", draft-ietf-mboned-lightweight-igmpv3-mldv2-04.txt (work in progress), September 2008. [5] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, August 1989. [6] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997. [7] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [8] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006. 6.2. Informative Referencess [9] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [10] Gundavelli, Ed., S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. Liu and Etc. Expires January 13, 2010 [Page 11] Internet-Draft IGMP and MLD Requirements for Mobility July 2009 [11] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [12] Romdhani, I., Kellil, M., and H. Lach, "IP Mobile Multicast: Challenges and Solutions", IEEE Comm. Surveys 6(1), 2004. Authors' Addresses 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 Hitoshi Asaeda Keio University Graduate School of Media and Governance 5322 Endo Fujisawa, Kanagawa 252-8520 Japan Email: asaeda@wide.ad.jp URI: http://www.sfc.wide.ad.jp/~asaeda/ T.M. Eubanks Iformata Communications 130 W. Second Street Dayton, Ohio 45402 USA Phone: +1 703 501 4376 Email: marshall.eubanks@iformata.com URI: http://www.iformata.com/ Liu and Etc. Expires January 13, 2010 [Page 12]