Internet Draft Hong-Ke Zhang Document: draft-zhang-mipshop-multicast-dma-00.txt Bo Shen Expires: November 2005 Bing-Yi Zhang Beijing Jiaotong University IP Lab May 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 MN (mobile nodes). An approach named DMA (Dynamic Multicast Agent) is proposed. The approach is a combination of MIP- BT and MIP-RS [1], and it is also a hybrid solution of Movement Based Method [2] and Distance Based Method [3]. Such a configuration allows MNs to optimize multicast routes, and meanwhile reduce 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 with no restriction on network topologies. Hong-Ke Zhang et al. Expires November 2005 [Page i] INTERNET-DRAFT Mobile IPv6 Multicast with DMA May 2005 Table of Contents Status of this Memo................................................i Abstract...........................................................i 1. Introduction....................................................1 1.1 Motivation.....................................................1 1.2 Conventions....................................................2 2. Dynamic Multicast Agent for Mobile IPv6 Multicast...............2 2.1 The Basic Idea.................................................2 2.2 Operation of MSA...............................................3 2.3 Dynamic Multicast Agent Selection..............................5 3. Conclusion......................................................7 Acknowledgements...................................................7 Intellectual Property Statement....................................8 1. Introduction 1.1 Motivation 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] specifies two basic methods for mobile multicast: via a bi-directional tunnel from a MN to its HA (Home Agent), that is called MIP-BT (Mobile IP - Bi- directional tunnel); 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. Hong-Ke Zhang et al. Expires November 2005 [Page 1] INTERNET-DRAFT Mobile IPv6 Multicast with DMA May 2005 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. This document addresses these problems. An approach named DMA (Dynamic Multicast Agent) is proposed, which accepts the merits of MIP-BT and MIP-RS. DMA uses Movement Based Method and Distance Based Method to select a new multicast agent dynamically, and the new selected agent is responsible for forwarding multicast data to the MN. Such a configuration 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 with no restriction on network topologies. In the following sections, we will first introduce the basic idea of the DMA. Then, we will describe the detail of operations of a MSA (Multicast Subnet Agent) and DMA selection process. 1.2 Conventions 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]. This document is a product of ... ... ... ... 2. Dynamic Multicast Agent for Mobile IPv6 Multicast 2.1 The Basic Idea In this document, three concepts are defined: MSA (multicast subnet Agent), DMA and Tunnel State. Hong-Ke Zhang et al. Expires November 2005 [Page 2] INTERNET-DRAFT Mobile IPv6 Multicast with DMA May 2005 MSA is the only multicast access point in one subnet. It is responsible for forwarding multicast datagrams to every MN that visits its subnet, and the Access Router running multicast protocol in a subnet can act as a MSA. MSA is in charge of local dynamic group membership management information via MLD protocol, and periodically sends query messages to solicit reports of all multicast addresses that are being listened to by local hosts. Tunnel State is a flag in every entry of multicast route table that is maintained by MSA. It represents the state of each group G (record -s whether the multicast packets are received through tunnel). When a MN first joins a multicast group through a MSA, the MSA becomes the current DMA of the MN. Before a new DMA is selected, the current DMA receives multicast data from the tree. When the MN leaves the subnet which its DMA is in and attaches at a new subnet, the MSA in the new subnet gets multicast data through the tunnel from the MSA to the MN's DMA, and then forwards the data to the MN. The current MSA exchanges MLD information with the MN's DMA through the tunnel also. Each MN corresponds with a DMA which is selected dynamically according to passed path of MN. The DMA selecting method and conditions are described in the next sub-section. A MSA will join multicast tree directly if it is selected as a DMA. Dynamic selection of DMA can optimize multicast transmit paths due to the shortest path from DMA to multicast source. Excessively long tunnels can be avoided because of the short distance between DMA and subnet. The DMA can make good use of network resources and avoid choke points of the network, compared with static subnet agent. Tunnel State makes sure that there is only one multicast agent providing service, which corresponds with MNs of a new-join multicast group in a subnet. It can also avoid the tunnel congregation problem. When a MN moves from a subnet to another subnet, it does not need to rejoin multicast trees due to DMA. So the impact on the multicast tree is reduced. 2.2 Operation of MSA Each MSA maintains a Visitor Table. There are two elements kept in every entry of the Visitor Table: MN item and DMA item. The meanings are: Hong-Ke Zhang et al. Expires November 2005 [Page 3] INTERNET-DRAFT Mobile IPv6 Multicast with DMA May 2005 o MN item records the mobile nodes that visit the subnet the MSA belongs to and need to be served; o DMA item records which MSA is selected as the MN's DMA. -------------------- | MN | DMA | |------------------| | | | -------------------- On arriving at a new foreign network, a MN obtains a new CoA (care- of address). The MN registers its current CoA with its HA, and then the MN immediately sends message to its current subnet's MSA. The message mainly contains the MLD group membership report message and the IP address of pMSA (previous subnet's MSA). When receiving the MLD group membership report message that is sent by a new visitor for group G, the detail operations of the MSA are as follows: o If the MSA already has an entry for group G in its multicast route table, add MN to the entry's outgoing interface list, and then examine the Tunnel State. If the Tunnel State is 'YES', it indicates that the MSA has already created the tunnel for the group and is receiving multicast datagrams via the tunnel. In this case, it only requires forwarding the MLD group membership report message to the other end of the tunnel. If the entry related to the MN exists in the MSA's Visitor Table, then the MSA is holding it. Otherwise if there is no entry related to the MN in its Visitor Table, it creates a new entry for the MN. In order to optimize the delivery path, the MSA of the current subnet is selected as the DMA of a MN according to certain rules. In this case, current subnet's MSA adds an entry in its MSA list (detailed in next sub-section) to record the movement path of the MN. And then the current subnet's MSA communicates with the MSA of the previous subnet that MN visited to obtain the IP address of the previous DMA, and informs the previous DMA to delete all data structures that are related to the MN. o If the MSA has no entry for group G in its multicast route table, it indicates that 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 to the entry's outgoing interface list. Hong-Ke Zhang et al. Expires November 2005 [Page 4] INTERNET-DRAFT Mobile IPv6 Multicast with DMA May 2005 o If there already exists an entry related to the MN in the MSA's Visitor Table, only when the MSA of current subnet acts as the DMA of the MN in this entry, the MSA simply sends join messages to the multicast tree. Otherwise if the DMA is not the MSA of current subnet, then set the Tunnel State to 'YES', create tunnel with the DMA of MN, and forward the MLD group membership report message to the other end of the tunnel. o If there is no entry related to the MN in its Visitor Table, the MSA creates one entry for the MN, communicates with the pMSA to obtain the IP address of the previous DMA, and then communicates with the pDMA. If the pDMA doesn't re-select a new DMA, the MSA adds the pDMA to the entry as the MN's current DMA, sets the Tunnel State to 'YES', creates tunnel with the current DMA of MN, and then forwards the MLD group membership report message to the other end of the tunnel. If the pDMA re-selects a new DMA, the MSA of current subnet works as the new DMA, the MSA simply sends join messages to the multicast tree, and at the same time, the current subnet's MSA creates and maintains an entry for the MN in its MSA list. A MN group member doesn't send a leaving message when it departs from the current subnet to visit another; the MSA detects its departure by the timeout of timer. When the MSA detects that a MN is departing from the current subnet, it deletes the entry maintained for the MN in its Visitor Table. For each multicast group G which the leaving MN has joined, the MSA deletes the MN from the group G entry's outgoing interface list. 2.3 Dynamic Multicast Agent Selection In DMA, the key point is the way of DMA re-selecting. The following selection principles are based on both Movement and Distance, and the selection of DMA can be performed by a MN's current DMA or the MN itself. The following description illustrates the dynamic multicast agent selection process by DMA. Each MN corresponds to only one DMA at one time. DMA is a multicast router which participates in Internet routing, provides multicast service for MN, and acts as an access point for the MN to the Mbone. Each multicast router which works as a DMA for an MN maintains a table and computes DMA re-selection for an MN which selects it as its DMA according to a specific rule. The table Hong-Ke Zhang et al. Expires November 2005 [Page 5] INTERNET-DRAFT Mobile IPv6 Multicast with DMA May 2005 changes dynamically with the route which the MN passes through. The corresponding DMA, therefore,is selected dynamically with the position of the MN. That is why it is called dynamic multicast agent (DMA). The MSA list which the corresponding DMA maintains the following records: -------------------- | MN | | -------------------- | MSA | Increment| |------------------| | DMA | 1 | | MSA 1 | 2 | | MSA 2 | 1 | | ... | ... | | MSA n | 3 | -------------------- The meaning of the element in the MSA list is as follows: o MN item records the mobile node which selected the MSA as DMA; o MSA item records MSA of each subnet which MN passes through; o Increment item records maintain the path increment of the MSA. The elements of forming MSA list can be divided into three categories: o If the subnet is the first subnet which the MN passes through, the MSA of this subnet works as DMA, and is the initial DMA of the MN. In this case, it creates and maintains an entry for this MN in the MSA list of this MSA. o When a MN enters a new foreign subnet, the MSA of this subnet receives MLD group member report messages of the MN. If the MSA has a group member of this multicast group, it receives multicast packets and forwards them to the MN. If there is no entry about this MN in the MSA Visitor Table, it selects the MSA of current subnet as DMA of MN to optimize the traffic route. In this case, it creates and maintains tabulation for this MN in Hong-Ke Zhang et al. Expires November 2005 [Page 6] INTERNET-DRAFT Mobile IPv6 Multicast with DMA May 2005 the MSA list of this MSA, and announces the previous DMA to delete all data structures of related MNs. o When a MN joins a new foreign subnet, MSA receives MLD group member report message of the MN. If the MN is the first group member in the subnet and there is no element of this MN in the MSA Visitor Table, the MSA communicates with the previous DMA of MN. If the previous DMA selects a new DMA, the MSA of current subnet works as new DMA, and it creates and maintains an entry for this MN in the MSA list of this MSA. When the entry is created in MSA list for a MN, the MN and its current subnet MSA are written to the location of DMA. Whenever the MN enters a new foreign subnet, the new subnet MSA will communicate with the DMA of the MN. If the DMA receives new messages from the new foreign subnet to inform that a new DMA selection has been taken place, the DMA deletes the entry maintained for the MN; otherwise the DMA will look up the entry list and determine if there is a record for it. If it is null, the DMA adds the new foreign MSA to the MSA list. When the summation of the path increment of MSAs in MSA list reaches the assigned threshold, DMA re-selection occurs. At this point, the old DMA sends a message to the MN, and then the MN gives notice to the MSA of the subnet it belongs to. Once the current MSA receives the message, it will choose itself as the new DMA of the mobile node, and add an entry for the MN in its MSA list. The path increment of a MSA is defined as [Length(MN-DMA)/Length(DMA -S)], where [x] is the minimum integer greater than or equal to x, and Length(y) is the distance of the path y. If the MSA needs to receive multicast packets via the DMA, it creates a tunnel between the MSA and the DMA to establish the existence of the membership. If the DMA has been the member of the group, the DMA will add a link to the MSA in the output interface list. If not,it need to request to add the group. When the DMA receives the multicast packets, it will forward them to all the members of the group through local link, and forward them to other MSAs through a tunnel. 3. Conclusion This document has discussed the support of IPv6 multicast for mobile Hong-Ke Zhang al. Expires November 2005 [Page 7] INTERNET-DRAFT Mobile IPv6 Multicast with DMA May 2005 nodes. The approach presented is based on IETF Bi-directional tunnel and remote subscription. It also integrates the merits of Movement based and Distance based location management methods. The purpose is to optimize mobile nodes multicast path, and meanwhile reduce the latency and the impact on multicast trees which result from the movement and handoff of mobile nodes. Acknowledgements References 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. Normative References [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses Hong-Ke Zhang, Bo Shen, Bing-Yi Zhang NJTU IP Labs Beijing Jiaotong University Beijing 100044 China Phone: +86 10 51685677 Hong-Ke Zhang:hkzhang@center.njtu.edu.cn Bing-Yi Zhang:bingyizhang@hotmail.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 Hong-Ke Zhang et al. Expires November 2005 [Page 8] INTERNET-DRAFT Mobile IPv6 Multicast with DMA May 2005 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 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 November 2005 [Page 9]