MULTIMOB Working Group Hong-Ke Zhang Internet Draft Zhi-Wei Yan Expires: September 2011 Shuai Gao Li-Li Wang Beijing Jiaotong University Qian Wu He-Wu Li Tsinghua University March 14, 2011 Multicast Source Mobility Support in PMIPv6 Network draft-zhang-multimob-msm-02.txt Abstract Proxy Mobile IPv6 (PMIPv6), specified in RFC 5213 [1], is a network- based mobility management 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. Although the issues of mobile multicast in the PMIPv6 network are being discussed in the Multimob WG, how to provide the service connectivity when the multicast source is moving is still a problem for the PMIPv6. This document proposes and analyzes the potential solutions of the multicast source mobility in PMIPv6. 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 September,2011 [Page 1] Internet-Draft MSM Support in PMIPv6 Network March 2011 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September, 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.................................................3 2. Multicast Source mobility in PMIPv6..........................3 2.1. Any Source Multicast....................................4 2.1.1. LMA-based scheme...................................4 2.1.2. MAG-based scheme...................................5 2.2. Source-Specific Multicast...............................5 2.2.1. LMA-based scheme...................................5 2.2.2. MAG-based scheme...................................6 2.3. LMA-based vs. MAG-based.................................7 3. Extensions of PMIPv6.........................................8 3.1. MAG.....................................................8 3.2. LMA.....................................................9 4. Format of signaling messages.................................9 4.1. PBU.....................................................9 4.2. PBA....................................................10 4.3. Multicast address option...............................10 5. Security Considerations.....................................11 6. References..................................................11 Authors' Addresses.............................................13 Acknowledgment.................................................13 Zhang et al. Expires September,2011 [Page 2] Internet-Draft MSM Support in PMIPv6 Network March 2011 1. Introduction Different from Mobile IPv6 (MIPv6) [2], PMIPv6 was proposed to support the network-based mobility management. The entities in the PMIPv6 have the responsibilities to track the Mobile Node (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 proposed [3-6]. However, all of these schemes aim to support the multicast service for the mobile receiver. How to support the multicast source mobility in the PMIPv6 network is a newly planned work in the Multimob WG. 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. This advance information is called as 'future vision' [7]. The multicast source mobility is one of the core supporting schemes to realize the above functions. In this document, the potential solutions of the multicast source mobility in PMIPv6 are proposed and analyzed. 2. Multicast Source mobility in PMIPv6 In PMIPv6 base solution, the LMA and the MAG are two most important functional entities. According to different packet transmission paths supporting multicast source mobility, two basic schemes are proposed in this document. In the first case, all the multicast packets sent out from the MN are directed to the LMA firstly and then transmitted to the receivers according to the basic multicast routing protocols, such as Protocol Independent Multicast-Sparse Mode (PIM-SM). While in the second case, the packets sent out from the MN can be directly transmitted from the MAG to the receivers. For convenience, these two schemes are denoted as the LMA-based scheme and the MAG-based scheme, respectively. Figure 1 shows the architecture of the multicast source mobility in PMIPv6 using this two schemes. As shown in Figure 1, the paths among the MAGs and the LMA represented by lines ("||") indicate the tunnels in base PMIPv6, while the path depicted with stars ("*") denotes the multicast tree of the LMA-based scheme and the path pictured with circles ("o") shows the multicast tree of the MAG-based scheme. Zhang et al. Expires September,2011 [Page 3] Internet-Draft MSM Support in PMIPv6 Network March 2011 +----+ |LMA | * * * * * * * * *{Receiver} +----+ o | o /*/ \\ o /*/ \\ o +-------/*/-------\\-----------o-------+ ( /*/ IPv6 \\ o ) ( /*/ Network \\ o ) +----/*/-------------\\-----o----------+ /*/ \\ o /*/ \\ o | |o +----+ +----+ |MAG1| |MAG2| +----+ +----+ | | {MS}----------------->{MS} Figure 1: Architecture of the multicast source mobility in PMIPv6 In Section 2, the above two basic schemes of multicast source mobility will be discussed in the scenarios of Any Source Multicast (ASM) and Source-Specific Multicast (SSM), respectively. Also some suggestions about the choice of multicast source mobility solutions are given. 2.1. Any Source Multicast These two schemes can be differently deployed in this scenario. 2.1.1. LMA-based scheme In the PMIPv6 network, the LMA is just the topological anchor point of the source's Home Address (HoA). In this way, the join message (HoA,G) is delivered to the LMA firstly and the LMA-based multicast tree can be established. In this case, the LMA allows a mobile source to continuously send data to the group through the LMA-MAG tunnel firstly. And then the packets are transmitted from the LMA to the receivers according to the multicast routing protocols. When the MN hands over from one MAG to another, only the PMIPv6 tunnel is updated and the movement of source is transparent to the receivers. Zhang et al. Expires September,2011 [Page 4] Internet-Draft MSM Support in PMIPv6 Network March 2011 When the handover from the Rendezvous Point Tree (RPT) to the Shortest Path Tree (SPT) happens, the join message destined for the HoA is delivered to the LMA firstly. After the encapsulation, the join message is redirected to the MAG through the LMA-MAG tunnel. Then the MAG parses the join message and establishes the related multicast state. However, the path between the LMA and the MN is still used for the multicast packets transmission. Although the SPT handover finishes, the practical path is not the topological shortest path tree due to the existence of PMIPv6 tunnel. 2.1.2. MAG-based scheme In the case, the MAG sends the packets originated by the MN to the RP directly but not through the PMIPv6 tunnel. For this, the PMIPv6 packet transmission procedure needs to be adjusted in the multicast case. In particular, when the MAG receives the packets destined for a multicast group, it should not encapsulate them in the MAG-LMA tunnel but directly tunnel them to the RP from the outgoing interface. For this, the MAG should ignore and discard all the join messages sent to the HoA. In this way, all the multicast packets originated by the MN can always be sent through the tunnel between the MAG and the RP. For the receivers, the original join message is sent to the RP for the (*,G) multicast service. Then the RP can redirect the multicast packets received from the MAG to the receivers according to the multicast routing protocol. When the handover of the RPT to the SPT happens, the procedure is similar to the statement in section 2.2.2. 2.2. Source-Specific Multicast The SSM is denoted by the multicast source address and the multicast group address (S,G). Receivers can receive the multicast data by subscribing to the channel (S,G). These two schemes can also be differently deployed in this scenario as the same as in the ASM scenario. 2.2.1. LMA-based scheme In SSM, the multicast receivers actively send the (S,G) subscribe message to establish the SPT from the specific source to the receivers. Accordingly, the SSM scenario with the LMA-based scheme is similar to the SPT handover in the ASM scenario with the LMA-based scheme. Zhang et al. Expires September,2011 [Page 5] Internet-Draft MSM Support in PMIPv6 Network March 2011 In this case, the subscribe message destined for the HoA is delivered to the LMA firstly. After the encapsulation, the subscribe message is redirected to the MAG through the LMA-MAG tunnel. Then the MAG parses the subscribe message and establishes the related multicast state. However, the current SPT path is not the topological shortest path tree due to the existence of PMIPv6 tunnel. 2.2.2. MAG-based scheme When the MAG-based scheme is adopted in the SSM, there are more complex issues. All the multicast listeners are forced to know the address of the MAG corresponding to the multicast service related HoA. For this, the following three important issues should be solved. 1) How can the MAG/LMA know all the receivers' addresses? 2) How can the MAG/LMA notify all the receivers about the current MAG the MN attached when the handover happens? 3) How can the MAG/LMA maintain the freshest list of all the receivers or DRs (Designated Routers)? Then, two possible approaches are listed as follows: Passive approach: When a receiver wants to subscribe a multicast group identified by (HoA,G), the related report message is sent to its attached DR. The DR then constructs a subscribe message destined for the HoA and sends this message to its upstream router. As the anchor point of this HoA, the LMA receives the subscribe message. The first subscribe message is transmitted to the MN through the LMA-MAG tunnel. However, the MAG when receiving the subscribe message must notify the receiver that the (HoA,G) identified multicast channel is the same channel identified by (MAG,HoA,G). Then the DR resubscribes the multicast group as the new subscribe message is sent to the MAG. Afterwards, the new SPT is established between the receiver and the MAG. When the MN hands over to a new MAG, all the receivers have to be notified with the new (MAG,HoA,G) and the SPT should be refreshed. Optionally, the notification procedure of the address of current MAG can also be executed by the LMA. Active approach: When a receiver wants to subscribe a multicast group identified by (HoA,G), it should query for the topological location of the (HoA,G) related multicast source firstly. When the querying message is received by the LMA, the LMA notifies the receiver about the MAG's address. Then the DR resubscribes the multicast group as the new subscribe message (MAG,HoA,G) is sent to the MAG. Afterwards, Zhang et al. Expires September,2011 [Page 6] Internet-Draft MSM Support in PMIPv6 Network March 2011 the new SPT is established between the receiver and the MAG. When the MN hands over to a new MAG, all the receivers have to be notified with the new (MAG,HoA,G) and the SPT should be refreshed. 2.3. LMA-based vs. MAG-based In general, the LMA-based scheme is easy to implement and has very low handover overhead and delay due to movement of the multicast source, however, the packets transmission in this scheme incurs packets transmission overhead and latency due to the sub-optimized routing and tunneling overhead. Although the packet transmission efficiency can be improved in the MAG-based scheme, it needs a high handover overhead and delay and it is difficult to implement for the essential extensions of the PMIPv6 protocol and the multicast routing protocol. Even if the multicast tree has been established successfully, it needs to be reconstructed even the MN moves between two nearby MAGs, which may lead to frequent disruption and low efficiency of the multicast service. The detailed comparison of the two schemes in the different scenarios is described in Table 1. Table 1: Comparison of the two schemes in different scenarios +------------------------------------------------------------------------------------------------+ | | PMIPv6 | PIM-SM | handover | handover | Path | | | Extension | Extension | delay | overhead | | |------------------------------------------------------------------------------------------------| | | | RPT | / | / | low | low | worst | | | LMA-based |------------------------------------------------------------------------------| | | | SPT | / | / | low | low | medium | | ASM |------------------------------------------------------------------------------------------| | | | RPT | MAG | / | low | low | better than | | | MAG-based | | | | | | LMA-based RPT| | | |------------------------------------------------------------------------------| | | | SPT | MAG/LMA | multicast router| high | high | best | | | | | | & receiver DR | | | | |------------------------------------------------------------------------------------------------| | | | | | | | | | | LMA-based | / | / | low | low | medium | | | | | | | | | | SSM |------------------------------------------------------------------------------------------| | | | | multicast router| | | | | | MAG-based | MAG/LMA | & | high | high | best | | | | | receiver DR | | | | +------------------------------------------------------------------------------------------------+ Zhang et al. Expires September,2011 [Page 7] Internet-Draft MSM Support in PMIPv6 Network March 2011 As shown in Table 1, the paths of the MAG-based SPT both in ASM and SSM scenarios are the most optimal, but the establishment of the MAG- based SPT is difficult and also incurs high handover delay and handover overhead. And the MAG-based SPT scheme in ASM and SSM needs to extend multicast routing protocols, which may be outside of the Multimob WG's scope and then difficult to implement. Thus, it is suggested that the MAG-based SPT scheme should not be considered. While the LMA-based schemes, not only in the ASM case but also in the SSM case, are simpler for implementation than other schemes, because extra extensions of the PMIPv6 protocol and the multicast routing protocol are unnecessary. Besides, it can be seen from the Table 1 that the path of the MAG-based RPT is better than the LMA-based RPT in ASM and is also a good choice for mobile multicast service. This is because that the packets can be transmitted from the MAG to the RP directly rather than the MAG-LMA tunnel. However, it is required the MAG should be extended accordingly. In real applications, the LMA- based scheme and the MAG-based scheme in the ASM RPT scenario can be selected according to network conditions and mobility characteristics of the MN. Here we suggest introducing a negotiation capability between the MAG and the LMA by some simple extensions of the PMIPv6 protocol specified in Section 3. The basic principle of the negotiation is that the LMA with more global network information than the MAG has the right to decide which schemes should be adopted. But the specific negotiation approach is out of this document. 3. Extensions of PMIPv6 The signaling messages and the related processing of basic PMIPv6 should be extended in order to notify the multicast source-related information from the MAG to the LMA. Besides, the extensions are used for the negotiation between the MAG-based scheme and the LMA-based scheme for a particular multicast source. 3.1. MAG In order to provide the multicast service during the MN's movement, the MAG must recognize that the attached MN is a multicast source and the corresponding multicast address must also be learned. These information can be learned by the MAG during the authentication phase for example. The particular procedure is out of this document. 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 when the "S" is set to "1". Besides, a one bit "J" flag is added to indicate whether the MAG has the ability to adopt the MAG- Zhang et al. Expires September,2011 [Page 8] Internet-Draft MSM Support in PMIPv6 Network March 2011 based scheme. When the MAG finds that the "J" flag is set to "1" in the extended Proxy Binding Acknowledgement (PBA) message from the LMA, the MAG-based scheme can be used for the MN. Otherwise, the LMA-based scheme is adopted for multicast service. 3.2. LMA When receiving the extended PBU message, the LMA establishes a tunnel to the MAG as specified in PMIPv6. And if the "J" flag is set with "1" in the extended PBU message, the LMA will judge whether the MAG should adopt the MAG-based scheme and indicate the MAG with the "J" flag in the extended PBA message. If the "J" flag is set with "0" in the extended PBU message, the LMA will also set the "J" flag with "0" in the extended PBA message. 4. Format of signaling messages 4.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|J| 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 mobile multicast source. When this flag is set to "1", the related multicast address is attached in the Multicast address option. J flag Zhang et al. Expires September,2011 [Page 9] Internet-Draft MSM Support in PMIPv6 Network March 2011 1-bit "MAG join" flag is used to identify whether the MAG has the ability to support the MAG-based scheme. 4.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|J|Res. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Multicast address option . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: PBA Message Format S flag and Multicast address option 1-bit "Multicast source identification" flag is used to identify whether this MN is a mobile multicast source. The flag is set to "1" only if the corresponding PBU had the S flag set to "1". And when this flag is set to "1", the related multicast address is attached in the Multicast address option. J flag 1-bit "MAG join" flag is used to identify whether the MAG should establish the MAG-based multicast tree. When the J in the PBA is set to "1" as the same value in the PBU message, the MAG will establish the MAG-based multicast tree. However, when the J in the PBA is set to "0" but its value in PBU is "1", the MAG-based scheme is not allowed by the LMA. The reason of the allowance of the MAG-based multicast tree establishment at the LMA is that the LMA has more information than the MAG to make this decision. 4.3. Multicast address option The format of Multicast address option is illustrated in Figure 4. Zhang et al. Expires September,2011 [Page 10] Internet-Draft MSM Support in PMIPv6 Network March 2011 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: 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 The multicast address related to the multicast session provided by the MN. 5. Security Considerations This document does not introduce any security considerations. 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-07, December 29, 2010. [4] H. Asaeda, P. Seite and J. Xia. "PMIPv6 Extensions for Multicast", draft-asaeda-multimob-pmip6-extension-04, September 9, 2010. Zhang et al. Expires September,2011 [Page 11] Internet-Draft MSM Support in PMIPv6 Network March 2011 [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-03, November 08, 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. Zhang et al. Expires September,2011 [Page 12] Internet-Draft MSM Support in PMIPv6 Network March 2011 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: +861051684274 Email:hkzhang@bjtu.edu.cn 06120232@bjtu.edu.cn shgao@bjtu.edu.cn 09111044@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 September,2011 [Page 13]