Multimob WG Hong-ke Zhang Internet Draft Jian-feng Guan Expires: February 2009 Hua-chun Zhou Zhi-wei Yan Beijing Jiaotong University August 5, 2008 MLD Extensions to Support the Mobile Multicast Group Management draft-zhang-multimob-mld-mmcast-00.txt 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. This document may only be posted in an Internet-Draft. 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 February 5, 2009. Abstract Mobile multicast is a research hotspot. Some mobile multicast schemes was proposed, but most of them depend on the traditional group membership management protocol and concern on the reconstruction of multicast delivery tree by various algorithms, and they little consider the mobile group membership management. So in this memo, we extend the MLD protocol to support the mobile multicast group management. The extension is compatible with the traditional MLD protocols, and it can also be applied to the IGMP protocol to manage the mobile multicast in IPv4. Zhang, et al Expires February 5, 2009 [Page 1] Internet-Draft MLD Extension for MMCAST August 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.................................................2 2. Terminology..................................................3 3. Overview of the MLD Extension................................3 4. MLD Extensions...............................................4 4.1. MLD Host Function Extension.............................4 4.1.1. The Extension of MLDv1 Report Message..............4 4.1.2. The Extension of MLDv2 Report Message..............5 4.1.3. MLD Message Encapsulation Format...................6 4.2. MLD Router Function Extension...........................9 5. The Operation Flow of Extended MLD Report Messages..........10 6. Security Considerations.....................................10 7. IANA Considerations.........................................10 8. Conclusions.................................................11 9. Acknowledgments.............................................11 10. References.................................................12 10.1. Normative References..................................12 10.2. Informative References................................12 Author's Addresses.............................................13 Intellectual Property Statement................................13 Disclaimer of Validity.........................................13 Copyright Statement............................................14 Acknowledgment.................................................14 1. Introduction Mobile multicast develops from the traditional multicast routing protocols and the mobility support specifications to provide the multicast services for mobile subscribers. Mobile IP [2] introduces two basic IPv4 mobile multicast methods, called Bi-directional Tunneling (BT) and Remote Subscribing (RS). The BT method forwards multicast packets from the Home Agent (HA) through the unicast tunnel. As a result, BT has lower join latency and does not require multicast support in the foreign networks. However, the BT method introduces the additional delivery overhead. The RS method transmits multicast packets from current access router, so it has optimal routing. However, it has long join latency and needs multicast support in the foreign networks. Afterwards, some improved mobile multicast schemes such as Mobile Multicast Protocol (MoM) [5] and Range-Based Mobile Zhang, et al. Expires February 5, 2009 [Page 2] Internet-Draft MLD Extension for MMCAST August 2008 Multicast (RBMoM) [6] have been proposed, and they try to make the trade-off between BT and RS by different multicast agent selection algorithms. However, the recent research [8-9] shows that the current mobile multicast schemes are not generally accepted. The current study of mobile multicast mainly concerns on the reconstruction algorithms, while little researches the mobile multicast membership management protocols. Generally, the multicast technology consists of multicast routing protocols and group management protocols. The multicast routing protocols are used to set up multicast delivery path, while group management protocols are used to maintain the dynamic group membership. The Multicast Listener Discovery (MLD) v1 [3] and MLDv2 [4] are used in IPv6 to maintain dynamic group membership for fixed nodes (IGMP is used in IPv4 networks). The MLD is designed to limit group management messages in local link and prevent the diffuse of group membership. This design principle is beneficial to reduce the redundant information in networks, but it is unable to provide the multicast management for mobile nodes. If the MLD protocol is directly used in mobile multicast services, it may cause a long multicast service disruption. According to the MLDv1 specification, this disruption may be 67 seconds even without the link layer handover and IP layer handover delay [7]. To improve the performance of mobile multicast, some mobile multicast management protocol mechanism should be proposed to manage the mobile subscribers. 2. Terminology 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]. The terminology used in this memo is already defined in MIPv6, FMIPv6, HMIPv6 and NEMO. 3. Overview of the MLD Extension The MLD protocol is a subset of ICMPv6 and the message types of MLDv1 and MLDv2 are 130, 131, 132 and 143. All MLD messages use the link- local address as the source address, and set the hop limit to be 1. In order to force the IPv6 routers on that link to check MLD messages, all MLD messages are encapsulated in hop-by-hop option with router alert sub-option. MLD is an asymmetric protocol which consists of router function and host function. The router function is used to create the multicast state for subscribers ,and the record form is {IPv6 group address, filter mode, source list}, while the host Zhang, et al. Expires February 5, 2009 [Page 3] Internet-Draft MLD Extension for MMCAST August 2008 function is used by subscribers to send the join and leave messages, and respond to periodic query messages. The MLD extension is based on the traditional MLD protocol to provide mobile multicast management for mobile nodes, and it is compatible with the current MLD protocol. The MLD extensions consist of MLD host function extension and MLD router function extension. And the principle of extensions is to transmit the MLD messages to the neighbouring subnets that the mobile subscribers may enter to create the multicast status in advance. 4. MLD Extensions The MLD extensions maintain the group membership for mobile nodes based on the extended fields, and add new fields in the multicast status to record the CoA and HoA information of mobile nodes. And the extensions also introduce the multicast forwarding flag to control the multicast packet transmission. 4.1. MLD Host Function Extension MLD host function extension mainly modifies the MLD hop limit to notify the neighbouring subnet to set up multicast status in advance. And the MLD host function extension mainly extends the MLD report message (message type are 131 and 143), and the MLD query message and done message is similar to traditional MLD protocol. 4.1.1. The Extension of MLDv1 Report Message Figure 1 shows the extension of MLDv1 report message. We use the code field in ICMPv6 header to mark the extended MLD messages. Zhang, et al. Expires February 5, 2009 [Page 4] Internet-Draft MLD Extension for MMCAST August 2008 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |Code(Extension)| Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Response Delay | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Multicast Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 The Extension Of MLDv1 Report Message Generally, the code field is used to create an additional level of message granularity, and the additional messages depend on the type of ICMPv6 message type. The MLDv1 report message is initialized to zero by the sender and ignored by receivers. We extend this field to carry the hops limit information. For example, we can use the code field to record the predefined hops limit directly. When code field is equal to 0, MLD messages use the link- local address as the source address, and perform the traditional MLD function. When the code field is bigger than 1, the MLD messages use the global unicast address as the source address, and use the value in the code field to set the hop limit in IPv6 header. Besides, we can also record the movement status of mobile node, and set up the map between the movement status and hops limit to set the hop limit. The detailed setting policy is beyond the scope of this memo. 4.1.2. The Extension of MLDv2 Report Message Figure 2 shows the extensions of MLDv2 report message. We extend the reserved field of MLDv2 report message to indicate the type of MLD message. Similar to the extended Code field in MLDv1 message, the source address selection is also based on the reserved field. When the reserved field is equal to 0, the message is traditional MLD message, or else it is an extended MLD report message. Zhang, et al. Expires February 5, 2009 [Page 5] Internet-Draft MLD Extension for MMCAST August 2008 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 143 | Extension | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |Nr of Mcast Address Records (M)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Multicast Address Record [1] . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Multicast Address Record [2] . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | . . . | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Multicast Address Record [M] . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 The Extension Of MLDv1 Report Message 4.1.3. MLD Message Encapsulation Format Mobile node generates extended MLD report messages during the movement. To provide the information for mobile multicast membership management, the encapsulation of extended MLD messages differ from the traditional MLD messages. Figure 3 shows the encapsulation format of MLDv1/v2 messages. The extended MLD messages use the CoA as the source address and set the hop limit based on the value in the extended field. The following header is Hop-by-hop Option and the value of IPv6 next header is 0x00. The Hop-by-hop Option uses the router alert sub-option to force the router to check this message. The next header field in Hop-by-hop Option is set to 0x3c which means Destination Option with the Home Address Option to carry the home address of mobile node. The last header is the ICMPv6 header which carries the extended MLDv1/v2 messages. Zhang, et al. Expires February 5, 2009 [Page 6] Internet-Draft MLD Extension for MMCAST August 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len |0 0 0|0 0 1 0 1|0 0 0 0 0 0 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (0) | PadN (2 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Extended MLDv1/MLDv2 Report Message | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 The Encapsulation of Extended MLDv1/v2 Report Message Version 4-bit Internet Protocol version number = 6. Traffic Class 8-bit traffic class field which is used by originating nodes and/or forwarding routers to Zhang, et al. Expires February 5, 2009 [Page 7] Internet-Draft MLD Extension for MMCAST August 2008 identify and distinguish between different classes or priorities of IPv6 packets. Flow Label 20-bit flow label. It may be used by a source to label sequences of packets for which it requests special handling by the IPv6 routers, such as non-default quality of service or "real-time" service. Payload Length 16-bit unsigned integer. Record the length of the IPv6 payload. Next Header 8-bit selector. Identifies the type of header immediately following the IPv6 header. To encapsulate the extended MLD message, the next header is the hop-by-hop option (0x00). Hop Limit 8-bit unsigned integer. Decremented by 1 by each node that forwards the packet. The packet is discarded if Hop Limit is decremented to zero. In traditional MLD message, the hop limit is set to 1. But for the extended MLD message, the hop limit is based on the value in the extended field. Source Address 128-bit address of the originator of the packet. For the traditional MLDv1/v2 message, the source address uses the link-local address. But for the extended MLD message, the source address selection is based on the value of extended field, (see section 4.1.1 and 4.1.2). Destination Address 128-bit address of the intended recipient of the packet (possibly not the ultimate recipient, if a Routing header is present). Next Header 8-bit selector. Identifies the type of header immediately following the Hop-by-Hop Options header. In the extended MLD message, the next header is Destination Option (0x3c) with carries the HAO option. Hdr Ext Len 8-bit unsigned integer. Length of the Hop-by-Hop Options header in 8-octet units, not including the first 8 octets. Zhang, et al. Expires February 5, 2009 [Page 8] Internet-Draft MLD Extension for MMCAST August 2008 Options Variable-length field, of length such that the complete Hop-by-Hop Options header is an integer multiple of 8 octets long. Contains one or more TLV-encoded options. In the extended MLD messages, the Router Alert Option is used to focus the routers along the path to check the message. The first three bits of the first byte are zero and the value 5 in the remaining five bits is the Hop-by-Hop Option Type number. By zeroing all three, the nodes not recognizing this option type should skip over this option and continue processing the header. The next 8 bits record the length of the option. And the value in the next 2 octet code is set to 0 which means the in network byte order with the following the packet that contains a Multicast Listener Discovery messages. Next Header 8-bit selector. The next header is the ICMPv6 message and the value set to 0x3a. Hdr Ext Len 8-bit unsigned integer. Length of the Destination Options header in 8-octet units, not including the first 8 octets. Option Type 201 = 0xC9, the HAO sub-option. Option Length 8-bit unsigned integer. Length of the option in octets excluding the Option Type and Option Length fields. This field MUST be set to 16. Home Address The home address of the mobile node sending the packet. This address MUST be a unicast routable address. 4.2. MLD Router Function Extension The router function extension is to add the CoA and HoA fields in multicast status. The extended record form is {IPv6 group address, filter mode, source list, CoA, HoA, forwarding flag}. The source list record format is {IPv6 source address, timers}. The CoA and HoA field are used to record the multicast status for mobile node, and the forwarding flag is used to indicate the multicast forwarding status. When the forwarding flag is 1, the multicast router will forward the Zhang, et al. Expires February 5, 2009 [Page 9] Internet-Draft MLD Extension for MMCAST August 2008 multicast packets, or else it will suppress the multicast packets forwarding. 5. The Operation Flow of the Extended MLD Report Messages Mobile node generates the extended MLD report messages when it moves among the foreign networks, and it sends the extended MLD report message to the MLD Querier in the attached link. The detailed procedure is shown as following. (1) Firstly, the MLD Querier checks the source address after receiving the report message. The source address indicates the type of MLD report message. (2) If the source address is the link-local address, the MLD Querier performs the traditional MLD message procedure. Or else it will perform the extended MLD message procedure. (3) And then the MLD Querier checks the sender of message based on the source address. If the source address belongs to its direct attached link, it will create/update the multicast status and set the forwarding flag to 1. Or else, it only creates/updates the multicast status with the forwarding flag set to 0. (4) After that the MLD Querier checks the hop limit. If the hop limit is 0, it will stop forwarding this message, or else it forwards this message to the other attached links. The MLD query message and MLD done message are similar to the traditional MLD protocol. When the multicast status is near to expire, the MLD Querier will advertise the MLD query message, and the MN responds the MLD report message to update the multicast status. When MN leaves the current access network, it sends MLD done message, and the MLD Querier will reply the last listener query message after receiving the done message. 6. Security Considerations The security considerations are similar to the [3-4]. 7. IANA Considerations This document defines the new extensions of MLDv1/MLDv2 Report messages. The extensions need to assign the new Code values in MLDv1 report message and reserved field in MLDv2 report message. Zhang, et al. Expires February 5, 2009 [Page 10] Internet-Draft MLD Extension for MMCAST August 2008 8. Conclusions In this memo, we propose the extended MLD protocol to provide mobile multicast membership management. The extended protocol extends the forwarding range of MLD messages, and maintains the multicast status for mobile nodes. 9. Acknowledgments The authors would like to thank Si-Dong Zhang, Ya-juan Qin, Hongbin Luo (BJTU NGIRC) for their valuable comments and suggestions on this memo. Zhang, et al. Expires February 5, 2009 [Page 11] Internet-Draft MLD Extension for MMCAST August 2008 10. References 10.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] C. Perkins, "IP Mobile Support for IPv4", IETF RFC 3344. 2002. [3] S. Deering, W. Fenner, B. Haberman, " Multicast Listener Discovery (MLD) for IPv6", IETF RFC 2710, 1999. [4] R. Vida and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", IETF RFC 3810, 2004. 10.2. Informative References [5] Harrison T.G., Williamson C. L., Mackrell W. L., Richard B. Bunt, "Mobile multicast (MoM) protocol: Multicast support for mobile hosts", ACM MOBIGCOM 1997, Budapest, Hungary, pp: 151- 160, 1997. [6] C.R. Lin and K.M Wang, "Mobile multicast support in IP networks", IEEE INFOCOM 2000, vol.3, Tel Aviv, Israel, pp: 1664-1672, 2000. [7] Wu Qian, "Studies on IP Multicast in Mobile Internet", Ph. D Thesis, Beijing: Tsinghua University, 2006. [8] Thomas C. Schmidt, Matthias Waehlisch, "Multicast Mobility in MIPv6: Problem Statement and Brief Survey", draft-irtf-mobopts- mmcastv6-ps-01, work in progress, 2007. [9] Jian-feng Guan et al., "MIPv6 Extensions for Mobile Multicast: Problem Statement", draft-zhang-multimob-memcase-ps-01, IETF draft, work in progress, 2007. Zhang, et al. Expires February 5, 2009 [Page 12] Internet-Draft MLD Extension for MMCAST August 2008 Author's Addresses Hong-ke Zhang, Jian-feng Guan, Hua-chun Zhou, Zhi-wei Yan Next Generation Internet Research Center (NGIRC), Beijing JiaoTong University Beijing, China, 100044 Phone: +86 10 51685677 Email: hkzhang@bjtu.edu.cn guanjian863@163.com hchzhou@bjtu.edu.cn 06120232@bjtu.edu.cn Intellectual Property Statement 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. Disclaimer of Validity 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. Zhang, et al. Expires February 5, 2009 [Page 13] Internet-Draft MLD Extension for MMCAST August 2008 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Zhang, et al. Expires February 5, 2009 [Page 14]