MULTIMOB Working Group Hong-Ke Zhang Internet Draft Zhi-Wei Yan Expires: January 2012 Shuai Gao Li-Li Wang Beijing Jiaotong University Qian Wu He-Wu Li Tsinghua University July 22, 2011 Multicast Source Mobility Support in PMIPv6 Network draft-zhang-multimob-msm-03.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 January, 2012 [Page 1] Internet-Draft MSM Support in PMIPv6 Network July 2011 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on January, 2012. 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. Problem statement............................................3 3. Multicast source mobility scheme in PMIPv6...................4 3.1. Data transmission through tunneling.....................4 3.2. Data transmission after tunneling.......................8 4. Extensions of PMIPv6.........................................9 4.1. MAG....................................................10 4.2. LMA....................................................10 5. Format of signaling messages................................10 5.1. PBU....................................................10 5.2. PBA....................................................11 5.3. Multicast address option...............................11 6. Security Considerations.....................................12 7. References..................................................12 Authors' Addresses.............................................14 Acknowledgment.................................................14 Zhang et al. Expires January, 2012 [Page 2] Internet-Draft MSM Support in PMIPv6 Network July 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. Problem statement In PMIPv6 base solution, the LMA and the MAG are two most important functional entities. The LMA is the home agent for the MN in a PMIPv6 domain. It is the topological anchor point for the MN's home network prefix(es) and is the entity that manages the MN's binding state. The MAG is a function on an access router that manages the mobility- related signaling for an MN that is attached to its access link. It is responsible for tracking the MN's movements to and from the access link and for signaling the MN's LMA. Therefore, the topological location of the MN is not equal to the actual location in the PMIPv6 networks, which brings some problems for the multicast packet transmission. And according to the statements in the Section 6.10.5 in RFC5213, when the MAG receives a packet from an MN connected to its access link, to a destination that is not directly connected, the packet MUST be forwarded to the LMA through the bi-directional tunnel established between the MAG and the MN's LMA. And in Section 6.3 in RFC5213 it is assumed that the link between the MN and the MAG have Zhang et al. Expires January, 2012 [Page 3] Internet-Draft MSM Support in PMIPv6 Network July 2011 multicast capability. However, there is no related description on the transmission of the multicast data in RFC5213, that is, there is no scheme about the multicast data forwarding. Thus, the MAG does not explicitly support the multicast communication. When the multicast traffic flows arrive at the MAG, for there is no Multicast Forwarding Information Base (MFIB) on the MAG, it will not be forwarded or transmitted through the bi-directional tunnel between the MAG and the LMA and then these packets would be simply discarded by the MAG. And even though the multicast packets can be transmitted to the LMA by some special processing, whether the LMA could carry out the functionality of the Designated Router (DR) can not be guaranteed. That is, whether the LMA can execute the source registration to the Rendezvous Point (RP) in the Any Source Multicast (ASM) scenario is not sure. And similarly in the Source-Specific Multicast (SSM) case, whether the LMA could forward the packets received from the tunnel interface to the other multicast router according to the related MFIB is also not sure. It is possibly because that the LMA is not directly connected to the source and the network prefix of the LMA's interface address is different from the Home Network Prefix (HNP) of the MN. In Section 3, the above mentioned problems of multicast source mobility in PMIPv6 will be discussed and also some possible solutions are proposed. 3. Multicast source mobility scheme in PMIPv6 In this section, according to the problem statement in Section 2 and the path of the multicast packet transmission, it is divided into two parts to describe the scheme of the multicast source mobility in PMIPv6. 3.1. Data transmission through tunneling Because the MAG does not explicitly support the multicast communication, in order to make the multicast data be forwarded or transmitted through the bi-directional tunnel between the MAG and the LMA based on the PMIPv6 protocol, two possible solutions for that are given as follows. Solution I: some extensions on the PMIPv6 are required for the transmission of the multicast data. By establishing multicast forwarding states on the MAG based on the PMIPv6, the multicast data sent by the mobile source can be forwarded through the LMA-MAG tunnel to the LMA after receiving this packet on the MAG. That is, after the MAG builds the PMIPv6 tunnel and adds route for the anycast packets originated from or destined to the MN, it should also update the Zhang et al. Expires January, 2012 [Page 4] Internet-Draft MSM Support in PMIPv6 Network July 2011 Multicast Forwarding Cache (MFC) for the multicast traffic. Figure 1 shows the detailed procedure of this solution. +-----+ +-----+ +-----+ | MN | | MAG | | LMA | +-----+ +-----+ +-----+ | | | 1) |--- Rtr Sol-------->| | | |------- PBU ----->| 2) | (Multicast address option) | | | | | Accept PBU | | (Allocate HNP, | | setup BCE and Tunnel) | |<------ PBA ------| | | (HNP, Group) | 3) | Accept PBA | | (Set Up Tunnel | | and Routing, Update MFC) | |<---- Rtr Adv ------| | | | | 4) |-- Multicast Data-->|=Multicast Data==>| | | | Figure 1: Procedure of extending the PMIPv6 The detailed descriptions are as follows: 1) The MN connects to the MAG initially and sends Router Solicitation (RS) message to the MAG; 2) When the attachment of MN is detected by the MAG, it obtains the group address as well as LMAA and MN_ID from the profile. Then an extended Proxy Binding Update (PBU) message is sent to the LMA. Because the LMA finds the Multicast address option contained in the PBU message, the LMA decide whether the MN is authorized to send multicast data to the group address. And then the LMA sends back an extended Proxy Binding Acknowledgement (PBA) message to the MAG. Afterwards, the tunnel is established in the LMA; 3) The MAG on receiving the PBA message sets up its endpoint of the bi-directional tunnel to the LMA and then sets up the forwarding for the MN's unicast traffic. At the same time, in order to support multicast source mobility, the MAG should also update the MFC in the kernel. And then it sends Router Advertisement (RA) Zhang et al. Expires January, 2012 [Page 5] Internet-Draft MSM Support in PMIPv6 Network July 2011 message to the MN on the access link advertising the MN's HNP as the hosted on-link prefix; 4) The same as the specification in RFC5213, when the MAG receives a multicast packet from an MN connected to its access link, to a multicast destination that has been authorized by the LMA, the MAG will forward this packet to the LMA through the bi- directional tunnel established between itself and the LMA. And the format of the tunnel multicast packets is shown below. IPv6 header (src= Proxy-CoA, dst= LMAA) /*Tunnel Header*/ IPv6 header (src= MN-HoA, dst= GRPA) /*Packet Header*/ Upper layer protocols /*Packet Content*/ Solution II: some extra functions, such as MLD Proxy as discussed in RFC 4605 [8] and [draft-schmidt-multimob-pmipv6-base-source] [9], could be used to transmit the multicast data through the tunnel of the PMIPv6. The MLD proxy functions are deployed at the MAG as described in RFC 6224 [10] and the MLD proxy instance serving a mobile multicast source configures its upstream interface at the tunnel towards the MN's corresponding LMA. For each LMA, there will be a separate instance of an MLD proxy. Although multicast communication can be enabled in PMIPv6 domains by deploying MLD Proxy functions at MAG, some disadvantages still exist. Firstly, for a proxy device performing IGMP/MLD-based forwarding has a single upstream interface and one or more downstream interfaces as described in RFC4605, there should be many MLD Proxy functions deployed at one MAG, which is complicated and then is difficult for implementation and management. And then when the multicast packets arrive at the MAG running multiple parallel MLD proxy functions, there may be confusions for the data if there is no extra processing or filtering scheme at the MAG. In addition, the route optimization issue is still up in the air, that is, for a mobile receiver and a source on the same MAG using different LMAs, the traffic has to go up to one LMA, cross over to the other LMA, and then be tunneled back to the same MAG, causing redundant flows in the access network and at the MAG. Therefore, the MLD Proxy function should be extended to accommodate the PMIPv6 protocol. As same as the document [9] and [10], the MLD proxy functions are deployed at the MAG, while only one MLD Proxy function is required to run at the MAG and multiple upstream interfaces can be set for the MLD Proxy instance, which is called Multi-Upstream Interfaces MLD Proxy (MUIMP). Figure 2 shows the Zhang et al. Expires January, 2012 [Page 6] Internet-Draft MSM Support in PMIPv6 Network July 2011 architecture of the MUIMP deploying in PMIPv6 for the multicast source mobility. As shown in Figure 2, the paths among the MAGs and the LMA represented by "||", "|o|" and "/*/" indicate the tunnels in base PMIPv6 for the MN1, MN2, and MNn, respectively. In this way, when the multicast data sent by the mobile source gets to the MAG from the downstream interface of an MLD proxy, the MAG forwards this data to the corresponding upstream interface according to the Binding Update List Entry (BULE) for example at this MAG and to all but the incoming downstream interfaces with appropriate forwarding states for this group. And the specific scheme for the choice of the corresponding upstream interface is outside of this document. Therefore, multicast packets originating from an MN/mobile source will arrive at the corresponding LMA and directly at all mobile receivers co-located at the same MAG. Figure 3 shows the signaling call flow of the MN attachment in this scheme. And when the MN leaves, after the deregistration of the PMIPv6 for MNs, the MUIMP deletes the corresponding upstream tunnel interface for each MN which leaves. When the MN hands over, it is the same course as the MN attached. And this scheme can not only solve the route optimization issue as mentioned in the document [9], but also can be easily to deploy, implement and manage. +-------------+ | Content | | Source | +-------------+ | ** ** ** ** ** ** ** ** ** Fixed Internet ** ** ** ** ** ** ** ** ** / | \ +----+ +----+ +----+ |LMA1| |LMA2| ... |LMAn| Multicast Anchor +----+ +----+ +----+ | | | \\ |o| /*/ \\ |o| /*/ \\ |o| /*/ \\ |o| /*/ \\ |o| /*/ Unicast Tunnel | +------------+ Zhang et al. Expires January, 2012 [Page 7] Internet-Draft MSM Support in PMIPv6 Network July 2011 | MAG | MLD Proxy with multi-upstream interfaces +------------+ / | \ {MN1} {MN2}...{MNn} Figure 2: Architecture of the MUIMP deploying in PMIPv6 MN1 MN2 MAG(MUIMP) LMA1 LMA2 | | | | | MN1 Attached | | | | | | | | | | MN2 Attached | | | | | | | | |After configuration of PMIPv6 for | | | |MNs, the MUIMP adds the corresponding| | | |tunnel interface as a new upstream | | | |interface for each MN | | | | | | | | |----------- Multicast Data --------->| | | | | | | | | | |=Mcast Data=>| | | | | | | | |-- Mcast Data -->| | | | | | | | | | |========Mcast Data=======>| | | | | | Figure 3: Mobile Node Attachment (MUIMP) - Signaling Call Flow 3.2. Data transmission after tunneling After the processing in Section 3.1, the multicast data arrives at the LMA through the PMIPv6 tunnel and the subsequent data transmission is illustrated in detail as follows. When the LMA can conduct the DR function, the data transmission procedures are described as follows. In the scenario of ASM, the multicast receivers send the (*,G) join message to the RP to establish the RPT from the RP to the receivers. 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 RP through the source Zhang et al. Expires January, 2012 [Page 8] Internet-Draft MSM Support in PMIPv6 Network July 2011 registration and then delivered 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. When the data traffic of the multicast source exceeds a certain value of data rate, the RP sends a (HoA,G) 'connection' message to the DR/LMA to establish the SPT from the specific source to the RP. Then the LMA parses this message and establishes the related multicast state. And when the handover from the Rendezvous Point Tree (RPT) to the Shortest Path Tree (SPT) happens, the receivers send the join message (HoA,G) to join the SPT of the source, and then the LMA receives this message and establishes the related multicast state. In this way, the LMA-based SPT is established successfully and the subsequent multicast data flow will be transmitted through the LMA- based SPT. 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 the PMIPv6 tunnel. In the SSM case, the multicast receivers actively send the (HoA,G) subscribe message, for the LMA is just the topological anchor point of the source's Home Address (HoA) in the PMIPv6 network, this message is delivered to the LMA firstly and then the LMA-based multicast SPT from the LMA to the receivers can be established. Accordingly, the SSM scenario with the LMA-based scheme is similar to the SPT handover in the ASM scenario with the LMA-based scheme. And the current SPT path is also not the topological shortest path tree due to the existence of PMIPv6 tunnel. As described in RFC 4601 [11], on receipt of data from S to G on interface iif (incoming interface of the packet), the DR will firstly check whether the source is directly connected and also the iif is identical to the Reverse Path Forwarding (RPF) interface. However, because the network prefix of the LMA's interfaces is not same with the HNP allocated to the mobile source, the check of the source's direct connection will not be successful and then the LMA may not perform the function of the DR for the source. And when the LMA can not conduct the DR function, some extensions on the LMA should be needed, which will be our future work for the multicast source mobility in PMIPv6. 4. 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. Zhang et al. Expires January, 2012 [Page 9] Internet-Draft MSM Support in PMIPv6 Network July 2011 4.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 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 Multicast address option when the "S" is set to "1". 4.2. LMA When receiving the extended PBU message and finding the "S" flag is set to "1", the LMA should send back an extended PBA message with the "S" flag set to "1" to the MAG. And then the LMA establishes a tunnel to the MAG as specified in PMIPv6. 5. Format of signaling messages 5.1. PBU The format of the PBU message is shown 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|M|R|P|S| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Multicast address option . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: PBU Message Format S flag and Multicast address option Zhang et al. Expires January, 2012 [Page 10] Internet-Draft MSM Support in PMIPv6 Network July 2011 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. 5.2. PBA The format of the PBA message is shown in Figure 5. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Multicast address option . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: 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. 5.3. Multicast address option The format of Multicast address option is illustrated in Figure 6. 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 + | | Zhang et al. Expires January, 2012 [Page 11] Internet-Draft MSM Support in PMIPv6 Network July 2011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: 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. 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-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. [5] Seil Jeon and Younghan Kim. "Mobile Multicasting Support in Proxy Mobile IPv6", draft-sijeon-multimob-mms-pmip6-02, March 4, 2010. Zhang et al. Expires January, 2012 [Page 12] Internet-Draft MSM Support in PMIPv6 Network July 2011 [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. [8] B. Fenner, H. He, B. Haberman and H. Sandick. "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006. [9] T C. Schmidt, M. Waehlisch and M. Farooq. "Mobile Multicast Sender Support in PMIPv6 Domains with Base Multicast Deployment", draft-schmidt-multimob-pmipv6-base-source-00, March 28, 2011. [10] T. Schmidt, M. Waehlisch and S. Krishnan. "Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains", RFC 6224, April 2011. [11] B. Fenner, M. Handley, H. Holbrook and I. Kouvelas. "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. Zhang et al. Expires January, 2012 [Page 13] Internet-Draft MSM Support in PMIPv6 Network July 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 liliwang@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 January, 2012 [Page 14]