MULTIMOB Working Group Hong-Ke Zhang Internet Draft Zhi-Wei Yan Expires: May 2011 Shuai Gao Li-Li Wang Beijing Jiaotong University Qian Wu He-Wu Li Tsinghua University November 8, 2010 Multicast Source Mobility Support in PMIPv6 Network draft-zhang-multimob-msm-01.txt Abstract Proxy Mobile IPv6, specified in RFC 5213, is a network-based mobility protocol. It uses a Mobile Access Gateway (MAG) and a Local Mobility Anchor (LMA) to allow hosts to move around within a domain while keeping their address or address prefix stable [1]. Although the issues of mobile multicast in the PMIPv6 network are being discussed in the Multimob WG, how to provide the service connectivity for the mobile multicast source is still a problem for the PMIPv6. This document discusses the extensions of the PMIPv6 to support the multicast source mobility. Requirements Language 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 [RFC2119]. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 Zhang et al. Expires May,2011 [Page 1] Internet-Draft MSM Support in PMIPv6 Network November 2010 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on May, 2011. 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. Table of Contents 1. Introduction................................................2 2. Overview....................................................3 3. Extensions of PMIPv6........................................4 3.1. MN.....................................................4 3.2. MAG....................................................5 3.3. LMA....................................................5 4. Multicast source mobility procedure.........................5 5. Format of signaling messages................................7 5.1. PBU....................................................7 5.2. PBA....................................................7 5.3. Multicast address option...............................8 6. Security Considerations.....................................9 7. References..................................................9 Authors' Addresses............................................10 Acknowledgment................................................10 1. Introduction Different from MIPv6 [2], 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 MN which is involved in the unicast communication. In order to deploy the multicast service in the PMIPv6 network, many schemes have been Zhang et al. Expires May,2011 [Page 2] Internet-Draft MSM Support in PMIPv6 Network November 2010 proposed [3-6]. However, all of these schemes aim to support the multicast service for the mobile receiver and how to support the multicast source mobility in the PMIPv6 network is not yet discussed. Without doubt, the multicast source mobility is also a very important issue for the deployment of the multicast service. For example, there is an advanced concept based on the Intelligent Transport Systems (ITS) service. In this concept, all the vehicles on the same route are identified by using a GPS or a car-navigation system. The vehicles multicast real-time video information about the transportation through the communication infrastructure like 3G, WiFi to the other vehicles interested in it. We call this advance information 'Future vision' and the similar concept has been proposed in [7]. The multicast source mobility just provides a network distribution functionality (protocol) to realize the above concept. In this document, a multicast source mobility supporting scheme is proposed. In this scheme, the basic PMIPv6 signalings are extended and the LMA which acts as the RP (Rendezvous Point), responses to the join message sent to the source (e.g., MN). The multicast packets are sent from MN to the LMA as the basic PMIPv6 specified. Then these packets are transmitted through the multicast tree established between the LMA and the receivers using the traditional multicast routing protocols. 2. Overview The problem of multicast source mobility was also concerned in the MIPv6 network in which the RPT-based (Rendezvous Point Tree-based) scheme and the SPT-based (Shortest Path Tree-based) scheme are proposed as two solutions [8]. In the RPT-based scheme, the Home Agent (HA) acts as the RP in order to provide the transparency of source mobility. The multicast tree is stable, while the multicast path may not be optimized in this scheme. In the SPT-based scheme, the MN need reconstruct the multicast tree once the L3 (network layer) handover happens. The multicast path can be optimized in this case, however, the frequent handover of the source may lead to the unstability of the multicast tree. The above two schemes can also be used in the PMIPv6 network. For the SPT-based scheme, the SPT can be reconstructed once the MN moves to the new MAG. And for the RPT-based scheme, the LMA can act as the RP for the MN. However, the SPT-based scheme is not suitable in the PMIPv6 network due to the following reasons: ---The PMIPv6 is used to enhance the handover performance for the MN, which moves in the restricted domain. So the LMA and the MAG may not be so far. In other words, the differences between the two paths Zhang et al. Expires May,2011 [Page 3] Internet-Draft MSM Support in PMIPv6 Network November 2010 corresponding to the RPT-based scheme and the SPT-based scheme may not be so evident; ---The stability of the multicast tree is a very important factor for the multicast service, which affects the disruption latency and then the performance of the multicast service during the multicast source mobility. However, in the SPT-based scheme, the multicast tree needs to be reconstructed even the MN moves between two nearby MAGs, which leads to the frequent disruption and low efficiency of the multicast service; ---A mobile multicast source must provide address transparency at two layers: To comply with Reverse Path Forward (RPF) checks, it has to use an address within the source field of the IPv6 basic header, which is in topological agreement with the employed multicast distribution tree. For application transparency, the logical node identifier must be presented as the packet source address to the transport layer at the receiver side. It is a tough problem for the SPT-based scheme because the identifier and the locator of the MN are separated. The MN can only configure the HoA (Home Address) as its identifier and its locator is the address of the MAG. However, the RPT-based scheme can easily solve this problem because the HoA is just anchored at the LMA. Thus, we suggest using the RPT-based scheme to provide the multicast source mobility in the PMIPv6 network. 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. The multicast packets sent by the MN are firstly sent to the LMA as traditional PMIPv6 specified and then the packets are transmitted from the LMA to the receivers according to the multicast routing protocols. 3. Extensions 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. Then the signaling messages and the related processing of basic PMIPv6 should be extended. 3.1. MN In order to provide the multicast service during the MN's movement, the MAG must recognize that the attached MN is a multicast source. This information can be learned by the MAG during the authentication phase for example and the corresponding multicast address must be Zhang et al. Expires May,2011 [Page 4] Internet-Draft MSM Support in PMIPv6 Network November 2010 contained in this information at least. The particular procedure is out of this document. 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". The multicast address is contained in the Multicast address option of the PBU message when the "S" is set to "1". Then the MAG encapsulates the multicast packets into the bi-directional tunnel and sends them to the LMA firstly. 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 session specified by the Multicast address option. The LMA also intercepts the join message and proceeds it for the MN. Then the SPT between LMA and the new receiver can be established. In this way, the multicast service can always be provided through the RPT and the stability of the multicast tree is guaranteed. 4. Multicast source mobility procedure Figure 1 shows the protocol procedure. +-----+ +-----+ +-----+ +-----+ | MN | | MAG1| | LMA | | MAG2| +-----+ +-----+ +-----+ +-----+ | | | | 1) |--- Rtr Sol------>| | | | |------- PBU ----->| | 2) | (Multicast address option) | | | | | | | Accept PBU | | | (Allocate HNP1, act as RP for MN) | | |<------ PBA ------| | |<---- Rtr Adv ----| (HNP1) | | | | | | 3) |==multicast data=>|=multicast data==>| | | | | | | | (process the join message and | Zhang et al. Expires May,2011 [Page 5] Internet-Draft MSM Support in PMIPv6 Network November 2010 | |establish the multicast routing tree)| | | | | 4) |---------------------- Rtr Sol------------------------->| | | |<----- PBU -------| | | (Multicast address option)| | | | | 5) | | Accept PBU | | | (Allocate HNP1, refresh tunnel) | | | | | | | |------- PBA ----->| | | | (HNP1) | |<-------------------- Rtr Adv ------------------------- | 6) |==================|===multicast data=|=================>| | | |<=multicast data==| | | (continue the packet transmission) | | | | | Figure 1: Multicast Source Mobility Procedure The detailed descriptions are as follows: 1) The MN connects to the MAG1 initially and sends Router Solicitation (RS) message to the MAG1; 2) When the attachment of MN is detected by the MAG1, an extended PBU message is sent to the LMA. Because the LMA finds the S flag and the Multicast address option 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. And then the LMA sends back a PBA message to the MAG1. Afterwards, the bi-directional tunnel is established between the MAG1 and the LMA; 3) The multicast packets are sent from the MN to the LMA as the basic PMIPv6 specified. Since the multicast routing tree will be established between the LMA and the receiver, the packets are transmitted between the LMA and the receiver according to the multicast routing protocol; 4) When the MN moves to the MAG2, the multicast related information is also learned by the MAG2; 5) Then the LMA-MAG bi-directional tunnel is refreshed, however, the multicast routing tree between the LMA and the receiver is kept unchanged; Zhang et al. Expires May,2011 [Page 6] Internet-Draft MSM Support in PMIPv6 Network November 2010 6) The multicast packets transmission continues after the handover and the mobility of the source is transparent to the receiver. 5. Format of signaling messages 5.1. PBU The format of the PBU message is shown in Figure 2. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|M|R|P|S| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Multicast address option . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: PBU Message Format S flag and Multicast address option 1-bit "Multicast source identification" flag is used to identify whether this MN is a multicast source. When this flag is set to "1", the related multicast address is attached in the Multicast address option. 5.2. PBA The format of the PBA message is shown in Figure 3. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status |K|R|P|S| Res. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . Zhang et al. Expires May,2011 [Page 7] Internet-Draft MSM Support in PMIPv6 Network November 2010 . Multicast address option . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: PBA Message Format S flag and Multicast address option The S flag is set to "1" if the LMA can act as the RP for the multicast service identified by the Multicast address option. The LMA will not act as the RP for the multicast service if the S flag is set to "0" or there is no S flag in the PBA message. How to provide the multicast source mobility service in the scenario with the LMA not acting as the RP will be discussed in the future. 5.3. Multicast address option The format of Multicast address option is illustrated in Figure 4. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Multicast address + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Format of Multicast Address Option Option Type TBD Option Length 8-bit unsigned integer indicating the length of the option in octets, excluding the option type and option length fields. This field can be set to 16 and 4 for the IPv6 and IPv4 multicast addresses, respectively. Multicast address Zhang et al. Expires May,2011 [Page 8] Internet-Draft MSM Support in PMIPv6 Network November 2010 The multicast address related to the multicast session provided by the MN. 6. Security Considerations This document does not introduce any security considerations. 7. 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, 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. [7] K. Sato, M. Katsumoto, T. Miki. "Future vision distribution system and network", This paper appears in: IEEE International Symposium on Communications and Information Technology, 2004. ISCIT 2004, vol.1, pp: 274 - 279, October 2004. [8] T. Schmidt, M. Waehlisch and G. Fairhurst. "Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey", RFC 5757, February 2010. Zhang et al. Expires May,2011 [Page 9] Internet-Draft MSM Support in PMIPv6 Network November 2010 Authors' Addresses Hong-Ke Zhang, Zhi-Wei Yan, Shuai-Gao, Li-Li Wang National Engineering Lab for NGI Interconnection Devices Beijing Jiaotong University, China Phone: +861051685677 Email:gaoxlh@gmail.com 06120232@bjtu.edu.cn 09111044@bjtu.edu.cn shgao@bjtu.edu.cn Qian Wu, He-Wu Li Network Research Center Tsinghua University, China Phone: +861062772375 Email:wuqian@cernet.edu.cn lihewu@cernet.edu.cn Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Zhang et al. Expires May,2011 [Page 10]