Multimob Jian-feng Guan Internet Draft Hong-ke Zhang Expires: May 2008 De-yun Gao Hua-chun Zhou Ya-juan Qin Beijing JiaoTong University November 17, 2007 MIPv6 Extensions for Mobile Multicast: Problem Statement draft-zhang-multimob-memcast-ps-01.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 May 17, . Abstract Mobile multicast is a research hotspot and gets more and more study recently. But the current existent mobility management specifications can not provide effective multicast transmission. In this memo, we discuss the problems arising from mobile multicast and address the solutions space of mobility support specifications extensions to support mobile multicast services. Zhang et al Expires May 17, 2008 [Page 1] Internet-Draft MEMCAST-PS 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..................................................3 2. Terminology...................................................3 3. Mobile Multicast Types........................................4 4. Problem Description...........................................4 4.1. General Issues...........................................5 4.1.1. Reconstruction of Multicast Delivery Tree...........5 4.1.2. Mobile Source Issues................................6 4.1.3. Mobile Receiver Issues..............................6 4.1.4. Mobile Forwarder Issues.............................6 4.2. Mobility Support Specification Issues....................6 4.3. Multicast Control Protocol Issues........................7 4.4. Multi-hop Mobile Multicast Issues........................8 4.5. Multihoming Mobile Multicast Issues......................8 5. Solutions Space Analysis......................................9 5.1. The Definition and Classification of Mobile Multicast....9 5.2. Which Entities Are Involved in Mobile Multicast?........10 5.2.1. How to Identify the Multicast Capacity of Forwarder?10 5.2.2. How to Select the Appropriate Forwarder?...........11 5.3. Who Initiates Mobile Multicast?.........................11 5.4. How to Extend Mobility Support Specifications and Multicast Specifications?..............................................11 5.5. How to Deploy Mobile Multicast in Multihoming Environment?12 5.6. What Are the Mobile Multicast Security Considerations?..12 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..............................................15 Intellectual Property Statement.................................15 Disclaimer of Validity..........................................15 Copyright Statement.............................................16 Acknowledgment..................................................16 Zhang, Guan et al. Expires May 17, 2008 [Page 2] Internet-Draft MEMCAST-PS November 2007 1. Introduction Multicast technology has developed from fixed platform to mobile platform. Recently, with the development of various wireless and mobile technologies, mobile multicast becomes more important because it can provide many applications such as mobile conference, on-line game. Mobile multicast has to solve both dynamic group membership and the mobility problem of multicast entity such as multicast source and multicast receiver. Multicast Listener Discovery (MLD) version 1[4] or version 2 [5] protocol is used to manage the dynamic membership for IPv6 (IGMP [6] for IPv4), while it cannot maintain the multicast states for mobile multicast entities. To solve this problem, it needs to support of both link layer handover such as WLAN, WiMAX, UMTS and network layer handover such as MIPv6 [2] and its variants such as FMIPv6 [11], HMIPv6 [12]and NEMO [3]. However, these specifications cannot provide an effective mechanism to support mobile multicast. MIPv6 is designed to support unicast communication by caching the binding between HoA and CoA of MN, and route the packets addressed to HoA to CoA transparently. For the multicast packets, two basic methods, Bi-directional Tunnel (BT) and Remote Subscribe (RS) methods were proposed. BT is transparent and has lower join latency, but introduces triangular routing and additional transmission overheads. While RS has effective routing, but increases long join delay especially when foreign networks do not have the multicast states of MN interested, and even result in multicast service disruption if foreign networks do not support multicast. Based on BT and RS, several improved schemes were proposed in past few years [13], and try to make the tradeoff between BT and RS, using different multicast agent selection algorithms or modifying the mobility support specifications. According to [14], the current mobile multicast schemes can be classified into three kinds, BT based methods, RS based methods and Agent based methods. The prime problem of mobile multicast is that the current mobility support specifications such as MIPv6 can not provide effective multicast transmission mechanism. The binding cache in MIPv6 only records the mapping between HoA and CoA which can be used to reroute the unicast packets directly. However, for multicast data, no such mechanism is defined. So, in this memo, we specify the problems for MIPv6 extensions of mobile multicast and describe the potential solutions space. 2. Terminology The terminology used in this memo is already defined in MIPv6, FMIPv6, HMIPv6 and NEMO. Zhang, Guan et al. Expires May 17, 2008 [Page 3] Internet-Draft MEMCAST-PS November 2007 3. Mobile Multicast Types Figure 1 shows the classification of mobile multicast based on the entities involved in multicast, which includes three basic mobile types, mobile source, mobile receiver and mobile forwarder. Mobile forwarder is the node in the multicast delivery tree. For example, Mobile IP based multicast is typical mobile source or receiver types, and the NEMO multicast and MANET multicast are mobile forwarder type. +---+ --+ Mobile source | S |--->move | +---+ +-> MLD protocol | | +-------+--------+ | | | --+ Mobile +---+ +---+ | Forwarder | R |--->move | R | | +---+ +---+ | | | +-> Multicast +-----+-----+ | | Routing protocol | | | | +---+ +---+ +---+ | | R | | R | | R | | +---+ +---+ +---+ --+ | | +-------+-------+ | | | | +-> MLD protocol +---+ +---+ +---+ Mobile | | H | | H | | H |---> Receiver | +---+ +---+ +---+ --+ +----------------------------------+ | H: host R: Router S: source| +----------------------------------+ Figure 1 Mobile multicast classification 4. Problem Description Mobile multicast derives from the development of Mobile IP and multicast technology, and current mobile multicast schemes are mainly based on the combination of fixed multicast and mobility support specifications. So, the mobile multicast problems come from two parts, one is fixed multicast and the other one is mobility support specifications. Zhang, Guan et al. Expires May 17, 2008 [Page 4] Internet-Draft MEMCAST-PS November 2007 Multicast provides an effective group communication mechanism in IP layer to reduce the redundant packets transmission compared with the unicast. Fixed multicast is based on host group model [7] which consists of multicast route protocol and multicast group control protocol. Multicast routing protocols constructs the multicast delivery tree and maintains the multicast states in multicast routers, while multicast control protocol is used by multicast router and host to exchange the multicast membership information. For the different mobile types, the current multicast routing protocols only support dynamic membership and cannot support mobile group members. When a group member moves into another subnet, it has to rebuild its multicast states by itself or the other entities. 4.1. General Issues Traditional multicast routing protocols have been designed for static network topology and the multicast delivery tree is stable or little changed. For mobile multicast, these assumptions changed. Directly applying traditional multicast route protocols to mobile scenario may result in multicast session disruption. To improve the performance of multicast services, it has to solve the following problems. 4.1.1. Reconstruction of Multicast Delivery Tree The foundational problem in mobile multicast is the reconstruction of multicast delivery tree. There are two kinds of multicast delivery trees, source-based tree such as DVMRP [15], MOSPF [8], PIM-DM [16] and PIM-SSM, and shared tree such as PIM-SM [9] and CBT [17]. Source- based protocols construct optimal multicast delivery trees for every source in a group. While shared tree protocols construct a RP or Core based multicast delivery tree for a group. Figure 2 shows the influence of mobile multicast with SPT and RPT. Different multicast delivery trees affect different nodes. In more complicated scenario with multiple mobile multicast types, the performance of mobile services will degrade significantly. +=========================================================+ | | Mobile Source | Mobile Forwarder| Mobile Receiver | +=====+===============+=================+=================+ | SPT | ALL | PART | ONE | +-----+---------------+-----------------+-----------------+ | RPT | ALL | PART | ONE | +-----+---------------+-----------------+-----------------+ Figure 2 The influence of Mobile multicast using SPT and RPT Zhang, Guan et al. Expires May 17, 2008 [Page 5] Internet-Draft MEMCAST-PS November 2007 4.1.2. Mobile Source Issues Once source changes its attachment, it will affect all receivers in the group. The first problem is the multicast data transmission mode. If the current AR supports multicast or MLD proxy with multicast forwarding, mobile source MAY transmit the native multicast packets. Or else, it MUST transmit the multicast packets encapsulated in unicast. The second problem is to hide mobility. To be transparent for the other nodes, mobile source SHOULD use the HoA as the source address of multicast data. However, using the HoA will result in the ingress filtering problem and RPF check failure. The third problem is when mobile source is out of the scope of group, AR will discard the multicast packets as it will take the source as a strange node. 4.1.3. Mobile Receiver Issues Once receiver changes its attachment, it only affects itself. The multicast packets will be loss and out-of-order, which result in service disruption. Firstly, mobile receiver SHOULD shorten the leave delay and rejoin delay as possible as it can. To reduce the leave delay can alleviate the overhead of multicast forwarder, while to shorten the rejoin delay will reduce the packet loss. Secondly, it SHOULD support the duplication packet detection (DPD) and packet realignment. After mobile receiver handover from one subnet to another subnet, it will get the duplicated and disordered multicast packets, which will degrade the performance of mobile multicast services. 4.1.4. Mobile Forwarder Issues Once forwarder changes its attachment, it will affect all the multicast traffic on the path. The multicast forwarder MAY be the Mobile Router in NEMO or the forward node in MANET multicast. Moreover, it also can be the RP when PIM-SM is used. Although mostly mobile multicast schemes only focus on the mobility in the access networks, the mobility in the middle should also be considered. 4.2. Mobility Support Specification Issues Mobile IP provides handover management and location management for mobile entity, and it sets up the binding cache between HoA and CoA to support the transparent unicast transmission. However, it does not provide mechanisms to enable multicast session to survive handover. Firstly, MIPv6 should not only record the unicast binding cache, but also record the multicast binding cache to assist the mobile Zhang, Guan et al. Expires May 17, 2008 [Page 6] Internet-Draft MEMCAST-PS November 2007 multicast. Multicast binding cache may include the group address, source lists, filter mode and interface identifier. It records the membership information from the tunneled MLD messages or extended signaling and gets the MN information from unicast binding cache. The Multicast binding cache can be located in the HA or the other entity such as Rendezvous Point in PIM-SM. Secondly, Multicast session consists of multicast data and group control messages transmission. As described in MIPv6, to support mobile multicast, HA should be a full IPv6 multicast router or have the proxy MLD function coupled with kernel multicast forwarding. However, MIPv6 does not define the detailed mechanisms and the functional requirements for HA and MN. To support the seamless multicast handover, HA should cooperate the mobility support specifications with multicast routing protocol or proxy MLD, and sets up the multicast information for MN and transmits the native multicast packets between HA and MN. Mobile support specification SHOULD maintain both of them. When HA receives the MLD message form the unicast tunnel or upstream interface, it SHOULD distinguish the owner of MLD messages. While MN SHOULD send the MLD messages to HA through tunnel or to AR through physical interface, respectively. Thirdly, Mobile IP based mobile multicast schemes have to solve the route optimization problem. To optimize multicast route, we need an effective multicast forwarder or agent selection mechanism. BT and RS are two basic selection methods. BT based methods use the bi- directional tunnel to transmit the multicast data between old location and new location of mobile entity. While using IP tunnels involves multiple encapsulation and de-capsulation operations which require an extra cost of CPU time and memory, and increase the multicast packet size which causes fragmentation and large bandwidth consumption. RS based methods rejoin the multicast delivery tree in new location, but introduce additional join delay, which includes L2 and L3 handover delay, multicast membership protocol delay, multicast delivery tree computation delay, and the increased propagation delay. It degrades the performance of multicast services. Agent based methods introduce new entity and use different selection algorithms to balance between BT and RS, but increase the complexity. So, mobility support specifications need solve multicast route optimization problem. 4.3. Multicast Control Protocol Issues Multicast router uses the IGMP/MLD as the multicast group control protocol to discovery the multicast subscribers, and the host uses the IGMP/MLD to join and leave the group. IGMP/MLD protocol is designed for fixed nodes, and only support dynamic group membership, Zhang, Guan et al. Expires May 17, 2008 [Page 7] Internet-Draft MEMCAST-PS November 2007 but not considers the mobility of nodes. To support the mobile multicast, IGMP/MLD protocol has to solve the following problems. Firstly, mobile entity has to send unsolicited IGMP/MLD report message immediately after detecting the movement to shorten the rejoin delay. Secondly, IGMP/MLD messages are link-local, destined to a link-scope multicast address and have a hop limit of 1 and can not forward to the other subnets. When mobile multicast subscriber moves into another subnet, it has to reconstruct multicast states in the new location. However, the IGMP/MLD protocol does not provide this mechanism. Thirdly, IGMP/MLD protocol only records the multicast membership information for every link not the node, which can reduce the number of multicast states in shared link such 802.11. But for some point-to-point links such as UMTS, HA assigns a home link prefix that is unique for each MN and HoA is assigned from this unique prefix. As a result, it makes a link for each MN. So the multicast behavior could be simplified. Extend the IGMP/MLD to record multicast state for MN in point-to-point link is preferable. 4.4. Multi-hop Mobile Multicast Issues The current mobile multicast schemes mainly are single-hop based, and the distance between mobile multicast subscribers and the AR is one hop. However, mobile network multicast such as NEMO multicast and MANET multicast interworking with the fixed networks is multi-hop. For NEMO multicast, the node in the mobile network such as LFN, VMN joins the multicast group through MR which may be multi-hop to the access networks. IGMP/MLD messages and multicast packets can not be forwarded if the router in the path to AR does not support the multicast function. Especially when nesting happens, the multicast packets transmission will suffer from large overheads and additional propagation delay, which result in degradation of multicast services. For the MANET multicast interworking with the fixed networks, every node in the MANET may be dynamic and get the connection through multiple nodes as forwarders. Because the mobile devices have limited bandwidth, power, and coverage, the multi-hop mobile multicast scheme should be light-weight. How to provide multicast service for these nodes in the mobile network should be considered in the further mobile multicast schemes. 4.5. Multihoming Mobile Multicast Issues Most mobile multicast methods including mobile network multicast are based on single network interface and connect to one AR at a time, which results in the mobile entity having to break the connection to the current network before reattaching itself to the new network (Break-Before-Make) [18]. The reason is that the current wireless Zhang, Guan et al. Expires May 17, 2008 [Page 8] Internet-Draft MEMCAST-PS November 2007 network interfaces of mobile devices are incapable of listening to multiple base stations. As a result, the multicast session will be disrupted because of the serious packet loss. Recently, more and more mobile devices have multiple network interfaces and can support more than one Internet connections at a time. Using multiple interfaces can provide Make-Before-Break handoffs , ubiquitous access, redundancy, load balancing. However, realizing the multihoming mobile multicast has to consider the problems inheriting from the MIPv6 multihoming [19]. While it still have some problems. Firstly, current mobility support specifications do not support MN to bind multiple CoAs in HA and CN. Secondly, it needs a multicast traffic distribution mechanism which includes the interface selection, HoA and CoA selection. When multiple paths are available, MN should choose a suitable one to transmit the multicast packets. If current path fails, MN should redirect the flow to the new path. Besides, to balance the multicast traffic among multiple interfaces, MN should set up a load balance mechanism. 5. Solutions Space Analysis As described in Section 4, Mobile multicast faces many challenges. In this section, we try to analyze the solution space based on following questions: o The definition of mobile multicast. o Which entities are involved in mobile multicast? o Who initiates mobile multicast? o How to extend mobility support specification and multicast specifications? o How to deploy the mobile multicast under multihoming? o What are the mobile multicast security considerations? 5.1. The Definition and Classification of Mobile Multicast In this memo, the mobile multicast means the IP multicasting in mobile environments based on various mobility support specifications, which include MIPv4/6, FMIPv4/6, HMIPv4/6, NEMO4/6 and various MANET unicast and multicast protocols. According to section 3, mobile multicast has three basic types, mobile source, mobile receiver and mobile forwarder. In some scenarios, multiple mobile types may coexist which is more complicated to provide mobile multicast services. Zhang, Guan et al. Expires May 17, 2008 [Page 9] Internet-Draft MEMCAST-PS November 2007 5.2. Which Entities Are Involved in Mobile Multicast? There are many combinations of entities involved in mobile multicast at different application scenarios. Figure 3 shows the entities involved in three mobile multicast types. +=========================+===+===+===+===+===+===+ | | MSS | S | R | F | HA| AR| MR| +-----------------+-------+---+---+---+---+---+---+ | | MIP | Y | N | Y | Y | Y | O | | +-------+---+---+---+---+---+---+ |Mobile Source | NEMO | Y | N | Y | Y | Y | Y | | +-------+---+---+---+---+---+---+ | | MANET | Y | N | Y | O | O | O | +-----------------+-------+---+---+---+---+---+---+ | | MIP | N | Y | Y | Y | Y | O | | +-------+---+---+---+---+---+---+ |Mobile Receiver | NEMO | N | Y | Y | Y | Y | Y | | +-------+---+---+---+---+---+---+ | | MANET | N | Y | Y | O | O | O | +-----------------+-------+---+---+---+---+---+---+ | | MIP | N | N | Y | Y | Y | O | | +-------+---+---+---+---+---+---+ |Mobile Forwarder | NEMO | N | N | Y | Y | Y | Y | | +-------+---+---+---+---+---+---+ | + MANET | N | N | Y | O | O | O | +=================+=======+===+===+===+===+===+===+ S – Source R – Receiver MR – Mobile Router F – Forwarder Y – Yes N – No O – Not a Issue Figure 3 Mobile multicast classification Every entity involved has different function requirement, and they have to cooperate to finish mobile multicast. The key entity in mobile multicast is the forwarder node (sometimes also called agent), which may be HA, AR, MR, or any other node with multicast capacity. So, there are two questions left to be solved. 5.2.1. How to Identify the Multicast Capacity of Forwarder? Multicast capacity means the node supports multicast routing or IGMP/MLD Proxying to forward multicast packets. B. Haberman and J. Martin [10] propose Multicast Router Discovery (MRD), a general mechanism to discovery the multicast routers. MRD introduces Multicast Router Advertisement (MRA) and Multicast Router Solicitation (MRS) to detect the IP multicast forwarding ability of a Zhang, Guan et al. Expires May 17, 2008 [Page 10] Internet-Draft MEMCAST-PS November 2007 router. MRD protocol can be used in mobile multicast to detect the multicast capacity of involved entities. 5.2.2. How to Select the Appropriate Forwarder? After detecting the multicast capacity of forwarder, we need to select one forwarder or more to optimize mobile multicast performance. For example, in BT based methods HA is selected as the forwarder, it will record the multicast states and forward multicast packets. In RS based methods, the current AR is selected as the forwarder. While in agent based methods, multiple forwarders are selected in succession with the movement of mobile entity. It seems that we need to define an effective forwarder selection algorithm. 5.3. Who Initiates Mobile Multicast? Mobile multicast is based on mobility support specifications. Similar to the handoff procedure it has different initiator. There are three kinds of handoff initiation mechanisms, mobile-controlled, network- controlled and mobile-assisted [23]. Mostly mobility support specifications such as MIP and NEMO are host-based, and the mobile entity firstly detects the movement and then initiates the mobile multicast, whereas the others mobility support specifications such as Proxy MIP [24] are network based, and the network in charge of the mobility management. When deploy mobile multicast services, the first problem we need to consider is the multicast handoff initiator. To advance the performance of mobile multicast, the earlier discovery of mobility is preferential. 5.4. How to Extend Mobility Support Specifications and Multicast Specifications? The current mobility support specifications and multicast protocols do not support the mobile multicast in nature. On one hand, multicast data is traded as unicast data in mostly mobility support specification. As a result to support effective mobile multicast, most mobile multicast schemes have to extend the mobility support specifications. Based on MIP, many schemes record multicast states for mobile entity in HA or the other nodes. While, FMIP based schemes most add multicast information in signaling messages such as FBU and HI. While in HMIP based schemes, MAP function entity is extended to have more multicast capacity. On the other hand, IGMP/MLD is also extended to record or transfer the multicast states context for mobile entity. Zhang, Guan et al. Expires May 17, 2008 [Page 11] Internet-Draft MEMCAST-PS November 2007 5.5. How to Deploy Mobile Multicast in Multihoming Environment? Most mobile entity has multiple Internet connections and attaches to multiple networks at one time, which have different coverage, bite rate, bandwidth. How to implement mobile multicast in multihoming scenarios is important to provide the seamless mobile multicast handover. Current most mobile multicast schemes based on single network interface to perform multicast handover, which is less stable and reliable. Once mobile entity lost its connection, it will have a significant impact on performance of mobile multicast services. Recently, the multihoming issues in MIPv6 [19] [20] and NEMO [21] 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 [22]. The multihoming techniques used for mobile multicast can ensure global connectivity and minimizes the disruption time. However, to deploy mobile in multihoming, we need to solve the problems such as multicast traffic distribution, multiple interfaces management and mobile multicast handover management. 5.6. What Are the Mobile Multicast Security Considerations? TBD 6. Security Considerations This memo discusses the MIPv6 extensions for mobile multicast. Security issues arise from the extensions of mobility support specifications and MLD protocols. 7. IANA Considerations There are no IANA considerations introduced by this memo. 8. Conclusions This memo discusses the problems arise from the mobile multicast over MIPv6 variants, and describes some solutions. 9. Acknowledgments The authors would like to thank Behcet Sarikaya (Huawei USA), Thomas C. Schmidt (HAW Hamburg), Hesham Soliman (Elevate Technologies), Si- Dong Zhang, Hongbin Luo (BJTU NGIRC) for their valuable comments and suggestions on this memo. Zhang, Guan et al. Expires May 17, 2008 [Page 12] Internet-Draft MEMCAST-PS November 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] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [3] V. Devarapalli, R. Wakikawa, A. Petrescu, P. Thubert, "Network Mobility (NEMO) Basci Support Protocol", RFC 3963, January 2005. [4] S. Deering, W. Fenner, B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [5] R. Vida, L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [6] W. Fenner, "Internet Group Management Protocol, Version 2", RFC 2373, July 1997. [7] S. Deering, "Host Extensions for IP Multicasting", RFC 1112, August 1989. [8] J. Moy, "Multicast Extensions to OSPF", RFC 1584, March 1994. [9] Bill Fenner, Mark Handley etc, "Protocol Independent Multicast- Sparse Mode (PIM-SM): Protocol Specification (Revised) ", RFC 4601, August 2006. [10] B. Haberman and J. Martin, "Multicast Router Discovery", RFC 4286, December 2005. 10.2. Informative References [11] R. Koodli, "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. [12] H. Soliman, C. Castelluccia, K. EI Malki, L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005. [13] Romdhani, I., Kellil, M., Lach, H.-Y. et al., "IP Mobile Multicast: Challenges and Solutions", IEEE Comm. Surveys, 6(1), 2004. Zhang, Guan et al. Expires May 17, 2008 [Page 13] Internet-Draft MEMCAST-PS November 2007 [14] Thomas C. Schmidt, Matthias Waehlisch, "Multicast Mobility in MIPv6: Problem Statement and Brief Survey", draft-irtf-mobopts- mmcastv6-ps-01, November 2007. [15] D. Waitzman, C. Partridge, S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988. [16] A. Adams, J. Nicholas, W. Siadak, "Protocol Independent Multicast – Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005. [17] A. Ballardie, "Core Based Trees (CBT version 2) Multicast Routing" – Protocol Specification, RFC 2189, September 1997. [18] Petander H., Perera E., Seneviratne A., "Multiple Interface Handoffs: A Practical Method for Access Technology Independent Make-Before-Break Handoffs", NICTA Technical Report, July 2005, http://nicta.com.au/uploads/documents/PA005092_NICTA1.pdf [19] 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. [20] Ernst, T., "Motivations and Scenarios for Using Multiple Interfaces and Global Addresses", draft-ietf-monami6- multihoming-motivation-scenario-01, work in progress, Oct. 2006. [21] 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. [22] Zhang Hongke et al., "Multiple Interface Mobile Multicast", draft-zhang-monani6-multipleif-mcast-00, work in progress, July 2007. [23] Farhan Siddiqui and Sherali Zeadally, "Mobility Management across Hybird Wireless Networks: Trends and Challenges", Computer Communications 29 (2006) 1363-1285, Elsevier publish, 2006. [24] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury and B. Patil, "Proxy Mobile IPv6", draft-sgundave-mip6-proxymip6-02, work in progress, March 2007. Zhang, Guan et al. Expires May 17, 2008 [Page 14] Internet-Draft MEMCAST-PS November 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 University 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. 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, Guan et al. Expires May 17, 2008 [Page 15] Internet-Draft MEMCAST-PS November 2007 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, Guan et al. Expires May 17, 2008 [Page 16]