Network Working Group H. Deng Internet-Draft China Mobile Intended status: Standards Track June 20, 2008 Expires: December 22, 2008 Multicast tunneling optimization for Mobile IPv4 draft-deng-multimob-mip4-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 December 22, 2008. Deng Expires December 22, 2008 [Page 1] Internet-Draft Multimob MIP4 June 2008 Abstract This document provides the solution to optimize the multicast tunneling in mobile IPv4. This solution will not break the basic bi- directional tunneling multicast solution of MIPv4. A new multicast foreign 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 foreign agent for single multicast stream. A new notification message is created for the communication between home agent and multicast foreign agent. There is no modification on mobile nodes. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. MIPv4 FA CoA multicast tunneling optimization . . . . . . . . 4 3. Call flow of Multicast MIP4 FA CoA . . . . . . . . . . . . . . 5 4. Operation of Multicast Foreign Agent (MFA) . . . . . . . . . . 7 4.1. Tunnel manipulation . . . . . . . . . . . . . . . . . . . 7 4.2. Operation of Multicast Serving Table . . . . . . . . . . . 7 4.3. Operation of Multicast notification message . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Normative References . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Deng Expires December 22, 2008 [Page 2] Internet-Draft Multimob MIP4 June 2008 1. Introduction While more and more operators begin to provide the wireless broadband network systems, the needs for multicast and broadcast service in mobile network become promising. Section 4.3 and 4.4 of [RFC3344] discuss the support of multicast and broadcast. In order to receive multicast packet through it's home network, a mobile node MUST join the multicast group in one of two ways. One is based on co-located care-of address, the other is based on the home address (foreign agent care-of address). In both cases, a mobile node tunnels IGMP messages to its home agent, the home agent forwards multicast datagrams down the tunnel to the mobile node. Access network (Wired or Wireless) IP multicast | packets +----+ | | | MN1| V +------+ +------+ | +----+---------------|======|=============| | | +----+ | FA | | HA | V | MN2|---------------|======|=============| |----- +----+ +------+ +------+ Figure 1: Nested tunneling in MIP4 for Multicast In the case of co-located care-of address, the home agent SHOULD tunnel the datagram to this care-of address directly; In the case of foreign agent care-of address, the home agent MUST first encapsulate the datagram in a unicast datagram addressed to the mobile node's home address and then MUST tunnel the resulting datagram (nested tunneling) to the mobile node's care-of address.If there are more than 500 MNs under the same FA, there will be 500 tunnels between HA and FA to transmit multicast packets. Deng Expires December 22, 2008 [Page 3] Internet-Draft Multimob MIP4 June 2008 2. MIPv4 FA CoA multicast tunneling optimization The characteristics of the link between MN and FA are different depending on the types of access network and radio links. So,the multicast optimization between MN and FA should be specific for access network. In this document, a new multicast foreign agent(MFA) is proposed to optimize the multicast tunneling solution of MIPv4. 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 +----+ | | | MN1| V +------+ +------+ | +----+---------------|======| | | | +----+ | MFA |=============| HA | V | MN2|---------------|======| | |----- +----+ +------+ +------+ Figure 2: Optimized MIP4 FA-CoA for Multicast MFA is the termination point of the tunnel from HA. MFA should be very close to ARs or even collocated with ARs. Compared with the current multicast solution of MIPv4, the number of unicasting tunnels for one streams multicast between one pair of MFA and HA will be decreased to only one. This is especially meaningful when one HA serves many MNs with multicast services. Deng Expires December 22, 2008 [Page 4] Internet-Draft Multimob MIP4 June 2008 3. Call flow of Multicast MIP4 FA CoA The call flow of the optimized MIPv4 multicast is shown below: MN p(MFA) n(MFA) HA MR | | | | | | IGMP host membership query | | (0) |< ========================================|< ----------| | | | | | | IGMP host membership report | | (1) |======================================== >|---------- >| | | MC Notify | | | (2) | |< -------------------------| Multicast | | | single | | packets | (3) | multiple | tunnel | |< ----------| (4) | tunnels |< #########################| | (5) |< ============| | | | | | | | | Handover to n(MFA) | | | ------------------------------------------------------------- | RRQ | | | | (6) |---------------------------------------- >| | | RRQ | | | | (7) |< ----------------------------------------| | | | | MC Notify | | (8) | | |< ---------| | | | MC Notify | | | (9) | |< -------------------------| Multicast | | | single | | packets | (10)| multiple | tunnel | |< ----------| (11)| tunnels |< #########################| | (12)|< ============| | | | Figure 3: Call flow of Multicast MIP4 FA CoA (0) HA forwards the IGMP host membership query message down to MNs via the bi-directional tunnels periodically. (1) MNs should report their multicast group membership by the IGMP host 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 MFA with the information of related MN addresses and multicast addresses. It may also put some other streams related messages inside the notification message. MFA will store this information inside the Multicast Serving Table (MST). HA Deng Expires December 22, 2008 [Page 5] Internet-Draft Multimob MIP4 June 2008 will also store the triple-units of (MN, MFA, Multicast Address) in the local cache. (3) HA receives one multicast stream from the multicast router. HA will check the cached (MN, MFA, multicast address) based on the multicast address of incoming multicast stream. (4) HA will tunnel the stream to the related MFA with single tunnel. The Outer IP header is from HA to MFA. The inner IP packet is the original multicast packet. (5) At MFA, it will check the MST and get the addresses of MNs who have subsribes this multicast stream. MFA will make duplication of the received tunnel packet based on the number of related MNs. then, it will replace the destination addresses of the outer tunnel headers with the home address 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 MFA, it will finish RRQ/ RRP procedure firstly with HA. (8) On parallel, HA sends notification to the new MFA with the information of multicast addresses =and MN addresses. The new MFA stores this information inside the (MST) of it's own. (9) HA notifies the old MFA 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, MFA, multicast address) based on the multicast address of incoming multicast stream. (11) The multicast packet will be tunneled to the new MFA accordingly. The Outer IP header is from HA to new MFA. The inner IP packet is the original multicast packet. (12) The new MFA will do the same tunnel duplication and address replacement as step (5) Deng Expires December 22, 2008 [Page 6] Internet-Draft Multimob MIP4 June 2008 4. Operation of Multicast Foreign Agent (MFA) 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. 4.1. Tunnel manipulation The logical packet of the tunnel from HA is showed below: +----------+------------+---------+--------------+---------+ | HA's Addr| MFA'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 MFA's address and HA's address respectively. The inner IP packet is the original IP multicast packet from the corresponding node(CN). In MFA, 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 Home Address(HoA) 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 HoA |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 [RFC3344]. So, the MN do not need to be modified in this solution. 4.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 information is sometimes useful for the stream manipulation. The initiation, update and termination of MST entries should only be done Deng Expires December 22, 2008 [Page 7] Internet-Draft Multimob MIP4 June 2008 based on the notification messages from HA. 4.3. Operation of Multicast notification message The definition of multicast notification message is a specific message or extension to a generic notification message. Detail definition explained as the below. Subtype (TBD) Multicast traffic notification message. MD: Message Direction 1 -- Message sent by the home agent to the foreign agent. A This bit MUST be set to "1" to indicate that the multicast notification message MUST be acknowledged by the foreign agent. Deng Expires December 22, 2008 [Page 8] Internet-Draft Multimob MIP4 June 2008 5. Security Considerations This solution basically does not break the security framework of MIPv4. Because IGMP membership messages should be tunneled, the data traffic between HA and MN should be protected by authentication extension. Notification messages could be protected by HA FA authentication extension. Deng Expires December 22, 2008 [Page 9] Internet-Draft Multimob MIP4 June 2008 6. IANA Considerations This document requests IANA to assign subtype 5 in generic notification message to indicate this message is for the purpose of multicast support. Deng Expires December 22, 2008 [Page 10] Internet-Draft Multimob MIP4 June 2008 7. Conclusion This document extend the generic notification message to notify the extended foreign agent to support multicast traffic in mobile IPv4. Deng Expires December 22, 2008 [Page 11] Internet-Draft Multimob MIP4 June 2008 8. Normative References [Deng08] Deng, H., "Generic Notification Message for Mobile IPv4", draft-ietf-mip4-generic-notification-message-03.txt (work in progress), January 2008. [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. Deng Expires December 22, 2008 [Page 12] Internet-Draft Multimob MIP4 June 2008 Author's Address Hui Deng China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: denghui02@gmail.com Deng Expires December 22, 2008 [Page 13] Internet-Draft Multimob MIP4 June 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 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. Deng Expires December 22, 2008 [Page 14]