Monami6 Research Group Hong-ke Zhang Internet Draft Jian-feng Guan Expires: December 2007 De-yun Gao Hua-chun Zhou Ya-juan Qin Beijing Jiaotong University June 30, 2007 Multiple Interfaces Mobile Multicast draft-zhang-monami6-multipleif-mcast-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 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. 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 December 30, 2007. Abstract Zhang et al Expires December 30, 2007 [Page 1] Internet-Draft multipleif-mcast June 2007 This memo addresses a multiple interfaces mobile multicast based on extending multihoming in Mobile IPv6 and NEMO. The interfaces in the MN may be homogeneous or heterogeneous. It introduces an interface multicast state transition mechanism and multiple interfaces handover mechanism for mobile multicast listeners and mobile multicast sender. MN (or MR) maintains a multicast state information database and a forwarding database for every interface and cooperates to support seamless mobile multicast handover. 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...................................................4 3. Overview of multiple interfaces mobile multicast..............5 4. The detailed process of multiple interfaces mobile multicast..6 4.1. List information in MN...................................6 4.1.1. Interface multicast state list......................6 4.1.2. Multicast forwarding interfaces list................7 4.2. Interface selection......................................7 4.3. Interface multicast state transition.....................8 4.4. Multiply interfaces interaction.........................10 5. Message format...............................................11 6. Security Considerations......................................12 7. IANA Considerations..........................................12 8. Conclusions..................................................12 9. Acknowledgments..............................................12 10. References..................................................13 10.1. Normative References...................................13 10.2. Informative References.................................13 Author's Addresses..............................................14 Intellectual Property Statement.................................14 Disclaimer of Validity..........................................15 Copyright Statement.............................................15 Acknowledgment..................................................15 1. Introduction Mobile multicast is a research hotspot, and some mobile multicast schemes were proposed in past few years. MIPv4 [2] describes two basic mobile multicast methods: (1) Bi-directional Tunnel (BT), (2) Remote Subscribe (RS), while both of them have advantages and Zhang et al Expires December 30, 2007 [Page 2] Internet-Draft multipleif-mcast June 2007 disadvantages. Later, some improved mobile schemes were proposed to integrate the advantages of BT and RS. More recently, with the development of MIPv6 [3], FMIPv6 [7] and HMIPv6 [8] were proposed to improve the handover performance. FMIPv6 configures the New CoA before L2 handover to reduce the handover delay, while HMIPv6 introduces a mobility anchor point (MAP) as a local HA to eliminate the overhead of global handover signaling. K. Suh et al. [9] propose the fast multicast protocol for Mobile IPv6 in the fast handovers environment (M-FMIPv6) which uses the unicast tunnel between PAR and NAR to forward the multicast data during the handover. Similar to M-FMIPv6, F. Xia and B. Sarikaya [10] propose the FMIPv6 extension for multicast handover, which extends a new option, Multicast Group Information Option (MGIO) in FBU and HI. It transmits MLD state by FBU and HI to NAR and establishes the multicast delivery trees before MN move into the NAR. Based on M- FMIPv6, Georigios A. Leoleis et al. [11] propose the Fast MIPv6 extensions for Multicast support with Flow Tunneling and Buffering (M-FMIPv6/FTB). It uses the conditional tunneling on per multicast traffic flow to solve the tunnel convergence and buffering technique to eliminate multicast packets loss. Thomas Schmidt and Matthias Waehlisch [12] propose a seamless multicast handover in a HMIPv6 environment (M-HMIPv6), which uses the MAP as multicast anchor point and transmits all multicast data through it. Zhang et al [13] propose a MIPv6 multicast scheme with dynamic multicast agent (DMA), it combines movement based method and distance based method to select new multicast agent dynamically to reduce the handoff frequency. As discussed above, most mobile multicast schemes are based on single interface to perform multicast handover, which is less stable and reliable. Once MN or MR lost its connection, performance of mobile multicast will degrade significantly. As a result, it cannot realize the seamless multicast handover. Recently, the multihoming issues in MIPv6 [14] [15] and NEMO [16] were discussed. MN with multiple addresses which allocated to either a single interface or multiple interfaces can provide ubiquitous, permanent and fault-tolerant access to the Internet. The multihoming techniques used for mobile multicast can derive these advantages. While the current MIPv6 and NEMO specification cannot provide these functions. They only support MN to register to HA or CN with one CoA (noted as primary CoA). To solve this problem, R. Wakikawa et al [17] proposed MIPv6 extensions designed to register multiple CoA bound to a single HoA instead of the sole primary CoA, which introduced Binding Unique Identification number (BID) to distinguish the multiple binding entries registered by HA or CN. And it also can be used in NEMO. Zhang et al Expires December 30, 2007 [Page 3] Internet-Draft multipleif-mcast June 2007 In this memo, we discuss the multihomed problems in mobile multicast and propose a multiple interfaces mobile multicast scheme. The interfaces in the MN may have the same HA or different HAs. MN can set up multiply tunnels with HA and transmit the multicast data through these physical interfaces or tunnels. This scheme can be used not only in MIPv6, FMIPv6 and HMIPv6, but also in NEMO. 2. Terminology The terminology used in this memo remains conformal to the definitions in MIPv6, FMIPv6, HMIPv6 and NEMO. AR: Access Router BID: Binding Unique Identification number BT: Bi-directional Tunnel CoA: Care of Address FBU: Fast Binding Update GFU: Group Forwarding Update HA: Home Agent HI: Handover Initiate L-Tunnel: Long tunnel, set up between HA and MN. MAP: Mobility Anchor Point MN: Mobile Node MLD: Multicast Listener Discovery NAR: New Access Router RS: Remote Subscribe S-Tunnel: Short tunnel, set up between two adjacent ARs. PAR: Previous Access Router Zhang et al Expires December 30, 2007 [Page 4] Internet-Draft multipleif-mcast June 2007 3. Overview of multiple interfaces mobile multicast Fig.1 shows the multiple interfaces mobile multicast deployment scenario. MN has two interfaces (noted as IF1 and IF2) and signal HA. Based on IF1 and IF2, MN setup two tunnels (noted as L-Tunnel1 and L- Tunnel2) between MN and HA. Besides, MN also creates two tunnels (S- Tunnel1 and S-Tunnel2) between PAR and NAR (noted as PAR-IF1/NAR-IF1 and PAR-IF2/NAR-IF2 respectively). The main idea is to integrate the BT and RS methods and insure that at least one interface can transmit the multicast data during movement. MN maintains an interface multicast state list and a multicast group forwarding list to assist the multicast data transmission. The proposed scheme includes interface selection, interface multicast state transition, and multiple interfaces interaction. +------------+ | | +-------+ | |------|PAR-IF1| | | +-------+ | | || | | || S-Tunnel1 Link1 | | +-------+ +---------| |------|NAR-IF1|-------+ | | | +-------+ \ IF1 | | | \ +------+ | | L-Tunnel1 +------+ | |=========================================| | | HA | | Internet | | MN | | |=========================================| | +------+ | | L-Tunnel2 +------+ | | | / | | | +-------+ / IF2 +---------| |------|NAR-IF2|-------+ Link2 | | +-------+ | | ||S-Tunnel2 | | || | | +-------+ | |------|PAR-IF2| | | +-------+ +---------=--+ Figure 1 Multiple interfaces mobile multicast scenario Some assumptions show as following. o MIPv6 (or NEMO) supports multihoming; Zhang et al Expires December 30, 2007 [Page 5] Internet-Draft multipleif-mcast June 2007 o MN has multiply interfaces; o At lest one interfaces can provide Internet access; Every interface has different priority based on the pre-defined policies such as bandwidth, cost and load. MN uses the interface with the highest priority to transmit the multicast data at the beginning. Before the high prior interface lose its attachment (Link down or interface down), MN will redirect its multicast data to the secondary prior interface. MN records the group membership and forwarding information for every interface to accomplish the flow redirect. MN selects the BT or RS based on whether the AR that MN attached supports multicast or not. Multicast Router Discovery (MRD) [6] provides a general mechanism that allows for the discovery of multicast routers. If the AR can provide the multicast services, MN will send unsolicited MLD report or multicast data (when MN is a multicast source). Otherwise, MN will transmit the multicast by BT method. There are two kinds of tunnel used in BT. The first kind is the tunnel between HA and MN which setup by MIPv6, noted as L-Tunnel which has long lifetime. When MN leaves its home networks far away, L-Tunnel will have long path and large transmission overheads. The second kind is the tunnel between PAR and NAR, noted as S-Tunnel which has short lifetime and short path. The tunnel between PAR and NAR described in FMIPv6 can be classified to S-Tunnel. MN uses the S- Tunnel to reduce the packets lost during the handover. When multiply interfaces with different preferences can access to Internet and provide multicast services, MN should decide to use which of the available interfaces. The detailed process is described in Section 4. 4. The detailed process of multiple interfaces mobile multicast 4.1. List information in MN 4.1.1. Interface multicast state list MN maintains multicast state for every interface, and determines the transmission interface of the multicast data. The record entry consists of several fields as follows: o IF-Name: the name of network interfaces, for example eth0 means the first Ethernet interface. o IF-ID: the interface system ID. Zhang et al Expires December 30, 2007 [Page 6] Internet-Draft multipleif-mcast June 2007 o IF-Priority: the value to indicate the priority of interface used for interface selection. o Interface Address: the global IPv6 address of interface. L-tunnel uses the HoA, while the S-Tunnel uses the NCoA. o Multicast Address: the multicast group MN joined. o Multicast State: BT state, RS state or Idle state. o Multicast source address list: record the source addresses for SSM mode. o Filter mode: INCLUDE or EXCLUDE mode for SSM. 4.1.2. Multicast forwarding interfaces list For a given multicast group, MN maintains a multicast forwarding interface list. It is used to verify the incoming multicast data and select the interface when MN is a multicast source. The record form is shown as following. o Multicast Address o Multicast Source Address List o Filter Mode o Interface Address list 4.2. Interface selection MN may access to different networks through different network interfaces to get different network services simultaneously. These networks can be WPAN (e.g. 802.15), WLAN (e.g. IEEE 802.11), WMAN (e.g. IEEE 802.16e), and WWAN (e.g. 2G/3G) which have different bandwidth, coverage range, cost etc. MN chooses the interface based on the requirement of the applications. A policy determination mechanism can be introduced to compute the priority of interfaces. For example if MN has a WLAN card and CDMA2000 card, it can set the WLAN as the default network interface to provide the network service, and switch to CDMA2000 interface when no WLAN coverage. The detailed Policy determination mechanism is out of this memo. Zhang et al Expires December 30, 2007 [Page 7] Internet-Draft multipleif-mcast June 2007 4.3. Interface multicast state transition Every interface has two multicast states, bi-directional tunnel state (noted BT state) when multicast data transmitted by L-Tunnel or S- Tunnel with multiply IPv6 headers, and remote subscribe state (noted RS state) when multicast data transmitted through physical interface with one IPv6 header. Assume the state no multicast data transmission is idle state, and then we can get the interface has three multicast states, BT state, RS state and Idle state. An important issue should be addressed is the source address selection of MLD report message. As described in [5], the MLDv2 Report message MUST be sent with a valid IPv6 link-local source address, or the unspecified address (::), if the sending interface has not acquired a valid link-local address yet. However, MIPv6 specification indicates that MN should send an MLD Report message with a CoA which is a global IPv6 address. In this memo, the multicast data transmission is based on the source address of unsolicited MLD Report message. When BT method is used, MN chooses the HoA as the source address. As for the RS method, MN chooses the global IPv6 address (CoA) as the source address. Assume that interface has no multicast data to transmit (Idle state) at first, and the state transition diagram is shown as fig.1. Zhang et al Expires December 30, 2007 [Page 8] Internet-Draft multipleif-mcast June 2007 +------+ 0 | | | V +------------+ | | 1 +--------->| |-----------+ | | Idle state | | | +----| |<---+ | | | | | | | | | +------------+ | | 5 | 6 | 8 | | | | | | | | | | | V | V +------------+ +------------+ | | 7 | | 2 +----->| |-------------->| |------+ 4 | | BT state | | RS state | | +------| |<--------------| |<-----+ | | 3 | | +------------+ +------------+ Figure 2 Interface multicast state transition diagram There are several trigger events that can cause multicast state transitions shown in fig.2. 0. "No MLD report messages received in the network interface" when MN does not join any multicast group; 1. "MN joins the group at Home networks" when MN is similar to fixed node. 2. "The interface does not change the attachment point". 3. "MN move into the foreign networks and no interfaces in RS state". 4. "MN does not receive the Group Forwarding Update (noted as GFU) message" which means the foreign networks does not support multicast and MN only transmit the multicast data through L-Tunnel or S-Tunnel. The GFU message is introduced to notify the other interfaces to stop forwarding the relative groups data according to the information included in the GFU. 5. "MN received the GFU message or MLD done message" which means the interface has no multicast states for the multicast group included in the message. Zhang et al Expires December 30, 2007 [Page 9] Internet-Draft multipleif-mcast June 2007 6. "Join the group through the L-Tunnel or S-Tunnel" which means the current AR does not provide multicast service. 7. "Join the group through the physical network interface". 8. "MN Receive the MLD done message" which means MN leaves the multicast group. For different multicast groups joined in the interface, MN may be in different multicast state at the same time. 4.4. Multiply interfaces interaction For the given multicast session in the MN, the multicast data flow will transmit through different interfaces when MN moves. In this section, we will discuss the interface interaction procedure assuming that MN has two network interfaces attaching to different ARs, noted as IF1 and IF2 (Support that IF1 has higher priority than IF2). Assume that MN joined a multicast group from IF1 in BT state at first, and we can get the operation flow of multiple interfaces mobile multicast. The policy of the interface selection is that IF1 and RS state is preferential. +--------+ +------------| IF1-RS |<------------+ | +--------+ | | ^ ^ | 7 | | | 6 | | | | | V | | | +--------+ 1 | | 5 +--------+ 0 | IF1-BT |---------+ | +---------| IF2-BT | +--------+ | | +--------+ | | | ^ | | | | 2 | 3 | | | | | V | | +--------+ 4 | +----------->| IF2-RS |-------------+ +--------+ Figure 3 Two interfaces multicast state interaction diagram 0. MN joined the multicast group through the tunnel setup by IF1. Zhang et al Expires December 30, 2007 [Page 10] Internet-Draft multipleif-mcast June 2007 1. IF1 will detect whether its attachment point changed (similar to the movement detection process as described in MIPv6). If IF1 changed its attachment point and attach to a new AR (NAR-IF1), it will perform multicast handover and rejoin the multicast group, change the IF1 multicast state based on whether NAR-IF1 support multicast or not. This can be done by capturing packets from the AR to analysis if MLD query message exist or using the multicast router solicitation described MRD. If NAR-IF1 has the multicast function, it will join the multicast group before sending MLD done message through the tunnel, otherwise it will join the group through the S-Tunnel between previous AR (PAR-IF1) and NAR-IF1. 2. If MN moved into the area which IF1 can not attach to any AR, the IF2 will detect new ARs and judge whether the current AR support multicast. MN will repeat this process until it finds the AR with the multicast function and then it will send MLD report message to join the multicast group. 3. Once MN joins the group from IF2 with RS method, it will redirect its multicast data flow to IF2. If IF1 rejoins the group again, MN will transmit the multicast data through IF1 with RS method (RS state). 4. If IF1 can not attach to any AR and IF2 accesses to the new AR (NAR-IF2), it will transmit the multicast data from the tunnel set up between pervious AR (PAR-IF2) and NAR-IF2. 5. If NAR-IF2 supports multicast, MN will change its multicast state before it sends MLD done message from the tunnel. 6. If IF1 rejoins the group again, MN will transmit the multicast data through IF1 with RS method (RS state). 7. After MN receives multicast data from IF1, it will perform movement detection process. If IF1 attaches to a new AR, it will transmit the multicast data through the tunnel between PAR-IF1 and NAR-IF2 (setp0). If NAR-IF1 support multicast, MN will change its multicast state before it sends MLD done message from the tunnel (step1). 5. Message format As described above, the GFU message is introduced to inform the other interfaces to stop forwarding the relative groups data according to the information included in the GFU. It is used among interfaces to update the interface multicast state list and multicast forwarding interfaces list. Zhang et al Expires December 30, 2007 [Page 11] Internet-Draft multipleif-mcast June 2007 The message format is TBD. 6. Security Considerations This memo discusses a multiple interfaces based mobile multicast scheme. Unlike the single interface mobile multicast methods, it uses multiple interfaces to transmit the multicast data based on basic BT and RS methods. Security issues arise from the MIPv6 and BT or RS methods. Further security considerations will be carefully studied with the update of the memo. 7. IANA Considerations There are no IANA considerations introduced by this memo. In the future, we MAY extend one ICMPv6 message (TBD). 8. Conclusions This memo discusses the multihomed mobile multicast that MN has multiple interfaces. It sets up three multicast stats in each interface for every multicast group and describes the interface multicast state transition diagram. A detailed multiple interfaces mobile multicast produce is given. 9. Acknowledgments The authors would like to thank Behcet Sarikaya, Si-Dong Zhang (BJTU NGIRC) for their valuable comments and suggestions on this memo. Zhang et al Expires December 30, 2007 [Page 12] Internet-Draft multipleif-mcast June 2007 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 et al, "IP Mobility Support for IPv4", RFC 3344, August 2002. [3] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [4] V. Devarapalli, R. Wakikawa, A. Petrescu, P. Thubert, "Network Mobility (NEMO) Basci Support Protocol", RFC 3963, January 2005. [5] R. Vida, L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [6] B. Haberman and J. Martin, "Multicast Router Discovery", RFC 4286, December 2005. 10.2. Informative References [7] R. Koodli, "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. [8] H. Soliman, C. Castelluccia, K. EI Malki, L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005. [9] K. Suh, Y.-J. Suh, "Fast Multicast Protocol for Mobile IPv6 in the Fast Handovers Environment", IETF Internet Draft, draft- suh-mipshop-fmcast-mip6-00, Expired January 2004. [10] F. Xia, B. Sarikaya, "FMIPv6 extension for multicast Handover", draft-xia-mipshop-fmip-multicast-01, work in progress, March 2007. [11] Georgios A. Leoleis et al., "Seamless multicast mobility support using fast MIPv6 extensions", Computer Communications (2006), doi: 10.1016/j.comcom. 2006.07.013. [12] Thomas C. Schmidt, Matthias Waehlisch, "Seamless Multicast Handover in a Hierarchical Mobile IPv6 Environment (M-HMIPv6)", draft-schmidt-waehlisch-mhmipv6-04, Expired, November 2005. Zhang et al Expires December 30, 2007 [Page 13] Internet-Draft multipleif-mcast June 2007 [13] Hong-Ke zhang et al, "Mobile IPv6 Multicast with Dynamic Multicast Agent", draft-zhang-mipshop-multicast-dma-03, work in progress, January 2007. [14] N. Montavount, R. Wakikawa, T. Ernst et al, "Analysis of Multihoming in Mobile IPv6", draft-ietf-monami6-mipv6-analysis- 02, work in progress, February 2007. [15] Ernst, T., "Motivations and Scenarios for Using Multiple Interfaces and Global Addresses", draft-ietf-monami6- multihoming-motivation-scenario-01, work in progress, Oct. 2006. [16] C. Ng, T. Ernst, E. Paik, M. Bagnulo, "Analysis of Multihoming in Network Mobility Support", draft-ietf-nemo-multihoming- issues-07, work in progress, February 2007. [17] R. Wakikawa et al, "Multiple Care-of Address Registration", draft-ietf-monami6-multiplecoa-02, work in progress, March 2007. Author's Addresses Hong-ke Zhang, Jian-feng Guan, De-yun Gao, Hua-chun Zhou, Ya-juan Qin Next Generation Internet Research Center (NGIRC), Beijing JiaoTong Univ. Beijing, China, 100044 Phone: +86 10 51685677 Email: hkzhang@bjtu.edu.cn guanjian863@163.com gaody@bjtu.edu.cn hchzhou@bjtu.edu.cn yjqin@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. Zhang et al Expires December 30, 2007 [Page 14] Internet-Draft multipleif-mcast June 2007 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Zhang et al Expires December 30, 2007 [Page 15]