MULTIMOB Group H. Liu Internet-Draft Huawei Technologies Co., Ltd. Expires: May 15, 2008 H. Asaeda Keio University November 12, 2007 Mobile Multicast Requirements on IGMP/MLD Protocols draft-liu-multimob-igmp-mld-mobility-req-00 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 May 15, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Liu & Asaeda Expires May 15, 2008 [Page 1] Internet-Draft IGMP and MLD Requirements for Mobility November 2007 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 & Asaeda Expires May 15, 2008 [Page 2] Internet-Draft IGMP and MLD Requirements for Mobility November 2007 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 . . . . . . . . . . . . 6 3.1. IGMP Version 1 . . . . . . . . . . . . . . . . . . . . . . 6 3.2. IGMP Version 2 . . . . . . . . . . . . . . . . . . . . . . 6 3.3. IGMP Version 3 . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Multicast Listener Discovery Protocols . . . . . . . . . . 7 3.5. Lightweight IGMPv3/MLDv2 . . . . . . . . . . . . . . . . . 8 4. Requirements for IGMP/MLD to support IP multicast mobility . . 9 4.1. General Evaluation of IGMP/MLD Protocols in mobile environments . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Requirements on the Tuning of IGMP/MLD Protocol Parameters . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Requirements on IGMP/MLD during handover . . . . . . . . . 10 4.4. Requirements on large number of point-to-point link . . . 11 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 & Asaeda Expires May 15, 2008 [Page 3] Internet-Draft IGMP and MLD Requirements for Mobility November 2007 1. Introduction With the increasing demand for the Internet broadband video service, IP multicast has more potential to be widely deployed to improve bandwidth efficiency. It is even desirable if the consumers can obtain such service while they are in the moving state. Much efforts have been taken to integrate IP multicast technology with current mobility IP mechanism to make a feasible solution. IP multicast is defined for the transmission of an IP datagram from a multicast source to a host group. The end host uses IGMP for IPv4 and MLD for IPv6 to subscribe or unsubscribe a group. The intermediate routers construct multicast tree between the source and the receiving hosts with multicast routing protocols. The IGMP and MLD protocol are natively designed for the fixed network. Even though the protocols are thought to be applicable also to the mobile or wireless environments, their protocol manner should be carefully evaluated whether they are completely suitable or should make some extension or modifications in these situations. In this draft, the requirements of mobile multicast service imposing on the IGMP/MLD group subscription mechanism are discussed in detail. Liu & Asaeda Expires May 15, 2008 [Page 4] Internet-Draft IGMP and MLD Requirements for Mobility November 2007 2. Problem Statement IP Multicast mobility generally is characterized by receiver mobility, source mobility and network mobility. The receiver mobility is our discussion focus because it has more promising application scenarios, exhibits less deployment complexity, and has more influence on the operation of IGMP/MLD protocols. A mobile host usually accesses to the network via wireless connection where bandwidth efficiency, packet loss under bad conditions, security issues due to interception and attack should be seriously considered. And a mobile terminal cares much about its battery consumption. All these require the IGMP/MLD protocols to be as compact as possible. When the receiving host moves from one network to another, it sometimes need to re-subscribe the multicast group. The handover will introduce extra packet loss and session disruption. This requires the IGMP/MLD to make group join and leave operation as quickly as possible to accelerate the reconnection and release the unnecessary link resources. In the following part of this draft, we first introduce the IGMP/MLD protocols, then analyze whether their protocol behavior can meet the requirements of IP multicast mobile service, and if needed, discuss the possibility of the modification or extension of the protocols. The illustration blow will consider both IPv4 and IPv6 networks. Liu & Asaeda Expires May 15, 2008 [Page 5] Internet-Draft IGMP and MLD Requirements for Mobility November 2007 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 [4] defines the basic operating model between the multicast receiving host and its upstream router to determine group membership. The router periodically launches General Group Queries to its attached subnet. An host sends an IGMP 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 Group Query - delaying response and suppressing reports. Delaying response means when a host receives a Query, it does not respond with a report immediately, but rather waits a random period of time. Suppression means the host will withdrawn its own report when it hears a report from other host joining the same group. It is impossible for the multicast router to track per host status for the suppression of the group report. IGMPv1 host does not send group leave message explicitly. It silently leaves the group by initiating no report when receiving Group Query. 3.2. IGMP Version 2 IGMP Version 2 [5] makes a series of optimization to improve the performance of IGMPv1. First, the IGMPv2 explicitly sends a leave report when it decides to stop receiving from a group, which enables fast leaving of a multicast group. Further, when a multicast router receives such leave message, it will generate a Group-Specific Query, which helps the router to further determine whether there is other receiver for this group on its network. The third optimization lies in that IGMPv2 can support more complicated networking when multiple multicast routers connected to the same network. In this case a single Querier is elected by ordering the addresses to take on the duty of sending Query packets. Several timers are defined with their values configurable. Query Interval is the interval between General Queries sent by a router, which has influence on the total number of IGMPv2 messages on the subnet. Query Response Interval is the maximum response time of a report after the host receiving the General Query. It helps reduce the burst of the reports on a subnet. Startup Query Interval is the Liu & Asaeda Expires May 15, 2008 [Page 6] Internet-Draft IGMP and MLD Requirements for Mobility November 2007 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 group leave. 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 robustly. 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 are no local members. Startup Query Count is the number of Queries issued on startup. The above values could be tuned according to the expected packet loss on a subnet. 3.3. IGMP Version 3 IGMP Version 3 [2] introduces a big enhancement to the previously two versions. It defines INCLUDE and EXCLUDE filter-mode on both the host and router side. Using this filter mode, the host can specify the source list information in its group report. IGMPv3 router uses filter-mode to process the group record properly. The router also maintain a group-timer to indicate the filter mode switchover 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 use host suppression, 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 packet may increase greatly on the subnet. IGMPv3 solves this problem by make pending reports or queries merged into a combined packet. An advantage for non-suppression is that it provide the possibility for the router to keep the receiving status of each individual member, which is known as Explicit Tracking. The tracking consumes much more memory on the router, but provides feasibility to manage end users. 3.4. Multicast Listener Discovery Protocols MLD1 and MLDv2 are respectively derived from IGMPv2 and IGMPv3 to be used for IPv6 host and router. The most important difference between MLD and IGMP is that MLD use ICMPv6 message format. For MLDv1 parts of the message types are renamed to distinguish from those of IGMPv2. Liu & Asaeda Expires May 15, 2008 [Page 7] Internet-Draft IGMP and MLD Requirements for Mobility November 2007 3.5. Lightweight IGMPv3/MLDv2 IGMPv3 and MLDv2 are very complex for the processing compared to their previous versions, which hindered the protocols from being deployed as expected to some degree. IGMPv3 supports the Source-Specific Multicast (SSM) communication [7] by including sources in the INCLUDE Group Record. But its usage of excluding undesired sources in EXCLUDE mode has little practical prototype, whereas has the major contribution of processing complexity. In [8], a simplified version of IGMPv3 is defined to keep the INCLUDE source-filtering characteristics to support SSM communication, while removing EXCLUDE source-filtering operation. The report types are reduced and the router part operation is greatly simplified. Besides, less states need to be stored by lightweight router compared to their full IGMPv3/MLDv2 counterpart. Liu & Asaeda Expires May 15, 2008 [Page 8] Internet-Draft IGMP and MLD Requirements for Mobility November 2007 4. Requirements for IGMP/MLD to support IP multicast mobility 4.1. General Evaluation of IGMP/MLD Protocols in mobile environments As mentioned in Section 3, bandwidth efficiency and security require the compactness of the IGMP/MLD protocols. This compactness means IGMP/MLD should minimize the packet interchanging between the mobile host and the multicast router. Considering the traditional multicast communication, called Any- Source Multicast (ASM), and SSM communication model, an ASM host can receive all the traffic from all the sources sending to the group, while an SSM host receives the traffic from a source through the subscribed (S,G) channel. The former is prone to interception and is more possible to import unnecessary multicast traffic onto local network, whether the host is willing to receive them or not. So from the mobile edge's prospective, SSM is a favorable choice to provide mobile multicast service. All the versions of IGMP/MLD support the ASM scenarios. Even though IGMPv1 has least packet transmission, but since it has no robust mechanism required in unreliable wireless situations, it should not be considered as an applicable solution. IGMPv2 and MLDv1 are more concise compared with IGMPv3/MLDv2 for its host suppression operation. But they do not support SSM subscription, thus have little potential to be widely deployed. When using SSM communication model, the mobile host can use IGMPv3/ MLDv2 and LW-IGMPv3/LW-MLDv2 to subscribe a SSM group. There is no packet overhead difference between the two protocols in both ASM and SSM reception model. The lightweight versions have the advantage of simpler processing. IGMP/MLD protocols (except for IGMPv1) adopt some measures to implement fast join and leave for a group. When a host intends to join a group, it sends unsolicited report immediately. The Startup Query Interval has been set to the 1/4 of General Query value to enable the fast joining at startup. When the host ceases from hearing from a group, it reports the leaving 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 just been stopped. This helps the router acquire the information as fast as possible when all the members as a whole leave a group. The latency of this kind of leaving of all members is referred to as network latency. Lower latency or faster leave has the advantage of releasing the network more quickly. Liu & Asaeda Expires May 15, 2008 [Page 9] Internet-Draft IGMP and MLD Requirements for Mobility November 2007 4.2. Requirements on the Tuning of IGMP/MLD Protocol Parameters Within each protocol's scope, the packet number on the network could be further decreased by tuning the value of the timer. 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, the message robustness requires some type of messages are transmitted more than once. Robust Variable is defined for IGMP/MLD protocols to adapt to networks of different robustness degree. It decides the transmitting times of the Startup Query, Last Member Query and Unsolicited Reports. On lossy subnet, the Robust Variable should be increased to allow for the expected level of packet loss. The 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 on IGMP/MLD during handover The handover manners are illustrated in diversified mobile IP multicast schemes. [9] categorized the schemes by their group subscription manner principally as home subscription-based and remote subscription based solutions. In home subscription, the IGMP/MLD message should be encapsulated and tunneled to the home network. The multicast router (usually 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. While in the remote subscription approach, the 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 hosts need to resend new reports to the routers on the new network. If the old multicast branches have been tore down before the new branches being able to be constructed, the host will suffer from packets loss during the handover. To prevent the possible packets loss, make-before-break mechanism should be provided. This requires the IGMP/MLD mobile host to join the group on the new network as soon as possible once it decides to switch onto 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 Liu & Asaeda Expires May 15, 2008 [Page 10] Internet-Draft IGMP and MLD Requirements for Mobility November 2007 multicast router. The mobile host can further benefit less packet loss from prediction of the handover. The detection and handover can be initiated either by the mobile host or by the network part. In the mobile-initiated handover, the host acquires the handover information quickly and can send early reports. While in the network-initiated handover, the network entity should indicate the mobile the possible handover situation. How this indication (usually layer2 information) is transmitted from the network to the host can be realized depending on the application. It is possible that IGMP and MLD are extended to carry this handover indication from router to the host to facilitate the fast join. In this case some extension should be made on the IGMP/MLD packet. However, this handover indication may also be required by other unicast sessions. A common handover indicating mechanism may be utilized for both multicast and unicast cases, which is not necessarily an IGMP/MLD extended solution. IGMP/MLD host and router can adjust their timer and counter values to make faster join/leave during handoever, as described in Section 4.2. The retransmission number of the report and query messages should make reference to the practical conditions of the wireless access connection. 4.4. Requirements on large number of point-to-point link Two link modes are characterized in wireless access networks [10][11]: shared link and point-to-point (PTP) link. IGMP and MLD are considered to be heavy when large number of PTP link is connected to the same multicast router, for the router should keep the state of each mobile in a separate interface. The protocol overhead speeds up (e.g. Query amount) as the number of the mobile node increases. There are two solutions to the problem. One option is using multicast VLAN in IGMP/MLD snooping switch, with each multicast group number belonging to a separate multicast VLAN, which can be interpreted as logical sharing on a multicast VLAN. The other option is simplifying IGMP/MLD Protocols to suit the PTP links. Because generally there is only one receiving host on each link, the operation of IGMP/MLD relating to multiple receivers on each interface should be taken out. Host suppression is unnecessary. Delaying response randomly to avoid bursting of packets can also be given up; instead the mobile could respond reports immediately, which can implement better fast-leave capability. Besides, neither Group- Specific query nor Source-and-Group-Specific is needed because when Liu & Asaeda Expires May 15, 2008 [Page 11] Internet-Draft IGMP and MLD Requirements for Mobility November 2007 this receiver mobile leaves this group, in most cases there is little other listeners for the group or the sources on the same mobile. When PTP link receiver number becomes large, the memory consumption on the multicast router may be undesirable for an interface structure should be recorded for each receiver. Thus the router should maintain least necessary state for each receiver. From this point of view, LW-IGMP/MLD protocols which discarding EXCLUDE filter-mode are preferably to be used when supporting SSM reception. 4.5. Requirements for Explicit Tracking If Host Suppression is not adopted, IGMP/MLD multicast routers could chose 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 much memory resources on the router. The advantage of explicit tracking is that it provides better manageability of (mobile) receivers. Besides, for the router knows who is listening for which group and sources, the Group-Specific query and Source-Specific Query triggered by stopping receiving is unnecessary to issue on the subnet. As mentioned in previous section, as tracking large number of hosts consumes a lot of memory, the LW-IGMP/MLD is preferred when SSM reception mode is to be deployed. Liu & Asaeda Expires May 15, 2008 [Page 12] Internet-Draft IGMP and MLD Requirements for Mobility November 2007 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 & Asaeda Expires May 15, 2008 [Page 13] Internet-Draft IGMP and MLD Requirements for Mobility November 2007 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] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, August 1989. [5] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2373, July 1997. [6] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [7] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006. 6.2. Informative References [8] Liu, H., Cao, W., and H. Asaeda, "Lightweight IGMPv3 and MLDv2 Protocols", draft-ietf-mboned-lightweight-igmpv3-mldv2-01.txt (work in progress), June 2007. [9] Romdhani, I., Kellil, M., and H. Lach, "IP Mobile Multicast: Challenges and Solutions", IEEE Comm. Surveys 6(1), 2004. [10] Schmidt, T., Waehlisch, M., and et. al, "Mobility in MIPv6: Problem Statement and Brief Survey", draft-irtf-mobopts-mmcastv6-ps-01.txt (work in progress), July 2007. [11] Zhang, H., Guan, J., and et. al, "MIPv6 Extensions for Mobile Multicast: Problem Statement", draft-zhang-multimob-memcast-ps-00.txt (work in progress), July 2007. Liu & Asaeda Expires May 15, 2008 [Page 14] Internet-Draft IGMP and MLD Requirements for Mobility November 2007 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 Liu & Asaeda Expires May 15, 2008 [Page 15] Internet-Draft IGMP and MLD Requirements for Mobility November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Liu & Asaeda Expires May 15, 2008 [Page 16]