NETLMM WG Hong-ke Zhang Internet Draft Jian-feng Guan Expires: March 2009 Hua-chun Zhou Ying Zhu Beijing Jiaotong University, NGIRC September 4, 2008 Multicast Routing in Proxy Mobile IPv6 draft-zhang-netlmm-pmipv6-mcast-00.txt 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. This document may only be posted in an Internet-Draft. 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 February 4, 2009. Abstract With the development of various mobile technologies, mobile multicast becomes a research hotspot. Several mobile multicast schemes were proposed, but most of them are based on the Mobile IPv6 and its alternatives. Recently, the Proxy Mobile IPv6 (PMIPv6) was proposed to provide the mobility support for mobile node without mobility function. However, the PMIPv6 mainly concerns on the unicast transmission support, and little considers the multicast routing. So, in this memo, we propose two mobile multicast mechanisms, the MAG- Zhang, et al. Expires March 4, 2009 [Page 1] Internet-Draft Multicast Routing in PMIPv6 September 2008 based method and LMA-based method to support the multicast routing in PMIPv6. Table of Contents 1. Introduction.................................................2 2. Conventions & Terminology....................................3 2.1. Conventions used in this document.......................3 2.2. Terminology.............................................3 3. Overview of Multicast Routing in PMIPv6......................4 4. Working flow.................................................5 4.1. MAG-based mobile multicast..............................5 4.1.1. Scenario 1: Intra-PMIPv6 domain roaming............5 4.1.2. Scenario 2: Inter-PMIPv6 domain Roaming............6 4.2. LMA-based mobile multicast..............................7 4.2.1. Scenario 1: Intra-PMIPv6 domain roaming............7 4.2.2. Scenario 2: Inter-PMIPv6 domains roaming...........9 5. Protocol Configuration Variables.............................9 6. Security Considerations......................................9 7. IANA Considerations..........................................9 8. Conclusions.................................................10 9. Acknowledgments.............................................10 10. References.................................................11 10.1. Normative References..................................11 10.2. Informative References................................11 Author's Addresses.............................................12 Intellectual Property Statement................................12 Disclaimer of Validity.........................................12 Copyright Statement............................................13 Acknowledgment.................................................13 1. Introduction With the development of mobile and wireless communication technologies, multicast technology has developed from fixed platform to wireless and mobile platform, and the mobile multicast technology was proposed. Mobile multicast has to handle the dynamic membership and manage mobile subscribers. The Multicast Listener Discovery (MLD) [3] [4] protocol was proposed to manage the dynamic membership for IPv6 (IPv4 uses the Internet Group Management Protocol), but it cannot maintain the continuous multicast session for the mobile subscribers. To support the mobile subscribers, The current mobile multicast schemes mainly depend on the MIPv6 [5] and its variants which are the host-based mobility management protocols, and require the mobile nodes to involve in the mobility signaling. As a result, the mobile node needs to implement new mobility support Zhang, et al. Expires March 4, 2009 [Page 2] Internet-Draft Multicast Routing in PMIPv6 September 2008 specifications which increases the process overhead. Recently, the IETF NETLMM workgroup proposes the Proxy Mobile IPv6 (PMIPv6) [6] protocol which provides the mobility support for mobile nodes without involvement of mobility signaling. But the current PMIPv6 specification does not consider multicast routing. In this memo, we proposed two mobile multicast methods to address the issues and requirement of mobile multicast in PMIPv6. 2. Conventions & Terminology 2.1. 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 2119 [1]. 2.2. Terminology All the general mobility related terms used in this document are to be interpreted as defined in the Mobile IPv6 base specification [5]. This document adopts the terms, Local Mobility Anchor (LMA) and Mobile Access Gateway (MAG) from the NETLMM Goals document [8]. This document mainly uses the following terms in this document. Proxy Mobile IPv6 Domain (PMIPv6-Domain) Proxy Mobile IPv6 domain refers to the network where the mobility management of a mobile node is handled using the Proxy Mobile IPv6 protocol as defined in this specification. The Proxy Mobile IPv6 domain includes local mobility anchors and mobile access gateways between which security associations can be setup and authorization for sending Proxy Binding Updates on behalf of the mobile nodes can be ensured. Local Mobility Anchor (LMA) Local Mobility Anchor is the home agent for the mobile node in the Proxy Mobile IPv6 domain. It is the topological anchor point for the mobile node's home network prefix and is the entity that manages the mobile node's binding state. The local mobility anchor has the functional capabilities of a home agent as defined in Mobile IPv6 base specification [5] with the additional capabilities required for supporting Proxy Mobile IPv6 protocol as defined in this specification. Mobile Access Gateway (MAG) Zhang, et al. Expires March 4, 2009 [Page 3] Internet-Draft Multicast Routing in PMIPv6 September 2008 Mobile Access Gateway is a function that manages the mobility related signaling for a mobile node that is attached to its access link. It is responsible for tracking the mobile node's movements to and from the access link and for signaling the mobile node's local mobility anchor. Mobile Node (MN) Throughout this document, the term mobile node is used to refer to an IP host or router whose mobility is managed by the network. The mobile node may be operating in IPv6 mode, IPv4 mode or inIPv4/IPv6 dual mode. The mobile node is not required to participate in any IP mobility related signaling for achieving mobility for an IP address that is obtained in that Proxy Mobile IPv6 domain. 3. Overview of Multicast Routing in PMIPv6 This document describes two basic multicast forwarding mechanisms in the PMIPv6 based on the configuration variable which is noted as the EnableMAGLocalMulticastRouting to control two different methods in multicast routing. The choice of the two methods SHOULD be based on the policy configured on the MAG, but enforced by the LMA. The specific details on how this is achieved are beyond of the scope of this document. In the PMIPv6, the MAG is a function that typically runs on an access router in IP level and acts as a default router for mobile nodes connected to it. So in case of mobile multicast in PMIPv6, the MAG SHOULD support multicast routing which includes the group membership management, the multicast state maintenance and the multicast packets forwarding. If EnableMAGLocalMulticastRouting is enabled to route the multicast packets locally in the MAG, the MAG MAY optimize the path by locally joining the group on behalf of the MN and routing the packets and by not reverse tunneling them to the LMA. MAG MAY choose to route the multicast packets directly from/to upstream multicast router locally. The mobile node uses the link-local address as the source address and sends the MLD messages. The MAG performs the join procedure after receiving the MLD message. For the mobile node that wants to send the multicast packets to a multicast group, it sends the multicast packets directly on the attached link, and then MAG forwards the multicast packets to the established multicast distribution tree. We call this mechanism the MAG-based mobile multicast. If the MAG is not allowed to route the multicast packets locally, the MAG SHOULD tunnel the MLD report message from the mobile node to the LMA. This mechanism requires that not only the MAG but also the LMA support the multicast routing function through the bi-directional Zhang, et al. Expires March 4, 2009 [Page 4] Internet-Draft Multicast Routing in PMIPv6 September 2008 tunnel, so that LMA can de-capsulate the MLD report message from the MAG and join the group on behalf of the mobile nodes. The mobile node uses the global address as the source address to send the MLD message. The MAG MAY performs the MLD proxy function to sets up the multicast listener state for mobile nodes and forwards the aggregated MLD messages through the bi-directional tunnel between the MAG and the LMA. The LMA sets up the multicast state and joins the group. Multicast packets SHOULD be tunneled to the MAG after being received by the LMA. The MAG forwards these packets to the MN according to the multicast listener state in the MAG after receiving the tunneled multicast packets. When mobile node serves as a multicast source and sends packets to a group, it sends the multicast packets to the MAG at first, and then MAG encapsulates these packets and forwards them to the LMA through the bi-directional tunnel. We call this mechanism the LMA-based mobile multicast. 4. Working flow 4.1. MAG-based mobile multicast 4.1.1. Scenario 1: Intra-PMIPv6 domain Roaming The MAG-based mobile multicast mechanism transmits the multicast through the local multicast router and it requires the MAG supports the multicast routing. Figure 1 shows the procedure of MAG-based mobile multicast mechanism in detail. Assume that mobile node attaches to P-MAG at first, and then it attaches to the N-MAG. After attaching to the P-MAG, the mobile node joins a multicast group. When the mobile node moves from the P-MAG to the N-MAG, it sends the unsolicited MLD report message including the joined multicast group information as soon as it finished the link-local address configuration. N-MAG firstly authenticates the mobile node for PMIPv6 services, and then acquires the profile information of mobile node. After that, N-MAG performs binding process with the LMA. If the N-MAG is allowed to forward the multicast packets locally which means the EnableMAGLocalMulticastRouting is enabled, the N-MAG will set up the multicast listener state and joins the multicast delivery tree to transmit the multicast packets to mobile node. On receiving the multicast packets from the local multicast router, the MAG checks the EnableMAGLocalMulticastRouting flag to ensure the MAG is allowed to route the multicast packets directly to the mobile node. If the MAG is not allowed to route the packets directly, it must discard these packets. On receiving the multicast packets from the mobile node as a source, MAG should firstly ensure that it is Zhang, et al. Expires March 4, 2009 [Page 5] Internet-Draft Multicast Routing in PMIPv6 September 2008 allowed to forward the multicast locally. MAG forwards these multicast packets according to its multicast routing state. N-MAG MN P-MAG LMA local-MR | | | | | | Attachment MN attached event | | | | (accquire MN-Id and Profile) | | | | |<-----register----->| | | | |====bi-dir tunnel===| | | |------RS----->| | | | |<-----RA------| | | | address configuration | | | | |--MLD Report->| | | | | |---MLD Report/Join message-->| | | |<---multicast packets------- | | |<--multicast--| | | | | packets | | | | | | | | MN attached event | | | | (acquire MN-Id handover MN detached event | | and Profile) | |<----deregister---->| | | | | | |<--------------------Register------------------->| | |================bi-directional tunnel============| | |<-----RS-----| | | | |------RA---->| | | | |<-MLD Report-| | | | |-----------------MLD Report/Join message----------------->| |<---------------------multicast packets-------------------| |--multicast->| | | | | packets | | | | | | | | | Figure 1 the work flow of MAG-based mobile multicast Generally speaking, the MAG-based mechanism joins the group through the access link directly, so it is more scalable and has the optimal multicast delivery path. However, it may have long join delay especially when the multicast delivery tree is far away the current MAG. Moreover in some systems, this mechanism may cause problem in applying traffic policies or accounting for those multicast traffic. 4.1.2. Scenario 2: Inter-PMIPv6 domain Roaming (TBD) Zhang, et al. Expires March 4, 2009 [Page 6] Internet-Draft Multicast Routing in PMIPv6 September 2008 4.2. LMA-based mobile multicast 4.2.1. Scenario 1: Intra-PMIPv6 Domain Roaming The LMA-based method transmits the multicast packets through the LMA, and it requires the LMA to support the multicast routing, and requires the MAG to forward the MLD messages between LMA and mobile nodes through bi-directional tunnel. Figure 2 shows the operation flow in detail. Assume that a mobile node attaches to P-MAG at first, and then it attaches to the N-MAG. After the mobile node attaches to the P-MAG, it sends a join message such as the MLD report message to join the multicast group. The P-MAG will forward this join message to the LMA through the tunnel. The LMA, after receiving this message, sets up the multicast state for the group and transmits the multicast packets through the bi-directional tunnel between the P-MAG and the LMA. When mobile node moves from P-MAG to N-MAG, it sends the unsolicited MLD report message to N-MAG as soon as it finished the global address configuration. The N-MAG sets up the multicast listener states and forwards the multicast packets to mobile node after receiving the encapsulated multicast packets from the LMA. The LMA records the multicast listener state for every tunnel, and maintains the group membership on behalf of every mobile node. On receiving the multicast packets that the mobile nodes joined, the LMA MUST forward the multicast packets to the corresponding tunnel. When the MN sends the multicast packets, the LMA, after removing the tunnel header, MUST forward these packets to multicast router that attached to the LMA according to the multicast routing table. Zhang, et al. Expires March 4, 2009 [Page 7] Internet-Draft Multicast Routing in PMIPv6 September 2008 N-MAG MN P-MAG LMA MR | | | | | | Attachment MN attached event | | | | (acquire MN-Id and Profile) | | | | |<-----register----->| | | | |====bi-dir tunnel===| | | |------RS----->| | | | |<-----RA------| | | | address configuration | | | | |--MLD Report->| | | | | |=====MLD Report ====| | | | | (Join message) | | | | | |MLD Report | | | |------->| | | | (Join message) | | | | | | | | | multicast | | | |<-------| | | | | packets| | | |==multicast packets=| | | |<--multicast--| | | | | packets | | | MN attached event | | | | (acquire MN-Id handover MN detached event | | and Profile) | |<----deregister---->| | | | | | |<--------------------Register------------------->| | |================bi-directional tunnel============| | |<-----RS-----| | | | |------RA---->| | | | |<-MLD Report-| | | | |=================MLD Report/Join message==================| |======================multicast packets===================| |--multicast->| | | | | packets | | | | | | | | | Figure 2 the work flow of LMA-based mobile multicast The LMA-based method has lower multicast handover delay compared with the MAG-based method, and it can provide the traffic management and accounting for mobile nodes. However, the LMA-based method requires the LMA support multicast and all the multicast packets transmitting through the tunnel increases the process overhead on the LMA. The bi- directional tunnel between LMA and MAG can be shared by multiple mobile nodes belonging to the same LMA. LMA only transmits one copy through the tunnel to mobile node located in the same MAG when they Zhang, et al. Expires March 4, 2009 [Page 8] Internet-Draft Multicast Routing in PMIPv6 September 2008 want to join the same group. But for the mobile nodes with different LMAs who want to join the same group, the MAG MAY receive multiple copies of the group, and it may cause the tunnel convergence problem. The problem is out of scope of this document and can be referred to [9]. 4.2.2. Scenario 2: Inter-PMIPv6 Domains Roaming (TBD) 5. Protocol Configuration Variables The local mobility anchor MUST allow the following variable to be configured by the system management. EnableMAGLocalMulticastRouting This flag indicates whether or not the mobile access gateway is allowed to enable local multicast routing when mobile access gateway can obtain or send multicast traffic data from or to local multicast router connected in the local area. The default value for this flag is set to false, indicating that the mobile access gateway MUST reverse tunnel all the MLD report to the local mobility anchor of the mobile node. When the value of this flag is set to true, the mobile access gateway MUST route the multicast traffic locally. This aspect of local multicast routing MAY be defined as policy and when present will take precedence over this flag. 6. Security Considerations This memo discusses the multicast routing in PMIPv6 and the security issues arise from the PMIPv6 specifications and MLD protocols. 7. IANA Considerations There are no IANA considerations introduced by this memo currently. Zhang, et al. Expires March 4, 2009 [Page 9] Internet-Draft Multicast Routing in PMIPv6 September 2008 8. Conclusions In this memo, we discuss the multicast routing in the PMIPv6 specification, and introduce the EnableMAGLocalMulticastRouting flag to determine the different multicast routing policy and method. 9. Acknowledgments The authors would like to thank Si-Dong Zhang, Ya-juan Qin (BJTU NGIRC) for their valuable comments and suggestions on this memo. Zhang, et al. Expires March 4, 2009 [Page 10] Internet-Draft Multicast Routing in PMIPv6 September 2008 10. References 10.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. [3] S. Deering, W. Fenner, B. Haberman, "Multicast Listener Discovery (MLD) for Ipv6", 1999. [4] R. Vida and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", IETF RFC 3810, (2004). [5] D. Johnson, C. Perkins, and J. Arkko, "Mobility Support in IPv6", RFC 3775, 2004. 10.2. Informative References [6] S. Gundavelli, K. leung, V. Devarapalli, K. Chowdhury, B. Patil, Proxy Mobile IPv6,draft-ietf-netlmm-proxymip6-18,work in progress,(2008). [7] S. Narayanan et al., "Detecting Network Attachment in IPv6 Networks (DNAv6)", draft-ietf-dna-protocol-07.txt, (2008) [8] J. Kempf et al., "Goals for Network-Based Localized Mobility Management (NETLMM)", RFC 4831, April 2007. [9] T.G. Harrison, C. L. Williamson, W. L. Mackrell, Richard B. Bunt, "Mobile multicast (MoM) protocol: Multicast support for mobile hosts", ACM MOBIGCOM 1997, Budapest, Hungary, pp:151-160, (1997). Zhang, et al. Expires March 4, 2009 [Page 11] Internet-Draft Multicast Routing in PMIPv6 September 2008 Author's Addresses Hong-ke Zhang, Jian-feng Guan, Hua-chun Zhou, Ying Zhu, Next Generation Internet Research Center (NGIRC), Beijing JiaoTong University Beijing, China, 100044 Phone: +86 10 51685677 Email: hkzhang@bjtu.edu.cn guanjian863@163.com hchzhou@bjtu.edu.cn 03211152@bjtu.edu.cn Intellectual Property Statement 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. Full Copyright Statement 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 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. Zhang, et al. Expires March 4, 2009 [Page 12] Internet-Draft Multicast Routing in PMIPv6 September 2008 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Zhang, et al. Expires March 4, 2009 [Page 13]