Multimob Hong-ke Zhang Internet Draft Jian-feng Guan Expires: January 2008 De-yun Gao Hua-chun Zhou Ya-juan Qin Beijing JiaoTong University July 2, 2007 MIPv6 Extensions for Mobile Multicast: Problem Statement draft-zhang-multimob-memcast-ps-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 January 2, . Abstract Mobile multicast is a research hotspot and gets more and more study recently. But the current mobility management specifications can not provide effective multicast packets transmission, and existing mobile multicast schemes are not generally accepted. In this memo, we discuss the problems arising from mobile multicast and address the solutions of MIPv6 extensions to support mobile multicast services. Zhang et al Expires January 2, 2008 [Page 1] Internet-Draft MEMCAST-PS July 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.................................................2 2. Terminology..................................................3 3. Problem Description..........................................3 3.1. General issues..........................................4 3.1.1. Reconstruction of multicast delivery tree..........5 3.1.2. Mobile source issues...............................5 3.1.3. Mobile receiver issues.............................5 3.1.4. Mobile forwarder issues............................5 3.2. Mobility support specification issues...................5 3.3. Multicast control protocol issues.......................7 3.4. Multi-hop mobile multicast issues.......................7 3.5. Multihoming mobile multicast issues.....................8 4. Solutions....................................................8 4.1. MIPv6 extensions........................................9 4.1.1. MIPv6 signaling extensions.........................9 4.1.2. Multicast route optimization.......................9 4.2. MLD extensions..........................................9 4.3. Multi-hop mobile multicast.............................10 4.4. Multihoming mobile multicast...........................11 5. Security Considerations.....................................11 6. IANA Considerations.........................................11 7. Conclusions.................................................11 8. Acknowledgments.............................................12 9. References..................................................13 9.1. Normative References...................................13 9.2. Informative References.................................13 Author's Addresses.............................................16 Intellectual Property Statement................................16 Disclaimer of Validity.........................................16 Copyright Statement............................................17 Acknowledgment.................................................17 1. Introduction With the development of various 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 mobility problem of multicast subscriber (multicast source and Zhang, Guan et al. Expires January 2, 2008 [Page 2] Internet-Draft MEMCAST-PS July 2007 multicast receiver) and it includes link layer handover such as WLAN, WiMAX, UMTS and network layer handover such as MIPv6 [2] and its variants such as FMIPv6 [9], HMIPv6 [10]and NEMO [3] which can provide the mobility support for mobile node or mobile network. However, these specifications do not provide an effective method to support mobile multicast services. 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. As for the multicast data, 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 [11], and try to make the tradeoff between BT and RS, using different multicast agent selection algorithms or modifying the mobility support specifications [12]. 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 scope for MIPv6 extensions of mobile multicast and describe the potential solutions. 2. Terminology The terminology used in this memo is already defined in MIPv6, FMIPv6, HMIPv6 and NEMOv6. 3. Problem Description Mobile multicast derives from the development of Mobile IP and multicast and the current mobile multicast schemes are mainly based on the combination of multicast and Mobile IP. So, the mobile multicast problem comes from two parts, first part is multicast and the second part is mobility support specifications. Multicast provides an effective group communication mechanism in IP layer to reduce the redundant packets, and it is based on host group model [6] which consists of multicast route protocol such as PIM-SM Zhang, Guan et al. Expires January 2, 2008 [Page 3] Internet-Draft MEMCAST-PS July 2007 [7] and multicast group control protocol such as MLDv1 [4] and MLDv2 [5]. Multicast routing protocol constructs the multicast delivery tree and maintains the multicast group states in multicast router, while multicast control protocol is used by multicast router and host to exchange the multicast services information. Multicast supports dynamic membership but does not support mobile group members. As a result, to provide multicast services for mobile host, both multicast route protocol and multicast control protocol face new challenges. +---+ --+ Mobile source | S |--->move | +---+ +-> MLD protocol | | +-------+--------+ | | | --+ Mobile +---+ +---+ | Forwarder | R |--->move | R | | +---+ +---+ | | | +-> Multicast +-----+-----+ | | Route protocol | | | | +---+ +---+ +---+ | | R | | R | | R | | +---+ +---+ +---+ --+ | | +-------+-------+ | | | | +-> MLD protocol +---+ +---+ +---+ Mobile | | H | | H | | H |---> Receiver | +---+ +---+ +---+ --+ Figure 1 Mobile multicast classification 3.1. General issues Traditional multicast routing protocols have been designed considering static network topology, and the multicast delivery tree is stable and little changed. Figure 1 shows the classification of mobile multicast, including mobile source, mobile receiver or mobile forwarder. 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. Zhang, Guan et al. Expires January 2, 2008 [Page 4] Internet-Draft MEMCAST-PS July 2007 3.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, MOSPF, PIM-DM and PIM-SSM, and shared tree such as PIM-SM and CBT. Source-based protocols construct 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. When we implement mobile multicast, the same mobile types in different multicast delivery tree may have different results. 3.1.2. Mobile source issues Once source changes its attachment, it will affect all receivers in the group. Firstly, transparency is the major issue for mobile source. Mobile source should hide the mobility and use the HoA as the source address of multicast data. Otherwise, the foreign network will not forward these packets. However, using the HoA will result in the ingress filtering problem and RPF check failure. Secondly, packet loss has an important impact on the performance of mobile multicast services. Thirdly, when mobile source is out of the range of group, the AR to which mobile source is attached will discard the multicast packets from the mobile source which will be considered as a foreign source. 3.1.3. Mobile receiver issues Once receiver changes its attachment, it only affects itself, and causes join delay and packet loss. 3.1.4. Mobile forwarder issues Mobile forwarder is the node in the multicast delivery tree. Once forwarder changes its attachment, it will affect the receivers in the multicast route path. Although mostly mobile multicast schemes only focus on the mobility in the access networks, the mobility in the core networks should also be considered forward mobility. 3.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 route. But, it does not provide mechanisms to enable multicast session to survive handover and to seamlessly continue from the new location. Zhang, Guan et al. Expires January 2, 2008 [Page 5] Internet-Draft MEMCAST-PS July 2007 Firstly, MIPv6 should not only record the unicast binding cache, but also record the multicast binding cache to assist the mobile multicast. Multicast binding cache may include the group address, source lists, filter mode and interface identifier. It gets the membership information through 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 transmission and multicast group control messages transmission. HA should distinguish the owner of MLD messages from the MN and intercepts and tunnels the global scoped multicast packets on home network based on the multicast group control protocol. MN should send the MLD messages to HA through tunnel or AR through physical interface to receive the multicast data from HA or AR respectively. 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 MIPv6 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. Thirdly, Mobile IP based mobile multicast schemes have to solve the route optimization problem. BT and RS are two basic mobile multicast methods, but both of them have the disadvantages. Thomas C. Schmidt and Matthias Waehlisch [12] classify mobile multicast methods into three kinds, BT based, RS based and Agent based. BT based methods use the bi-directional tunnel to transmit the multicast data between old location and new location of mobile entity, but result in tunnel convergence problem and additional overheads. 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. [11] 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 makes the multicast session instantaneous and degrades the performance of multicast services. Agent based methods try to balance between BT and RS, but increase the complexity. It needs more signaling to select the multicast agent and reconstruct the multicast tree for mobile entity. Zhang, Guan et al. Expires January 2, 2008 [Page 6] Internet-Draft MEMCAST-PS July 2007 3.3. Multicast control protocol issues IPv6 multicast router uses the MLD as the multicast group control protocol to discovery the multicast listeners, while the host uses the MLD to join and leave the group. MLD protocol is designed for fixed nodes, and only focuses on the dynamic group membership, but not considers the mobility of node. To support the mobile multicast, MLD protocol has to solve the following problems. Firstly, mobile entity has to send unsolicited MLD report message immediately after detecting the movement to shorten the rejoin delay. However, the rejoin delay results in many packets lost unfortunately even without including the link layer and IP layer handover delay. MLD can not maintain multicast group membership continually. As a result, we should increase new MLD message types to support mobile entity. Secondly, 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 MLD states in the new location. However, the MLD protocol does not provide this mechanism. How to transfer the MLD state between old location and new location affects the performance of multicast services. Thirdly, 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 MLD to record MLD state for MN in point-to- point link is preferable. 3.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 especially MANET multicast interworking with the fixed networks is multi-hop. As for the NEMO multicast, the node in the mobile network such as LFN, VMN joins the multicast group through MR which may be multiple hops to the access networks. 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 suffers from large overheads and extra propagation delay, which result in degrade of multicast services performance significantly. As Zhang, Guan et al. Expires January 2, 2008 [Page 7] Internet-Draft MEMCAST-PS July 2007 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 relay points. 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 study. 3.5. Multihoming mobile multicast issues Most mobile multicast methods including mobile network multicast are based on single 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-Mobile) [13]. The reason is that the current wireless interface of mobile devices is 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 interfaces and can support more than one Internet connections at a time (multihoming). Using multiple interfaces will provide Make-Before- Break handoffs [14], ubiquitous access, redundancy, load balancing. However, realizing the multihoming mobile multicast has to consider the problems inheriting from the MIPv6 multihoming [32]. Firstly, to use the multiple interfaces simultaneously, MN should bind multiple CoAs to a given HoA, but the current MIPv6 specification is lacking such ability. Secondly, when multiple paths from and to MN, MN should choose a suitable one to transmit the multicast packets, which includes the interface selection, HoA and CoA selection. Thirdly, when current path fails, MN should redirect the flow to the new path. Final, to balance the multicast traffic among multiple interfaces, MN should set up a load balance mechanism. 4. Solutions Mobile IP based mobile multicast solutions include MIPv6 variants extensions, MLD extensions, aiming to support multicast mobility. These extensions usually put the multicast information in signaling or transfer MLD state among ARs to reduce the re-join delay and realize optimal multicast packets transmission. Zhang, Guan et al. Expires January 2, 2008 [Page 8] Internet-Draft MEMCAST-PS July 2007 4.1. MIPv6 extensions 4.1.1. MIPv6 signaling extensions Most mobile multicast schemes extend the MIPv6 to carry the multicast information in signaling. In basic MIPv6, BT method transmits the MLD messages and multicast packets through the unicast tunnel. Based on RS, F. Xia and B. Sarikaya [15] propose FMIPv6 extension for multicast handover, which introduces a new Multicast Group Information Option (MGIO) in Fast Binding Update (FBU) and Handover Initiate (HI). To reduce the join delay, PAR transmits multicast group information to NAR through FBU and HI with the MGIO to join the multicast group in advance. Then Georigios A. Leoleis et al. [16] propose Fast MIPv6 extensions for Multicast handover support with Flow Tunneling and Buffering (M-FMIPv6/FTB), which uses the conditional tunneling of multicast traffic per flow to solve the tunnel convergence. Besides, it proposes a simple buffering technique to eliminate multicast data loss. More recently, Dong-Hee Kwon et al. [17] proposed an efficient multicast support scheme for FMIPv6. It introduces new multicast options in mobility header and ICMP header, which contain the multicast group information MN subscribed. To reduce the join delay, NAR setups the multicast states MN interested in advance by the FMIPv6 operation. Beside, it establishes a multicast specific tunnel between PAR and NAR instead of the unicast tunnel between PAR and NCoA to solve the tunnel coverage problem. Based on BT, Thomas Schmidt et al. [18] proposed seamless multicast handover in a HMIPv6 environment (M-HMIPv6), which uses the MAP as anchor point for mobile multicast and transmits all multicast data through this MAP using Regional CoA (RCoA) for multicast receiver or source. 4.1.2. Multicast route optimization Multicast route optimization aims to solve the tunnel convergence problem and realize the native multicast transmission. Agent based schemes described in [12] mainly focus on these problems. The multicast agent takes over the multicast packets transmission function, and sets up the optimal routing to mobile multicast subscriber. For example, M-FMIPv6 [19] chooses every AR as the agent while M-HMIPv6 chooses the MAP as the agent. DMA [20] chooses the dynamic multicast agent based and distance and movement. 4.2. MLD extensions Christophe Jelger and Thomas Noel [23] introduces a new type of MLD message called MLD hold message, which is used to notify an HA to Zhang, Guan et al. Expires January 2, 2008 [Page 9] Internet-Draft MEMCAST-PS July 2007 stop forwarding multicast data for specified group, but keep the group membership. To transfer the multicast state in advance, MN should have the ability to identify whether the AR has the multicast function or not at first. B. Haberman and J. Martin [8] 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 router. MRD protocol can be used in mobile multicast to help the mobile entity to realize the native multicast data transmission. After detecting the multicast ability, the mobile entity should transfer the MLD states to the candidate AR. Based on context transfer [21], I. Miloucheva and K. Jonas [22] propose fast mobile multicast in IPv6 based on multicast listening context transfer method to transmit the MLD states among ARs. 4.3. Multi-hop mobile multicast Mobile entity may have multiple Internet connections at the same time and attaches to multiple networks, which have different coverage, bite rate, bandwidth. How to implement mobile multicast in multihoming scenarios may be the key to provide the seamless mobile multicast handover. As for NEMO multicast, C. Janneteau et al. [24] propose MLD-proxy based IPv6 multicast for mobile network, which deploys MLD-based multicast forwarding (MLD-proxying) between MR and visited networks to support the multicast service in mobile network. Kiyong Park et al. [25] propose a dynamic multicast tree construction mechanism for mobile network. It sets up the multicast tunnel between MR and multicast router to support the multicast services. As for the MANET multicast interworking with fixed networks, Wei Ding [26] introduces a Multicast GateWay (MGW) entity to realize multicast routing in the mixed network. MGW has both wire-line multicast interface and wireless communication interface and supports both multicast route protocols. At the beginning it joins the multicast groups on both sides explicitly transmit data packets. However, it has been less focused on the multiple MGWs scenario. Then P. Ruiz and A. Skarmeta propose the Multicast MAnet Routing Protocol (MMARP) [27]. It introduces Multicast Internet Gateway (MIG) and uses the on-demand multicast protocol to construct the multicast structure in the MANET, maintains the route to the MIG. Besides, MMARP supports a standard mobile node accessing the Internet through the MANET. MIG keep the connectivity with the AR through the IGMP inquire message. However, the existed schemes still need further study to solve problems such Zhang, Guan et al. Expires January 2, 2008 [Page 10] Internet-Draft MEMCAST-PS July 2007 as multicast security, management etc. Afterwards Wang et al. propose a Modified MLD (M.MLD) scheme [28] which modifies the MLD messages for MANET to realize the IPv6 multicast between fixed network and MANET. In this scheme the access router in the MANTE is deployed as a Designated Router (DR) of the fixed network, and M.MLD is used as the multicast membership management protocol in the MANET by encapsulating in the unicast packets. More recently, IETF MANET WG proposes a Simplified Multicast Forwarding (SMF) for MANET [29] and tries to support interoperability with connected wired infrastructure. Zhang hui et al. [30] proposes a multicast interworking scheme between MANET and fixed network which supports cross-network multicast sessions. It uses the Certificate Authority (CA) [31] to manage the cross-network multicast sessions and insure the multicast security. 4.4. Multihoming mobile multicast Current most mobile multicast schemes based on single interface to perform multicast handover, which is less stable and reliable. Once MN or MR lost its connection to Internet, it will have a significant impact on performance of mobile multicast. Recently, the multihoming issues in MIPv6 [32] [33] and NEMO [34] 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. Zhang et al. [35] propose a multiple interfaces mobile multicast scheme in Mobile IPv6 and NEMO. The interfaces in the MN may be homogeneous or heterogeneous. This scheme introduces an interface multicast state transition mechanism and multiple interfaces handover mechanism for mobile multicast listeners and mobile multicast sources to support seamless mobile multicast handover. 5. Security Considerations This memo discusses the MIPv6 extensions for mobile multicast. Security issues arise from the extensions of mobility support specifications and MLD protocols. 6. IANA Considerations There are no IANA considerations introduced by this memo. 7. Conclusions This memo discusses the problems arise from the mobile multicast over MIPv6 variants, and describes some solutions. Zhang, Guan et al. Expires January 2, 2008 [Page 11] Internet-Draft MEMCAST-PS July 2007 8. Acknowledgments The authors would like to thank Behcet Sarikaya (Huawei USA), Hesham Soliman (Elevate Technologies), Si-Dong Zhang (BJTU NGIRC) for their valuable comments and suggestions on this memo. Zhang, Guan et al. Expires January 2, 2008 [Page 12] Internet-Draft MEMCAST-PS July 2007 9. References 9.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] S. Deering, "Host Extensions for IP Multicasting", RFC 1112, August 1989. [7] Bill Fenner, Mark Handley etc, "Protocol Independent Multicast- Sparse Mode (PIM-SM): Protocol Specification (Revised) ", RFC 4601, August 2006. [8] B. Haberman and J. Martin, "Multicast Router Discovery", RFC 4286, December 2005. 9.2. Informative References [9] R. Koodli, "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. [10] H. Soliman, C. Castelluccia, K. EI Malki, L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005. [11] Romdhani, I., Kellil, M., Lach, H.-Y. et al., "IP Mobile Multicast: Challenges and Solutions", IEEE Comm. Surveys, 6(1), 2004. [12] Thomas C. Schmidt, Matthias Waehlisch, "Multicast Mobility in MIPv6: Problem Statement and Brief Survey", draft-irtf-mobopts- mmcastv6-ps-00, May 2007. Zhang, Guan et al. Expires January 2, 2008 [Page 13] Internet-Draft MEMCAST-PS July 2007 [13] 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 [14] H. Matsuoka, T. Yoshimura, and T. Ohya, "A robust method for soft IP handover", IEEE Internet Computing, vol 7, no.2, pp 18- 24, 2003. [15] F. Xia, B. Sarikaya, "FMIPv6 extension for multicast Handover", draft-xia-mipshop-fmip-multicast-00, work in progress, September 2006. [16] Georgios A. Leoleis et al., "Seamless multicast mobility support using fast MIPv6 extensions", Computer Communications (2006), doi: 10.1016/j.comcom. 2006.07.013. [17] Dong-hee Kwon et al., "Design and Implementation of An Efficient Multicast Support Scheme for FMIPv6", IEEE INFOCOM, 2006. [18] Thomas C. Schmidt, Matthias Waehlisch, "Seamless Multicast Handover in a Hierarchical Mobile IPv6 Environment (M-HMIPv6)", draft-schmidt-waehlisch-mhmipv6-04, Expired, November 2005. [19] 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. [20] Zhang, Hongke et al., "Mobile IPv6 Multicast with Dynamic Multicast Agent", draft-zhang-mipshop-multicast-dma-03, work in progress, January 2007. [21] J. Loughney et al., "Context Transfer Protocol (CXTP)", RFC 4067, July 2005. [22] I. Miloucheva and K. Jonas, "Multicast Contexe Transfer in mobile IPv6", draft-miloucheva-mldv2-mipv6-00, June 2005. [23] Jelger C. and Noel T., "Multicast for Mobile Hosts in IP Networks: Progress and Challenges", Wireless Communications, IEEE, Volume 9, Issue 5, pp 58-64, Oct. 2002. [24] C. Janneteau et al., "IPv6 Multicast for Mobile Networks with MLD-Proxy", draft-janneteau-nemo-multicast-mldproxy-00, Expired, April 2004. Zhang, Guan et al. Expires January 2, 2008 [Page 14] Internet-Draft MEMCAST-PS July 2007 [25] Kiyong Park et al., "Dynamic Multicast Tree Construction for NEMO", draft-park-nemo-dyn-multicast-tree-00, Expired, Oct. 2005. [26] Wei Ding, "Multicast Routing in Fixed infrastructure and mobile ad hoc wireless networks with a multicast gateway" Available: http://kunz-pc.sce.carleton.ca/Thesis/WeiThesis.pdf, 2002. [27] P. Ruiz, A. Skarmeta, "Integrated IP multicast in mobile ad hoc networks with multiple attachments to wired IP networks", Proc. of IEEE International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC), pp579-583, September 2004. [28] WANG Liang you et al., "Realization of IPv6 Multicast Interworking between MANET and Fixed Networks", The Journal of China Universities of Posts and Telecommunications Vol.10, No.3, pp30-34 Sep. 2003. [29] J. Macker (NRL) et al., "Simplified Multicast Forwarding for MANET", draft-perkins-manet-smurf-02, Work in Progress, IETF MANET work group, 2006. [30] Hui Zhang, Hongke Zhang et al., "A New Architecture of Multicast Interworking between MANET and Fixed Network", Journal of Internet Technology, vol. (8):1, 2007. [31] Al-Sulaiman et al., "Cooperative caching techniques for increasing the availability of MANET certificate authority services", The 3rd ACS/IEEE International Conference on Computer Systems and Applications, pp88-94, 2005. [32] 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. [33] Ernst, T., "Motivations and Scenarios for Using Multiple Interfaces and Global Addresses", draft-ietf-monami6- multihoming-motivation-scenario-01, work in progress, Oct. 2006. [34] 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. [35] Zhang Hongke et al., "Multiple Interface Mobile Multicast", draft-zhang-monani6-multipleif-mcast-00, work in progress, July 2007. Zhang, Guan et al. Expires January 2, 2008 [Page 15] Internet-Draft MEMCAST-PS July 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 January 2, 2008 [Page 16] Internet-Draft MEMCAST-PS July 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 January 2, 2008 [Page 17]