Network Working Group Hong-Ke Zhang INTERNET-DRAFT Bo Shen Expiration Date: January 2006 Bing-Yi Zhang Beijing Jiaotong University En-Hui Liu Spencer Dawkins Huawei Technologies Co.,Ltd. July 2005 Mobile IPv6 Multicast with Dynamic Multicast Agent 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. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document addresses the problem of delivering IPv6 multicast traffic to MNs (Mobile Nodes). An approach named Mobile IPv6 Multicast with Dynamic Multicast Agent is proposed. The approach is a combination of Movement Based Method [2] and Distance Based Method [3]. Such a design allows MNs to optimize multicast routes, and meanwhile reduces the number of handoffs by selecting new multicast agents dynamically. In addition to weakening the triangle route problem and diminishing the influence of handoff to multicast, this approach provides global mobility in the Internet without the restriction on network topologies. Hong-Ke Zhang et al. Expires January 2006 [Page 1] INTERNET-DRAFT Mobile IPv6 Multicast with DMA July 2005 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 [5]. Table of Contents Status of this Memo.................................................1 Abstract............................................................1 1. Introduction....................................................3 2. Concepts and Framework..........................................4 3. Operation of MSA................................................5 4. Operation of DMA................................................7 5. DMA switch decision-making algorithm in DMA.....................9 6. Conclusion......................................................9 7. Acknowledgements...............................................10 8. Informative Reference..........................................10 9. Normative Reference............................................10 10. Authors' Addresses.............................................11 11. Intellectual Property Statement................................11 Hong-Ke Zhang et al. Expires January 2006 [Page 2] INTERNET-DRAFT Mobile IPv6 Multicast with DMA July 2005 1. Introduction Multicast is an efficient way for forwarding data from one node or multi-nodes to multi-nodes. Supporting mobility becomes an inevitable function of multicast technologies. The mobility support for IPv6 protocol [1] has specified two basic methods for mobile multicast: 1) via a bi-directional tunnel from a MN to its HA (Home Agent), that is called MIP-BT (Mobile IP Bi-directional tunnel); 2) via a (local) multicast router on the foreign link being visited, that is called MIP-RS (Mobile IP Remote Subscription). In MIP-BT, the MN tunnels its multicast group membership control packets to its HA, and the HA forwards multicast packets down the tunnel to the MN [1]. In MIP-RS, the MN MUST use its care-of address and MUST NOT use the Home Address destination option when sending MLD (Multicast Listener Discovery) packets [1,4]. These two basic methods can retain multicast communications when MNs move, but some issues exist. o First, MIP-BT suffers the triangle route which is composed of MN-HA tunnel and HA-S multicast tree path. When the MN is far from its HA, the data forwarding path of multicast becomes deteriorative. o Second, multiple tunnels from a subnet to a HA are established in MIP-BT, when some MNs that come from the same home link attach at one AR (Access Router) in the subnet and these MNs join the same multicast group at the same time. This case is called tunnels congregation which leads to more network resources being consumed. o Third, although the multicast path in MIP-RS is optimal, the frequent handoffs of a MN, which are due to the movement of the MN among subnets, produce much latency. This is because the handoff action makes the MN leave and re-join the multicast group frequently. This document addresses these above problems. An approach named Mobile IPv6 Multicast with Dynamic Multicast Agent is proposed, which accepts the merits of MIP-BT and MIP-RS. This approach combines Movement Based Method and Distance Based Method to select a new multicast agent dynamically, and the new selected multicast agent is responsible for forwarding multicast data to the MN. Hong-Ke Zhang et al. Expires January 2006 [Page 3] INTERNET-DRAFT Mobile IPv6 Multicast with DMA July 2005 Such a design allows MNs optimize multicast routes and meanwhile reduce the number of handoffs. In addition to weakening the triangle route problem and diminishing the influence of handoff to multicast, this approach provides global mobility in the Internet without the restriction on network topologies. In the following sections, we will first introduce the concepts and framework of the approach. Then, we will describe the details of Dynamic Multicast Agent switch procedure. 2. Concepts and Framework In this document, two key roles are defined for Mobile IPv6 Multicast with Dynamic Multicast Agent: - MSA: Multicast Subnet Agent, which is the access router running multicast protocols in a subnet and forwarding the subscribed multicast data to the MN that visits the subnet. - DMA: Dynamic Multicast Agent, which is the current MSA or one of the previous MSAs of the MN acting as the leaf router in a multicast delivery tree the MN subscribed and forwarding the subscribed multicast data to the MN through its current MSA. MSA is in charge of the local multicast group membership management and maintenance in a subnet via MLD protocol. MSA periodically sends regular MLD query messages to solicit regular MLD reports from the MNs visiting the subnet. The MN does regular MLD reports and tell its previous MSA address to the current MSA. When a MN first subscribes a multicast group G, its current MSA becomes its initial DMA, which joins the subscribed multicast delivery tree as a leaf router and then forwards the subscribed multicast data to the MN. Within an acceptable roaming distance, the DMA of a MN will not change although its visited MSA changes if its visited MSA doesn't yet have the group G membership in the subnet. When the MN's current MSA is different from its DMA, its current MSA receives the group G multicast data from its DMA via a short tunnel, and then forwards the multicast data to the MN. Beyond this acceptable roaming distance, the MN's DMA will be switched to the new MSA that the MN currently is visiting. Hong-Ke Zhang et al. Expires January 2006 [Page 4] INTERNET-DRAFT Mobile IPv6 Multicast with DMA July 2005 By introducing the concept of DMA, it is avoidable for all recently visited MSA of the MN along its roaming path to successively join and leave the subscribed multicast delivery tree as a leaf router. In this approach, only MSAs selected as a DMA need to join the subscribed multicast delivery trees as a leaf router. In comparison with the Static Multicast Agent approach (e.g. MAP in HMIPv6 [5]), this DMA approach is quite distributed. So the rick of Static Multicast Agent being performance bottleneck and resulting long tunnels and large tunnel numbers can be avoided. In comparison with MIP-BT approach, this DMA approach optimizes multicast transmit paths due to the shortest path from DMA to multicast source. So the triangle routes, long tunnels and large tunnel numbers can be avoided. In comparison with MIP-RS approach, this DMA is quite effective. The frequency of remote multicast subscription and multicast delivery tree restructuring is quite reduced. 3. Operation of MSA MSA is in charge of the local multicast group membership management and maintenance in a subnet via MLD protocol. MSA periodically sends regular MLD query messages to solicit regular MLD reports from the MNs visiting the subnet. MSA maintains a Multicast Route Table used for receiving and forwarding the subscribed multicast data. There are four elements kept in every entry of the Multicast Route Table: Group Address, Membership (INCLUDE or EXCLUDE mode), Tunnel_State, Tunnel_ID, and Outgoing Interface List. o Tunnel_ID is the identifier of a tunnel between MSA and DMA for MSA to receive the multicast data of the Group from DMA. o Tunnel_State is a flag that represents whether Tunnel ID is valid and whether MSA has created a tunnel for the Group and is receiving the multicast data of the Group via the tunnel. MSA also maintains a Visitor Table for support of DMA switch process. There are two elements kept in every entry of the Visitor Table: MN and DMA. o MN item records the IP address of a MN visiting the subnet and being a multicast subscriber. Hong-Ke Zhang et al. Expires January 2006 [Page 5] INTERNET-DRAFT Mobile IPv6 Multicast with DMA July 2005 o DMA item records the IP address of the MN's DMA. -------------------- | MN | DMA | |------------------| | | | -------------------- On arriving at a new visited subnet, a MN obtains a new CoA (Care of Address) and registers its current CoA with its Home Agent. Then the MN immediately sends regular MLD reports to its current subnet's MSA and the IP address of the previous subnet's MSA. The MSA communicates with the MN's previous MSA to obtain the IP address of the MN's previous DMA. When receiving the MLD group membership report sent from a visitor for group G, the MSA operates as follows: o If there already is an entry for group G in the MSA's multicast route table, the MSA adds the MN to the entry's outgoing interface list, and then examines the Tunnel_State. If the Tunnel_State is 'YES', it represents that the MSA has already created a tunnel for the group and is receiving multicast data via the tunnel. In this case, it simply forwards the MLD group membership report message to the other end of the tunnel. - If there already is an entry for the MN in the MSA's Visitor Table, then the MSA keeps it. - Otherwise, if there is no entry for the MN in the MSA's Visitor Table, then the MSA creates a new entry for the MN. In order to optimize the delivery path, the DMA of the MN is switched to the MSA itself. And then the MSA informs the previous DMA to clear the states of the MN if available. o If there is no entry for group G in the MSA's multicast route table, (i.e. the MN is the first group member of group G in the subnet), then MSA creates a new entry for group G in its multicast route table and adds the MN into the entry's outgoing interface list. - If there already is an entry for the MN in the MSA's Visitor Table, and if the MSA itself is the DMA of the MN, the MSA simply sends PIM Join messages to the multicast delivery tree. But if the MSA itself is not the DMA of the MN, the MSA creates a tunnel to the DMA of the MN, records the Tunnel_ID, sets the Tunnel_State to 'YES', and forwards the MLD group membership report message to the other end of the tunnel. Hong-Ke Zhang et al. Expires January 2006 [Page 6] INTERNET-DRAFT Mobile IPv6 Multicast with DMA July 2005 - If there is no entry for the MN in the MSA's Visitor Table, the MSA creates an entry for the MN, and asks the MN's previous DMA if it needs to be switched to the MSA itself. If the MN's DMA doesn't need to be switched to the MSA itself, the MSA adds the MN's DMA into the entry, creates a tunnel to the MN's DMA, records the Tunnel_ID, sets the Tunnel_State to 'YES', and forwards the MLD group membership report message to the other end of the tunnel. If the MN's DMA needs to be switched to the MSA itself, the MSA adds itself into the entry, acts as the MN's DMA, and sends PIM Join messages to the multicast delivery tree. The MSA detects the MN's departure by the timeout of timer. When the MSA detects that a MN is departing from the current subnet, it deletes the entry for the MN in its Visitor Table. For each multicast group which the leaving MN subscribed, the MSA deletes the MN from the group's outgoing interface list. 4. Operation of DMA DMA is in charge of joining the multicast delivery tree of the group G that a MN subscribed via PIM-based protocol as a leaf router. It receives the multicast data of group G and forwards the data to the MN through the MN's current MSA. When a MN first subscribes a multicast group G, its current MSA becomes its initial DMA. Within an acceptable roaming distance, the DMA of a MN will not change although its MSA changes if its MSA doesn't yet have the group G membership in the subnet. So the DMA of a MN may be its current MSA or one of its previous MSAs. At a time only one DMA serves the MN for its subscribed multicast group G. When receiving the MLD group membership report sent from its served MN for a new group G, the DMA sends PIM Join messages to join the multicast delivery tree of the group G as a leaf router. When DMA switch happens or the MN leaves the group G, the DMA sends PIM Prune messages to prune itself from the multicast delivery tree of the group G. DMA maintains a table to record the MN's recent attachment history, which is used for DMA to do DMA switch decision-making for the MN. There are three elements kept in every entry of the Table: MN, MSA and Increment. o MN item records the IP address of the MN that the DMA serves; Hong-Ke Zhang et al. Expires January 2006 [Page 7] INTERNET-DRAFT Mobile IPv6 Multicast with DMA July 2005 o MSA item records the IP address of the MSA in each subnet that the MN recently roamed through; o Increment item records the path increment of each MSA. -------------------- | MN | | -------------------- | MSA | Increment| |------------------| | DMA | 1 | | MSA 1 | 2 | | MSA 2 | 1 | | ... | ... | | MSA n | 3 | -------------------- The first MSA is the DMA itself, which creates the table, initiates the MN item, creates an entry for the first MSA and puts itself in the entry. When a MN enters into a new subnet, the MSA in this subnet receives the MLD group member report and the IP address of the MN's previous MSA from the MN. The MSA communicates with the MN's previous MSA to obtain the IP address of the MN's previous DMA. To maintain the recent attachment history table of the MN, the MN's DMA operates as follows: According to the operation of MSA as described in Section 3, o if the DMA of the MN is switched to the MSA itself, the MSA informs the previous DMA to clear the states of the MN if available. Then the MSA acts as the MN's current DMA, creates and initiates the recent attachment history table for the MN. The MN's previous DMA deletes the recent attachment history table of the MN and prunes itself from the multicast delivery tree of the group G. o if the DMA of the MN is not switched to the MSA itself, the MSA communicates with the MN's previous DMA to ask whether it can continue acting as the MN's DMA. The MN's previous DMA creats an entry for the MSA in the recent attachment history table of the MN, and then makes the decision according to the DMA switch decision-making algorithms in DMA as described in Section 5. Hong-Ke Zhang et al. Expires January 2006 [Page 8] INTERNET-DRAFT Mobile IPv6 Multicast with DMA July 2005 - If the decision is 'Yes', then the MSA acts as the MN's current DMA, creates and initiates the recent attachment history table for the MN. The MN's previous DMA deletes recent attachment history table of the MN and prunes itself from the multicast delivery tree of the group G. - If the decision is 'No', the MN's previous DMA continues acting as the MN's DMA. The MSA receives the group G multicast data from the DMA via a tunnel and forwards the data to the MN. 5. DMA switch decision-making algorithm in DMA In DMA, the key point is the algorithm of DMA switch decision-making based on movement and distance. As described in Section 4, DMA maintains a table to record the MN's recent attachment history ( namely History_Table), which is used for DMA to do DMA switch decision-making for the MN. The DMA switch decision-making algorithm could be simple or precise. The main principle is that there should not be any DMA switch for an MN within an acceptable roaming distance if the MN's visited MSA doesn't yet have the group G membership in the subnet. Here, we just provide a simple algorithm via checking the path increment of the recently joined MSA. When the path increment of MSAs in the DMA's History_Table reaches the assigned threshold, DMA switch happens. So the DMA deletes the recent attachment history table of the MN and prunes itself from the multicast delivery tree of the group G. Meanwhile, the MN's current MSA acts as its new DMA, which joins the multicast delivery tree of the group G as a leaf router, creates and initiates the recent attachment history table for the MN. The path increment of a MSA can be defined as: 1 + Minimum [Distance(MSA,DMA),Distance(DMA,MN)], where Distance[x] is the minimum integer greater than or equal to x. For example, the path increment of a MSA is 1 if the MSA itself is the MN's DMA. 6. Conclusion This document has discussed the delivering of IPv6 multicast traffic Hong-Ke Zhang et al. Expires January 2006 [Page 9] INTERNET-DRAFT Mobile IPv6 Multicast with DMA July 2005 to mobile nodes. The presented approach is a compromised approach between MIP-BT and MIP-RS, using a Dynamic Multicast Agent to join the multicast delivery trees intead of a static multicast agent. The use of MSA and DMA is the key feature of the approach. The purpose is to optimize the multicast path to MNs, and meanwhile reduce the latency and the impact on multicast trees which result from the roaming of MNs. By introduing the concept of DMA, it reduces the frequent remote subscription and multicast delivery tree restructuring, and avoids the long tunnels and the large number of tunnels. 7. Acknowledgements We would like to thank Thomas Schmidt, and Kishore Mundra for their valuable comments and suggestions on this document. 8. Informative References [1] Johnson, D., Perkins C., and Arkko, J., "Mobility Support in IPv6", RFC 3775, June 2004. [2] Zhang, J. Y. "Location Management in Cellular Networks". 2001. [3] Bar-Noy, A. Kessler, I. and Sidi, M. "Mobile Users: To update or not to Update?", Wireless Networks Journal, 1995,1(2):175-86. [4] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [5] Soliman, H., Castelluccia, C., El-Malki, K., Bellier, L. "Hierarchical Mobile IPv6 mobility management", draft-ietf- mipshop-hmipv6-04 (work in progress), December 2004. 9. Normative References [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Hong-Ke Zhang et al. Expires January 2006 [Page 10] INTERNET-DRAFT Mobile IPv6 Multicast with DMA July 2005 10. Authors' Addresses Hong-Ke Zhang, Bo Shen, Bing-Yi Zhang IP lab, Beijing JiaoTong Univ. Beijing, China, 100044 Tel: +86 10 51685677 Email: hkzhang@center.njtu.edu.cn bingyizhang@hotmail.com En-Hui LIU Huawei Technologies Co., Ltd. Beijing, China, 100085 Tel: +86-10-82882495 Fax: +86-10-82882537 Email: LEH10814@huawei.com Spencer Dawkins Huawei Technologies Co., Ltd. TX, USA, 75075 Email: sdawkins@futurewei.com 11. 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. Hong-Ke Zhang et al. Expires January 2006 [Page 11] INTERNET-DRAFT Mobile IPv6 Multicast with DMA July 2005 Full Copyright Notice Copyright (C) The Internet Society (2005). 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. 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. Hong-Ke Zhang et al. Expires January 2006 [Page 12]