MULTIMOB Working Group Hong-Ke Zhang Internet Draft Zhi-Wei Yan Expires: December 2010 Hua-Chun Zhou Jian-Feng Guan Si-Dong Zhang Beijing Jiaotong University June 10, 2010 Multicast Source Mobility Support in PMIPv6 Network draft-zhang-multimob-msm-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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, 2010. Zhang et al. Expires December,2010 [Page 1] Internet-Draft MSM Support in PMIPv6 Network June 2010 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract The NetLMM WG has specified Proxy Mobile IPv6 (PMIPv6) for network- based localized mobility management, taking basic support for registration, de-registration and handover of Mobile Node (MN) into account in the RFC 5213 [1]. Although the mobile multicast provision in the PMIPv6 network is being discussed in the multimob WG, how to provide the service connectivity during the movement of MN which is a multicast source, is a problem still up in the air for the PMIPv6. This document discusses the extension of the PMIPv6 to support the multicast source mobility. 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 5213 [1]. Table of Contents Copyright Notice..................................................2 Abstract..........................................................2 1. Introduction...................................................3 2. Problem statement..............................................3 3. Extension of PMIPv6............................................4 3.1. MN........................................................4 3.2. MAG.......................................................4 3.3. LMA.......................................................5 4. Multicast source mobility procedure............................5 4.1. SPT between LMA and receiver..............................5 4.2. SPT between MN and receiver...............................6 5. Security Considerations........................................8 Zhang et al. Expires December,2010 [Page 2] Internet-Draft MSM Support in PMIPv6 Network June 2010 6. References.....................................................8 Author's Addresses................................................9 Acknowledgment....................................................9 1. Introduction Be different with the MIPv6[2], the PMIPv6 [1] was proposed to support the network-based mobility management. The entities in the PMIPv6 have the responsibility to track the MN, update the location of the MN and redirect the packets to and from the MN. However, the basic PMIPv6 protocol only solves the mobility management for the single MN, which is only focus on the unicast transmission. In order to deploy the multicast service in the PMIPv6 network, many schemes are proposed [3-6]. However, all of these schemes focus on how to support the multicast service for the mobile receivers. While how to support the multicast source mobility in the PMIPv6 network is not discussed yet. So in this document, a multicast source mobility supporting scheme is proposed. In this scheme, the basic PMIPv6 signaling is extended and the Local Mobility Anchor (LMA) which acts as the RP (Rendezvous Point), responses to the join message sent to the source (MN). Then the multicast packets are sent from MN to the LMA as the basic PMIPv6 specified, however, the packets are transmitted through the multicast tree established between LMA and the receivers using the traditional multicast routing protocols. 2. Problem statement When the MN is the multicast source, all the multicast packets will be transmitted through the Shortest Path Tree (SPT) from the source to the receiver. In this way, the stability of the multicast tree decreases with the increased handover rates of the MN. That is because the multicast tree must be refreshed when the root of the multicast tree changes its location. However, according to the basic PMIPv6 specification, all the packets to and from the MN must be transmitted to the LMA through the LMA-MAG tunnel firstly. That means the LMA is a fixed point on the way to and from the MN. So we can set the LMA to be the RP and the proxy source of the multicast. And the following packet transmission method is proposed in this document. The multicast packets sent by the MN is firstly sent to the LMA as traditional PMIPv6 specified and then the packets are transmitted according to the multicast routing protocols from the LMA to the receivers. However, the packets transmission proposed above incurs serious packets transmission overhead and latency due to the sub-optimized Zhang et al. Expires December,2010 [Page 3] Internet-Draft MSM Support in PMIPv6 Network June 2010 routing and tunneling overhead. So the MN should decide how to establish the multicast tree: when the MN hands over between MAGs in a low rate, the multicast join should be processed by the MN itself and the SPT should be established between the MN and the receivers, while when the MN hands over between MAGs in a high rate, the method proposed above should be used. 3. Extension of PMIPv6 In order to support the mobility of the multicast source, the LMA is selected to be the RP of the mobile multicast service. Besides, the join message is processed by the LMA or the MN, which is decided by the MN and indicated to the LMA. Then the signaling message and the related processing should be extended. 3.1. MN In order to provide the multicast service even during its movement, the MN should indicate this information to the attached MAG through the interface between MAG and MN. For example, the MAG may get this information during the authentication phase. In this document, we do not specify how to get this information, but the MAG must get the multicast address corresponding to the multicast service provided by the MN and the indication of whether the MN wants to process the join message itself. 3.2. MAG When the MAG finds that the attached MN is a multicast source, it should send the extended Proxy Binding Update (PBU) message to the LMA. In the extended PBU message, a one bit "S" flag is added and set to "1", which means the MN is a multicast source. The multicast address is contained in the PBU message as a Multicast Address option when the "S" is set to "1". Besides, a one bit "J" flag is added to indicate whether the LMA should receive and process the join message sent to the MN. When the MAG finds that the "J" flag is set to "1", it should not encapsulate the multicast packets into the bi- directional tunnel but transmit them according to the traditional multicast routing protocol. In this case, the MAG has to set up the multicast routing table according to the traditional multicast routing protocol. Zhang et al. Expires December,2010 [Page 4] Internet-Draft MSM Support in PMIPv6 Network June 2010 3.3. LMA When receiving the extended PBU message, the normal PMIPv6 tunnel is established between LMA and MAG. Besides, the LMA recognizes that it should act as the RP for the multicast specified by the Multicast Address option. Besides, when the "J" flag is set to "1", the LMA who receives the join message sent to the MN will response to it and establish the SPT between LMA and the receiver. In order to find the RP for the receiver, the corresponding information of "Multicast address<->address of RP" has to be learned by the receiver. And this is out of the scope of the document. 4. Multicast source mobility procedure According to the indication from the MN, different multicast tree establishment methods are adopted. 4.1. SPT between LMA and receiver Fig.1 shows the protocol procedure for the MN which hands over between MAGs in a high rate. +-----+ +-----+ +-----+ +-----+ | MN | | MAG1| | LMA | | MAG2| +-----+ +-----+ +-----+ +-----+ | | | | 1) |--- Rtr Sol------>| | | ("S" and "J=1") |------- PBU ----->| | 2) | | Accept PBU | | | (Allocates HNP1, acts as RP for MN) | |<------ PBA ------| | |<---- Rtr Adv ----| (HNP1) | | | | | | 3) |==multicast data=>|=multicast data==>| | | | | | | | (process the join and establish SPT)| | | | | 4) |------------- Rtr Sol ("S"and "J=1")------------------->| | | |<----- PBU -------| | | | | 5) | | Accept PBU | | | (Allocates HNP1, refreshes tunnel | | | | | | | |------- PBA ----->| | | | (HNP1) | Zhang et al. Expires December,2010 [Page 5] Internet-Draft MSM Support in PMIPv6 Network June 2010 |<-------------------- Rtr Adv ------------------------- | 6) |==multicast data=>|=multicast data==>| | | | | | | | (continue the packet transmission) | | | | | Figure 1 msm in the first case 1) As illustrated in the figure, the "S" bit ,the multicast address and the "J" flag can be contained in the Router Solicitation(RS) message sent from the MN to the MAG; 2) When the attachment of MN is detected by the MAG1, an extended PBU message is sent to the LMA. And then the bi-directional tunnel is established between MAG1 and LMA. Because the LMA finds the extended information contained in the PBU message, the LMA acts as the RP of the multicast service corresponding to the multicast address and responses to the join message sent to the MN; 3) The multicast packets are sent from the MN to the LMA as the basic PMIPv6 specified. Since the SPT will be established between LMA and the receiver, the packets are transmitted according to the multicast routing protocol between LMA and the receiver; 4) When the MN moves to the MAG2, the multicast related information is transmitted to the new MAG; 5) Then the LMA-MAG bi-directional is refreshed, however, the SPT between LMA and the receiver is not affected; 6) So the multicast packets transmission is continued after the handover and the mobility of the source is transparent to the receiver. 4.2. SPT between MN and receiver Fig.2 shows the protocol procedure for the MN which hands over between MAG in a low rate. +-----+ +-----+ +-----+ +-----+ | MN | | MAG1| | LMA | | MAG2| +-----+ +-----+ +-----+ +-----+ | | | | 1) |--- Rtr Sol------>| | | ("S" and "J=0") |------- PBU ----->| | 2) | | Accept PBU | Zhang et al. Expires December,2010 [Page 6] Internet-Draft MSM Support in PMIPv6 Network June 2010 | | (Allocates HNP1, acts as RP for MN) | |<------ PBA ------| | |<---- Rtr Adv ----| (HNP1) | | | | | | 3) |==multicast data=>|=multicast data==>| | (process the join and establish SPT) | | | | | | 4) |------------- Rtr Sol ("S" and "J=0")------------------>| | | |<----- PBU -------| | | | | 5) | | Accept PBU | | | (Allocates HNP1, refreshes tunnel | | | | | | | |------- PBA ----->| | | | (HNP1) | 6) |<-------------------- Rtr Adv ------------------------- | (refreshes the SPT) | | | | | | | Figure 2 msm in the second case 1) As illustrated in the figure, the "S" bit ,the multicast address and the "J" flag can be contained in the RS message sent from MN to the MAG; 2) When the attachment of MN is detected by the MAG1, an extended PBU message is sent to the LMA. And then the bi-directional tunnel is established between MAG1 and LMA. Because the LMA finds the extended information contained in the PBU message, the LMA acts as the RP of the multicast service corresponding to the multicast address but it will not response to the join message sent to the MN; 3) The multicast packets are sent from the MN to the LMA as the basic PMIPv6 specified firstly. But when the LMA redirects the join message to the MN, the SPT is established between MN and the receiver and the following packets are transmitted through the optimized path; 4) When the MN moves to the MAG2, the multicast related information is transmitted to the new MAG; 5) Then the LMA-MAG bi-directional is refreshed; 6) However, the SPT must be refreshed because the root of the multicast tree moves to a different location. Zhang et al. Expires December,2010 [Page 7] Internet-Draft MSM Support in PMIPv6 Network June 2010 5. Security Considerations The MAG should be responsible for the multicast service management for the mobile source because the packets may be not transmitted to the LMA. 6. References [1] Gundavelli, et al., Proxy Mobile IPv6, RFC5213, August 2008. [2] David B. Johnson, Charles E. Perkins and Jari Arkko, Mobility Support in IPv6, RFC 3775, June 2004. [3] T C. Schmidt, M. Waehlisch and S. Krishnan, Base Deployment for Multicast Listener Support in PMIPv6 Domains, draft-ietf- multimob-pmipv6-base-solution-00, February 24, 2010. [4] H. Asaeda, P. Seite and J. Xia, PMIPv6 Extensions for Multicast, draft-asaeda-multimob-pmip6-extension-03, March 8, 2010. [5] Seil Jeon and Younghan Kim, Mobile Multicasting Support in Proxy Mobile IPv6, draft-sijeon-multimob-mms-pmip6-02.txt, March 4, 2010. [6] T C. Schmidt, M. Waehlisch, R. Koodli and G. Fairhurst, Multicast Listener Extensions for MIPv6 and PMIPv6 Fast Handovers, draft-schmidt-multimob-fmipv6-pfmipv6-multicast-01, March 06, 2010. Zhang et al. Expires December,2010 [Page 8] Internet-Draft MSM Support in PMIPv6 Network June 2010 Author's Addresses Hong-Ke Zhang, Zhi-Wei Yan, Hua-Chun Zhou, Si-Dong Zhang NGI Research Center Beijing Jiaotong University of China Phone: +861051685677 Email:hkzhang@bjtu.edu.cn 06120232@bjtu.edu.cn hchzhou@bjtu.edu.cn sdzhang@center.njtu.edu.cn Jian-feng Guan Institute of Networking Technology, Beijing University of Post and Telecommunication Beijing, China, 100876 Phone: +86 10 62281007 Email: jfguan@bupt.edu.cn Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Internet-Draft MSM Support in PMIPv6 Network June 2010