Network Working Group P. Yang Internet-Draft Hitachi (China) R&D Corporation Intended status: Standards Track H. Deng Expires: May 8, 2008 China Mobile Q. Wu Tsinghua Univ. November 5, 2007 Multicast tunneling optimization for Mobile IPv6 draft-yang-multimob-mip6-mc-tunnel-opt-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 8, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Yang, et al. Expires May 8, 2008 [Page 1] Internet-Draft Multicast Opt for MIPv6 November 2007 Abstract This document provides the solution to optimize the multicast tunneling in mobile IPv6. This solution will not break the basic bi- directional tunneling multicast solution of MIPv6. A new Mobile Multicast Agent works as a proxy node for multiple mobile nodes within one limit scope. Single tunnel is set up between one Home Agent and one Mobile Multicast Agent for single multicast stream. A new notification message is created for the communication between home agent and mobile multicast agent. There is no modification on mobile nodes. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Solution for MIPv6 multicast tunneling optimization . . . . . 4 3. Operation of Mobile Multicast Agent (MMA) . . . . . . . . . . 7 3.1. Tunnel manipulation . . . . . . . . . . . . . . . . . . . 7 3.2. operation of Multicast Serving Table . . . . . . . . . . . 7 3.3. operation of Multicast notification message . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Normative References . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Yang, et al. Expires May 8, 2008 [Page 2] Internet-Draft Multicast Opt for MIPv6 November 2007 1. Introduction Mobile IPv6 (MIPv6)[RFC3775] allows the mobile nodes(MN) to maintain the reachability while moving in the IPv6 network. After registration to home agent(HA), the packets destined to MN could be routed correctly by using the end-to-end tunnel, while MN is away from the home network. MIPv6 has some other extensions (HMIP6 [RFC4140] and FMIP6 [RFC4068] for different application schemes. Multicast is an optimal way for mass multimedia delivery of gourp communication in mobile network. Mobile IPTV is one of such group communication cases, where multicast is suitable. [Yang07]. MIPv6 has two methods for multicast. [Schmidt07] has analysis on these two ways: - Remote multicast subsciption: this solution rely on multicast router, which is seldom available in the mobile network. It also suffers from the slow handover. - Bi-directional tunneling: The advantage of the bi-directional tunneling solution is its simplicity and the transparency of handover to the multicast operation. But multiple tunnels are set up between MNs and HA even for one single multicast stream. This tunnel overhead weakens the benefit of using multicast greatly. So, this document proposes the solution to optimize the bi-direction tunneling multicast solution of MIPv6. With simple extension, this solution could also be applied to other extended MIPv6 solution as well. When MN is in the foreign network, the packet routing between HA and MN is at least via an access router(AR). AR is the first hop for MN to get access to internet. The characteristics of the link between MN and AR are different depending on the types of access network and radio links. So, the multicast optimization between MN and AR should be specific for access network. In this document, the solution is only focused on the multicast tunnels between AR and HA. Yang, et al. Expires May 8, 2008 [Page 3] Internet-Draft Multicast Opt for MIPv6 November 2007 2. Solution for MIPv6 multicast tunneling optimization Currently bi-directional tunneling multicast routing in foreign network is depicted in the picture below: Access network (Wired or Wireless) IP multicast | packets | | +------+ V +------+ +------+ | | |===============|======|=============| | | | MN | | AR | | HA | V | | |======|=============| |----- +------+ //+------+ +------+ // +------+ //< -------bi-dictional | |// tunnel. | MN | | | +------+ In this document, a new mobile multicast agent(MMA) is proposed to optimize the multicast tunneling solution of MIPv6. In the real deployment, MMA and AR could be collocated together. The new solution of bi-directional tunneling multicast routing in foreign network is depicted in the picture below: Access network (Wired or Wireless) IP multicast | +......................+ packets | : may be collocated : | +------+ V : +------+ +------+ : +------+ | | |============|======|====| | : | | | | MN | : | AR | | MMA |========| HA | V | | : |======|====| | : | |----- +------+ //+------+ +------+ : +------+ //......................+ +------+ // | |// < -------bi-dictional | MN | tunnel. | | +------+ MMA is the termination point of the tunnel from HA. MMAs should be very close to ARs or even collocated with ARs. Compared with the current multicast solution of MIPv6, the number of unicasting tunnels Yang, et al. Expires May 8, 2008 [Page 4] Internet-Draft Multicast Opt for MIPv6 November 2007 for one streams multicast between one pair of AR/MMA and HA will decreased to only one. This is especially meaningful when one HA serves many MNs with multicast services. The call flow of the optimized MIPv6 multicast is shown below (AR and MMA are collocated together): MN p(AR/MMA) n(AR/MMA) HA MR | | | | | | MLD membership query | | | (0) |< ========================================|< ----------| | | | | | | MLD membership report | | | (1) |======================================== >|---------- >| | | MC Notify | | | (2) | |< -------------------------| Multicast | | | single | | packets | (3) | multiple | tunnel | |< ----------| (4) | tunnels |< #########################| | (5) |< ============| | | | | | | | | Handover to n(AR/MMA) | | | ------------------------------------------------------------- | BU | | | | (6) |---------------------------------------- >| | | BA | | | | (7) |< ----------------------------------------| | | | | MC Notify | | (8) | | |< ---------| | | | MC Notify | | | (9) | |< -------------------------| Multicast | | | single | | packets | (10)| multiple | tunnel | |< ----------| (11)| tunnels |< #########################| | (12)|< ============| | | | (0) HA forwards the MLD membership query message down to MNs via the bi-directional tunnels periodically. (1) MNs should report their multicast group membership by the MLD membership report message. This message should be tunneled to HA firstly and forwarded to the other multicast routers afterwards. (2) When HA finds that MN(s) want to have join the new multicast groups, it will notify AR/MMA with the information of related MN addresses and multicast addresses. It may also put some other Yang, et al. Expires May 8, 2008 [Page 5] Internet-Draft Multicast Opt for MIPv6 November 2007 streams related messages inside the notification message. AR/MMA will store this information inside the Multicast Serving Table (MST). HA will also store the triple-units of (MN, AR/MMA, Multicast Address) in the local cache. (3) HA receives one multicast stream from the multicast router. HA will check the cached (MN, AR/MMA, multicast address) based on the multicast address of incoming multicast stream. (4) HA will tunnel the stream to the related AR/MMA with single tunnel. The Outer IP header is from HA to AR/MMA. The inner IP packet is the original multicast packet. (5) At AR/MMA, it will check the MST and get the addresses of MNs who have subsribes this multicast stream. AR/MMA will make duplication of the received tunnel packet based on the number of related MNs. then, it will replace the dstination addresses of the outer tunnel headers with the Care of Addresses(CoAs) of related MNs repectively. Lastly, it will send all these tunnel packets to the MNs. MNs do not need modification to receive these packets. (6,7) When MN handover to the subnet of new AR/MMA, it will finish BU/BA procedure firstly with HA. (8) On parallel, HA sends notification to the new AR/MMA with the information of multicast addresses =and MN addresses. The new AR/MMA stores this information inside the (MST) of it's own. (9) HA notifies the old AR/MMA to remove the MST entries related to the MN addresses. (10) HA receives one multicast stream from the multicast router. HA will check the cached (MN, AR/MMA, multicast address) based on the multicast address of incoming multicast stream. (11) The multicast packet will be tunneled to the new AR/MMA accordingly. The Outer IP header is from HA to new AR/MMA. The inner IP packet is the original multicast packet. (12) The new AR/MMA will do the same tunnel duplication and address replacement as step (5) MMA may be a seperated device from AR. The tunnel optimization solution is almost the same as the combined one. But it may be necessary for HA to discover the new MMA. How to choose the new MMA is out of scope of this document. And, if MMA does not change while MN does handover to new AR, HA does not need to do the step (9) in the picture above. Yang, et al. Expires May 8, 2008 [Page 6] Internet-Draft Multicast Opt for MIPv6 November 2007 3. Operation of Mobile Multicast Agent (MMA) The main function of MMA is to convert the single multicast tunnel from HA to multile tunnels for related MNs respectively. This operation should be done based on the information of MST. It is recommended to put MMA and AR together. 3.1. Tunnel manipulation The logical packet of the tunnel from HA is showed below: +----------+------------+---------+--------------+---------+ | HA's Addr| MMA's Addr |CN's Addr|Multicast Addr| Payload | +----------+------------+---------+--------------+---------+ |< ---- Outer IP ---- >|< ---- Inner IP ---- >| | tunnel header | tunnel header | In the tunneled packet from HA, the destination and original address of the outer IP tunnel header is MMA's address and HA's address respectively. The inner IP packet is the original IP multicast packet from the corresponding node(CN). In MMA, it will check the MST and get the addresses of MNs who have subsribes this multicast stream. Duplication of the received tunnel packet will be made based on the number of related MNs. The dstination addresses of the outer tunnel headers will be replaced by the Care of Addresses(CoAs) of related MNs repectively. Lastly, it will send all these tunnel packets to the MNs. The generated tunnel packet is depicted in the picture below: +----------+------------+---------+--------------+---------+ | HA's Addr| MN's CoA |CN's Addr|Multicast Addr| Payload | +----------+------------+---------+--------------+---------+ |< ---- Outer IP ---- >|< ---- Inner IP ---- >| | tunnel header | tunnel header | The structure of this tunnel packet is the same as the one of the tunneled multicast packets between HA and MN in [RFC3775]. So, the MN do not need to be modified in this solution. 3.2. operation of Multicast Serving Table MST should at least contains the information of HA address, MNs' addresses and related multicast address. It may have some other information, such as the characterastics of streams, timing information and mobile TV channel information. These supplementary Yang, et al. Expires May 8, 2008 [Page 7] Internet-Draft Multicast Opt for MIPv6 November 2007 information is sometimes useful for the stream manipulation. The initiation, update and termination of MST entries should only be done based on the notification messages from HA. 3.3. operation of Multicast notification message The definition of multicast notification message is out of scope of this document. It could be a specific message or extension to a generic message. This part should be defined by seperated documents. Yang, et al. Expires May 8, 2008 [Page 8] Internet-Draft Multicast Opt for MIPv6 November 2007 4. Security Considerations This solution basically does not break the security framework of MIPv6. Because MLD membership messages should be tunneled, the data traffic between HA and MN should be protected by tunnel ESP. It is recommended to set up the security associations (SAs) between HA and MMAs. Notification messages could be protected by transport ESP. Yang, et al. Expires May 8, 2008 [Page 9] Internet-Draft Multicast Opt for MIPv6 November 2007 5. Conclusion A new multicast delivery solution in MIPv6 is proposed in this solution. It does not break the basic routing and security framework of the original MIPv6 solution. The multiple unicasting multicast tunnels could be avoided between HA and AR. Yang, et al. Expires May 8, 2008 [Page 10] Internet-Draft Multicast Opt for MIPv6 November 2007 6. Normative References [BCMCS] 3GPP2, "Broadcast/Multicast Services - Stage 1, Revision A", 3GPP2 S.R0030-A V1.0, Feb. 2004. [MBMS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS) Architecture and functional description", 3GPP TS 23.246 V8.0.0, September 2007. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. [RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005. [Schmidt07] Schmidt, T., "Multicast Mobility in MIPv6: Problem Statement and Brief Survey", draft-irtf-mobopts-mmcastv6-ps-01.txt (work in progress), July 2007. [Yang07] Yang, P., "Problem Statement and Analysis: Multicast Mobility for Mobile IPTV", draft-yang-multimob-ps-mobiletv-00.txt (work in progress), November 2007. Yang, et al. Expires May 8, 2008 [Page 11] Internet-Draft Multicast Opt for MIPv6 November 2007 Authors' Addresses Peng Yang Hitachi (China) R&D Corporation 301, North Wing, Tower C Raycom Infotech Park 2 kexueyuan Nanlu Haidian District Beijing, 100080 P.R. China Phone: +861082862918(ext.)328 Email: pyang@hitachi.cn Hui Deng China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: denghui@chinamobile.com Qian Wu Tsinghua Univ. Yang, et al. Expires May 8, 2008 [Page 12] Internet-Draft Multicast Opt for MIPv6 November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Yang, et al. Expires May 8, 2008 [Page 13]