MULTIMOB Group H. Liu Internet-Draft Huawei Technologies Co., Ltd. Expires: April 16, 2009 H. Asaeda Keio University TM. Eubanks Iformata Communications October 13, 2008 Mobile Multicast Requirements on IGMP/MLD Protocols draft-liu-multimob-igmp-mld-mobility-req-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 April 16, 2009. Liu, et al. Expires April 16, 2009 [Page 1] Internet-Draft IGMP and MLD Requirements for Mobility October 2008 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. Liu, et al. Expires April 16, 2009 [Page 2] Internet-Draft IGMP and MLD Requirements for Mobility October 2008 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 [1]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 3. The Behavior of IGMP and MLD Protocols . . . . . . . . . . . . 7 3.1. IGMP Version 1 . . . . . . . . . . . . . . . . . . . . . . 7 3.2. IGMP Version 2 . . . . . . . . . . . . . . . . . . . . . . 7 3.3. IGMP Version 3 . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Multicast Listener Discovery Protocols . . . . . . . . . . 9 3.5. Lightweight IGMPv3/MLDv2 . . . . . . . . . . . . . . . . . 9 4. Requirements for IGMP/MLD to Support Mobile Multicast . . . . 10 4.1. Functional Requirements for Mobile Multicast . . . . . . . 10 4.2. Requirements on Tuning IGMP/MLD Protocol Parameters . . . 10 4.3. Requirements for Handover . . . . . . . . . . . . . . . . 11 4.4. Requirements for Point-To-Point Link . . . . . . . . . . . 12 4.5. Requirements for Explicit Tracking . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Normative References . . . . . . . . . . . . . . . . . . . 14 6.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Liu, et al. Expires April 16, 2009 [Page 3] Internet-Draft IGMP and MLD Requirements for Mobility October 2008 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. IGMP and MLD protocols work on broadcast shared links and point-to- point links. These protocols can also work on a wireless link. However, it is necessary to consider how to make a router and mobile hosts using IGMP and MLD protocols better fit the properties of a wireless link. In this document, the requirements for IGMP and MLD protocols that enable mobile multicast services via a wireless link are discussed. This document mainly focuses on IEEE 802.11 and 802.16 as the target wireless link to adapt the requirements for the general use, whereas 3GPP or 3GPP2 might be the additional target in the revised version of this document. Receiver mobility is the target of this document, because it has more promising application scenarios and exhibits less deployment complexity. In addition, in IP multicast the IGMP/MLD protocols describe the interaction between multicast receivers and their first hop routers, sources do not require IGMP/MLD support unless they are also receivers, and so there is not expected to be any IGMP/MLD requirements for multicast source or network mobility. 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. Liu, et al. Expires April 16, 2009 [Page 4] Internet-Draft IGMP and MLD Requirements for Mobility October 2008 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 cast 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 all group membership states indicating which multicast sessions mobile hosts have joined on a wireless LAN. In many cases, current upstream wireless routers and switches do not maintain this information and flood all multicasts received onto each wireless LAN, which is not an efficient use of wireless bandwidth. 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 access link, 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. In the following sections of this document, we briefly introduce the IGMP/MLD protocols, analyze the protocol behavior and the requirements of IP multicast mobile service, and discuss the Liu, et al. Expires April 16, 2009 [Page 5] Internet-Draft IGMP and MLD Requirements for Mobility October 2008 possibility of the modification or extension of the protocols if needed. The illustration below will consider both IPv4 and IPv6 networks. Liu, et al. Expires April 16, 2009 [Page 6] Internet-Draft IGMP and MLD Requirements for Mobility October 2008 3. The Behavior of IGMP and MLD Protocols A multicast receiving host using IGMP protocols to join and leave a multicast group on an IPv4 network, and using MLD protocols on an IPv6 network. 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. IGMPv1 introduces two specific mechanisms to avoid the implosion of concurrent reports when the host answers the Query - delaying response and report suppression. Delaying response means when a host receives the Query, it does not respond with a report immediately, but rather waits a random period of time. Report suppression means the host will withdraw its own report when it hears a report scheduled to be sent from other host joining the same group. It contributes to minimizing the number of responses but is impossible for the multicast router to track per host's membership status by reports. An IGMPv1 host does not send group leave message explicitly. It 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] makes a series of optimizations to improve the protocol behavior. An IGMPv2 host can explicitly send a Leave Report when it decides to stop receiving multicast data. This enables fast leave from the multicast group. When a multicast router receives a leave message, it will generate a Group-Specific Query specifying the multicast group address in order to recognize 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 network. In this case, a single Querier is elected by ordering the IP addresses to take on the duty of sending Query packets. Liu, et al. Expires April 16, 2009 [Page 7] Internet-Draft IGMP and MLD Requirements for Mobility October 2008 Several timers are defined for IGMPv2 operations and these 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. 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 mode on both the host and router side. With the filter mode, a host can specify the desired or undesired source address(es) and 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, because the various packet type and the diverse information carried in the report make it rather difficult to define a uniform suppression policy. Without suppression, the number of report messages may increase greatly on a link. IGMPv3 solves this problem by make pending reports or queries merged 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. Liu, et al. Expires April 16, 2009 [Page 8] Internet-Draft IGMP and MLD Requirements for Mobility October 2008 3.4. Multicast Listener Discovery Protocols MLDv1 and MLDv2 are respectively derived from IGMPv2 and IGMPv3 to be used for IPv6 host and router. 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 filter mode or vise versa, both the host and the upstream router cause 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. Not only are LW-IGMPv3 and LW-MLDv2 compatible with the standard IGMPv3 and MLDv2, but also the protocol operations made by hosts and routers or switches (performing IGMPv3/MLDv2 snooping) are simplified by reducing the complex processes and the scalability problems. The number of report types are reduced, and the host-side kernel implementation and the router's operation are greatly simplified. Besides, 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. Liu, et al. Expires April 16, 2009 [Page 9] Internet-Draft IGMP and MLD Requirements for Mobility October 2008 4. Requirements for IGMP/MLD to Support 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) implement 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. 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. Liu, et al. Expires April 16, 2009 [Page 10] Internet-Draft IGMP and MLD Requirements for Mobility October 2008 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, 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 a mobile host moves to a new foreign network, it does not need to re-join the multicast group. In the remote subscription approach, 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. After handover to another foreign network, the host needs to resend new reports to routers 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 Liu, et al. Expires April 16, 2009 [Page 11] Internet-Draft IGMP and MLD Requirements for Mobility October 2008 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 Point-To-Point Link A wireless link assumed in this document is categorized as a shared link or a point-to-point (PTP) or point-to-multipoint (PMP) link. For a shared link, the interface state maintained by a multicast router on the link is the summary of the receiving state for member hosts on the link. But for a PTP link, a multicast router has to maintain the interface state for each link, and this condition may introduce protocol overhead for the router. When a large number of receivers attach on the wireless link, the multicast router may introduce protocol overhead for the router. Protocol simplification may give some benefit for the processing cost and memory usage to deal with a 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, et al. Expires April 16, 2009 [Page 12] Internet-Draft IGMP and MLD Requirements for Mobility October 2008 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. Liu, et al. Expires April 16, 2009 [Page 13] Internet-Draft IGMP and MLD Requirements for Mobility October 2008 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 References [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. [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. Liu, et al. Expires April 16, 2009 [Page 14] Internet-Draft IGMP and MLD Requirements for Mobility October 2008 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, et al. Expires April 16, 2009 [Page 15] Internet-Draft IGMP and MLD Requirements for Mobility October 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Liu, et al. Expires April 16, 2009 [Page 16]