Network Working Group Hong-Ke Zhang Internet Draft Xiao-Hua Chen Jian-Feng Guan Bo Shen Beijing Jiaotong University En-Hui Liu Spencer Dawkins Huawei Technologies Co.,Ltd. Expires: July 2007 January 29, 2007 Mobile IPv6 Multicast with Dynamic Multicast Agent draft-zhang-mipshop-multicast-dma-03.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 July 29, 2007. Abstract This document addresses the problem of delivering IPv6 multicast traffic to MN (Mobile Node). An approach named Mobile IPv6 Multicast with Dynamic Multicast Agent is proposed which combines Movement Based Method [2] and Distance Based Method [3], Such a design allows MN to optimize multicast route, and meanwhile reduce the handoff frequency by selecting new multicast agent dynamically. In addition to weakening the triangle route problem and diminishing the influence of handoff to multicast, this approach provides global mobility in Internet without limitations on network topology. This draft is the same as the earlier version, it is just an update of it. Hong-Ke Zhang et al. Expires July 29, 2007 [Page 1] Internet-Draft Mobile IPv6 Multicast with DMA January 2007 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 1. Introduction................................................2 2. Concepts and Framework......................................3 3. Operation of MSA............................................5 4. Operation of DMA............................................7 5. DMA switch decision-making algorithm in DMA.................9 6. Security Considerations....................................10 7. IANA Considerations........................................10 8. Conclusions................................................10 9. Acknowledgments............................................10 10. References................................................11 10.1. Normative References.................................11 10.2. Informative References...............................11 Author's Addresses............................................11 Intellectual Property Statement...............................12 Disclaimer of Validity........................................12 Copyright Statement...........................................13 Acknowledgment................................................13 1. Introduction Multicast is an efficient way for forwarding data from one node or multi-nodes to multi-nodes. mobility support 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 MN to its HA (Home Agent), which is called MIP-BT (Mobile IP Bi-directional Tunnel); 2) via a (local) multicast router on the foreign link being visited, which is called MIP-RS (Mobile IP Remote Subscription). In MIP-BT, 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, 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 MN moves, but some issues still exist. o First, MIP-BT suffers from 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. Hong-Ke Zhang et al. Expires July 29, 2007 [Page 2] Internet-Draft Mobile IPv6 Multicast with DMA January 2007 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 will consume more network resources. o Third, although the multicast path in MIP-RS is optimal, frequent handoffs of MN among subnets will produce much latency. Because when MN handovers , it will leave and re-join the multicast tree and multicast group frequently. This document addresses these above problems. An approach named Mobile IPv6 Multicast with Dynamic Multicast Agent is proposed. This approach combines the advantages of MIP-BT and MIP-RS, selecting a new multicast agent based on both movement and distance dynamically, and the new selected agent is responsible for forwarding multicast data to the MN. Such a design optimizes the multicast routes and reduces handoff frequency. Beside releasing triangle route problem and diminishing the influence of handoff to multicast, it can also provide global mobility without limitation on network topology. In the following sections, we will first introduce the concepts and framework of this 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. The whole procedure of this approach is shown in Figure1. Hong-Ke Zhang et al. Expires July 29, 2007 [Page 3] Internet-Draft Mobile IPv6 Multicast with DMA January 2007 MN pMSA nMSA DMA | | | | | |<----request----| | | |-----reply----->| | | | | | |---MLD query--->| | | |<--MLD report---| | | | | | | | Disconnect | | | | | | |------ Unsolicited report------->| | | | DMA handoff decision | | | | | | | connect | | | |------------->| | | | Tunnel Setup | | | |<-------------| |<---------- MLD query------------| | | | | | |<=========deliver packets=======>| | | | | | | | | | Figure 1 Operation process of MSA and DMA 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. To learn address information of neighbor MSAs, each MSA sends request message(e.g. PIM Hello message etc.) periodically, receivers send reply message to the sender, informing it their address information. In this approach, tunnel between nMSA and DMA is setup after MN has attached to nMSA. In order to shorten MN's handover latency, Fast Handover protocol[6] and CARD(Candidate Access Router Discovery) protocol[7] can be adopted. In these two approaches, tunnel is setup before the handover process, so after MN attaches to the nMSA, it can transmit data immediately, handover latency can be reduced Dramatically. When MN first subscribes a multicast group G, its current MSA becomes its initial DMA, which runs multicast protocol and 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 MN's current MSA is different from its DMA, its current MSA receives the group G Hong-Ke Zhang et al. Expires July 29, 2007 [Page 4] Internet-Draft Mobile IPv6 Multicast with DMA January 2007 multicast data from its DMA via a short tunnel, and then forwards 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. Then the MSA will run multicast protocol and operate as DMA. In this case, multicast packets will be delivered from DMA directly to MN without tunnel. In this approach, not all visited MSA along MN's roaming path will join the subscribed multicast delivery tree by introducing the concept of DMA. only that selected as DMA need join the delivery trees as a leaf router. In comparison with other Agent selection approaches (e.g. MAP in HMIPv6 [5]), this DMA selection method is quite distributed, so the problem of performance bottleneck can be released. In comparison with MIP-BT approach, this DMA approach optimizes multicast transmission path by using shortest path from DMA to multicast source. So disadvantages of MIP-BT such as triangle route, large amount and long distance of tunnels can be avoided. In MIP-RS, every MSA is a leaf router of the subscribed multicast tree. once MN moves from the coverage of one MSA to another, it will leave the old MSA and attach to new MSA, which will consume more network resources. This DMA approach can reduce the frequency of remote multicast subscription and that of multicast delivery tree reconstructing dramatically, simplifying MN's signaling procedure, network performance is enhanced. 3. Operation of MSA MSA is in charge of the local multicast group membership management and maintenance in a subnet via MLD protocol, including local hosts and visiting mobile nodes. MSA periodically sends regular MLD query messages to solicit regular MLD reports from the MN visiting the subnet. MSA maintains a Multicast Route Table used for receiving and forwarding the subscribed multicast data. There are six components kept in every entry of the Multicast Route Table: Group Address, Filter Modes(INCLUDE or EXCLUDE mode), Source_Address List, Tunnel_State, Tunnel_ID, and Egress Interface List. o Filter Modes defines host and router parts of the protocol respectively to support the source filtering function. Hong-Ke Zhang et al. Expires July 29, 2007 [Page 5] Internet-Draft Mobile IPv6 Multicast with DMA January 2007 o Source_Address List records all source addresses which should be included or excluded according to the filter modes. 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. o Egress Interface List composes all receivers’ egress interface of this group. multicast data should be forward to these interfaces. 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. 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 unsolicited report message 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 ingress 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 Hong-Ke Zhang et al. Expires July 29, 2007 [Page 6] Internet-Draft Mobile IPv6 Multicast with DMA January 2007 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. - 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 Hong-Ke Zhang et al. Expires July 29, 2007 [Page 7] Internet-Draft Mobile IPv6 Multicast with DMA January 2007 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 called History-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; 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, Hong-Ke Zhang et al. Expires July 29, 2007 [Page 8] Internet-Draft Mobile IPv6 Multicast with DMA January 2007 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 creates 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. - 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: Hong-Ke Zhang et al. Expires July 29, 2007 [Page 9] Internet-Draft Mobile IPv6 Multicast with DMA January 2007 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. Security Considerations This specification introduces a new concept to Mobile IPv6, namely, a Dynamic Multicast Agent that acts as a multicast agent. It is crucial that the security relationship between the Multicast Source Agent and the DMA is strong; it MUST involve mutual authentication, integrity protection, and protection against replay attacks. Confidentiality may be needed for payload traffic. The absence of any of these protections may lead to malicious mobile nodes impersonating other legitimate ones or impersonating a DMA. Any of these attacks will undoubtedly cause undesirable impacts to the mobile node's communication with all correspondent nodes. 7. IANA Considerations See [9] for instructions on IANA allocation. 8. Conclusions This document has discussed the delivering of IPv6 multicast traffic 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 instead 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 introducing 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. 9. Acknowledgments We would like to thank Thomas Schmidt, and Kishore Mundra for their valuable comments and suggestions on this document. Hong-Ke Zhang et al. Expires July 29, 2007 [Page 10] Internet-Draft Mobile IPv6 Multicast with DMA January 2007 10. References 10.1. Normative 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. [6] Koodli, R., Ed., "Fast Handovers for Mobile IPv6", RFC4068, July 2005. [7] M. Liebsch, Ed., A. Singh, Ed.,H. Chaskar.,D. Funato.,E. Shim "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. 10.2. Informative References [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [9] Kempf, J., "Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations", RFC 4065, July 2005. Author's Addresses Hong-Ke Zhang, Bo Shen, Bing-Yi Zhang IP lab, Beijing JiaoTong Univ. Beijing, China, 100044 Phone: +86 10 51685677 Email: hkzhang@center.njtu.edu.cn bingyizhang@hotmail.com Hong-Ke Zhang et al. Expires July 29, 2007 [Page 11] Internet-Draft Mobile IPv6 Multicast with DMA January 2007 En-Hui LIU Huawei Technologies Co., Ltd. Beijing, China, 100085 Phone: +86-10-82882495 Fax:+86-10-82882537 Email: LEH10814@huawei.com Spencer Dawkins Huawei Technologies Co., Ltd. TX, USA, 75075 Email: sdawkins@futurewei.com 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. Disclaimer of Validity 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 July 29, 2007 [Page 12] Internet-Draft Mobile IPv6 Multicast with DMA January 2007 Copyright Statement Copyright (C) The Internet Society (2007). 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. Hong-Ke Zhang et al. Expires July 29, 2007 [Page 13]