Network Mobility Kiyong Park INTERNET-DRAFT Konkuk University Expires April 18, 2006 Sunyoung Han Konkuk University Kicheon Kim Konkuk University Jinpyo Hong Hankuk University of FS Oct, 2005 Dynamic Multicast Tree Construction for NEMO draft-park-nemo-dyn-multicast-tree-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. 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 Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved Abstract Multicast Supporting is one of the most important issues in Network Mobility Environment, because some killer applications related to multicast service need to be provided on Next Generation Network. However, current NEMO technique based on basic support protocol have got many problems to support the service such as route optimization, pinball route, mass of multicast problem, etc. the most signficant problem of the service in NEMO environment is that Mobile Network cannot be sure that multicasting from parent mobile networks is possible when the network is nested, Moreover, even though the best case that all mobile networks have its own multicast router is supposed and multicasting is working well, the multicast route tree can not be optimized due to different MNPs of the multicast routers in each nested network. This document defines additional functions of each component to enable dynamic multicast tree construction for multicast service in Mobile Network. Expires: April 18, 2006 [Page 1] INTERNET-DRAFT Dynamic Multicast Tree Construction for NEMO Oct, 2005 Table of Contents 1. Introduction 2. General Terms 3. Overview 3.1 Applicable Previous Techniques 3.1.1 MIP-BT 3.1.2 MIP-RS 3.2 Current Problems 3.3 Assumption 3.3.1 Multicast Router Functionalities in Mobile Router 3.3.2 Prefix Delegation Mechanism 4. Extensions 4.1 Default Multicast Router Information field 4.2 Router Advertisement Message Source option 4.3 Active Router Extension 4.4 Mobile Router Extension 4.4.1 Router Advertisement Message Propagation. 4.4.2 Multicast Tunnel Construction 5. Operation Flow 6. Conclusion 7. Acknowledgements 8. References 9. Authors 10. Full Copyright Statement Expires: April 18, 2006 [Page 2] INTERNET-DRAFT Dynamic Multicast Tree Construction for NEMO Oct, 2005 1. Introduction Multicast support is one of the most challengeable issues in mobile environment. Although basic architectures to support multicasting on mobile environment based on Mobile IP technology [1] were suggested. Unfortunately, the architectures are not standard. In these circumstances, issuing multicast on NEMO [2][3][4] can be ahead of the times. However, multicasting on NEMO must be standardized for the purpose of making killer applications and commercial benefits in Next Generation Networks. NEMO basic architecture has been faced at fundamental problem of route optimization called Pinball Route [10]. This problem is getting critical more and more when the network is nested deeper. This problem is caused by Bi-directional tunneling and must be solved to enable multicast service on NEMO too. Fortunately, the solution was suggested and it is based on Prefix Delegation (PD) Mechanism [5] in IPv6. Therefore, In this time, multicasting techniques on NEMO must be reinvestigated. Because, in NEMO, the entire network moves away. The multicast router realizes that the network to service multicast disappeared or it moves away from the service network. In addition to it, when the mobile networks are nested, multicasting from upper mobile network may be impossible for the reason of upper network's network management rules. To support multicast completely in NEMO, all disturbances stated above must be solved and proper solution must be created This memo, to create proper solution of multicasting on NEMO, explains interoperation among multicast router, mobile router, active router and some flows to construct route optimized multicasting model on NEMO 2. Terminology The keywords "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. Expires: April 18, 2006 [Page 3] INTERNET-DRAFT Dynamic Multicast Tree Construction for NEMO Oct, 2005 3. Overview 3.1. Applicable Previous Techniques In early Mobile-IP (MIP) technologies, basic architectures such as MIP-BT (Bidirectional Tunneling) , MIP-RS (Remote Subscription) [7] and Multicast Proxy Server [8], were suggested to provide multicast service for Mobile hosts. These techniques can be basic architectures for mobile network to support multicast service. 3.1.1. MIP-BT (Bidirectional Tunnel) In MIP-BT, a mobile node in a foreign network receives multicast data packets from the mobility agent in the home network by bi-directional tunneling. This approach assumes that the home agent has multicast router functions or there is a multicast router in the home network. The home agent intercepts multicast packets that the mobile node used to receiving, encapsulates and transmits them to the mobility agent in the foreign network (called 'foreign agent'). When the foreign agent receives these packets, it decapsulates them and sends to the local network. 3.1.2. MIP-RS (Remote Subscription) In MIP-RS, when a mobile node moves to a new network, it sends IGMP messages to the local network in order to rejoin the multicast group [6], so that it can receive multicast data packets from the local multicast router of the foreign network. 3.2. Current Problems Because NEMO basic support architecture has inherited Mobile IP and related techniques, many serious problems in supporting multicast in Mobile IP still exist in NEMO. Major problems are tunnel convergence problem, mass of multicast problem [9], and route optimization problem. Furthermore, because NEMO basic support is using bi- directional tunnel, multicasting on NEMO has the serious weakness called the pinball route problem, which can be classified into a route optimization problem. If MIP-BT is adopted on NEMO, the tunnel convergence problem occurs and it gives much overhead not only on MRs but also on AR because they must process many tunnels, while the problem gives some loads only to AR or mobility agent on pure Mobile IP. Furthermore, the more networks are nested, the more damages occur in the entire mobile network. Expires: April 18, 2006 [Page 4] INTERNET-DRAFT Dynamic Multicast Tree Construction for NEMO Oct, 2005 If MIP-RS is adopted on NEMO, MNs in the mobile network can not join a multicast group, because they don't know where multicast routers are located. Moreover, their IGMP [6] messages cannot be routed to a multicast router, because their IGMP messages might not be routed by the MR's upper router for their different mobile network prefixes. 3.3. Assumption 3.3.1. Multicast Router Functionalities in Mobile Router Firstly, we must handle the multicast support on a mobile network itself, otherwise no MNs in mobile network are sure of the reception of multicast data. Furthermore, lots of tunnels will generate network congestions in the mobile network and its ascendants as explained in 3.2. these problems cannot be solved until mobile network has a multicast router or MR has multicast router functions. For above reasons, we assume that in our method, multicast router functions are built in MR. if any network which do not want to support multicast service is exits, it would not have the functions. 3.3.2. Prefix Delegation [PD] Mechanism in IPv6 In NEMO basic support architecture, bi-directional tunnel is used for a MR to communicate with its home network. But it causes a serious problem of route optimization, called the pinball route problem. It happens again in the case of multicasting whenever a mobile network is nested. To overcome this weakness, we adopt the Prefix Delegation mechanism. It achieves route optimization of multicast tunnel between a MR and its HA. That is, multicast tunnels in our method are made from internet address of the multicast router directly to MR's CoA. Expires: April 18, 2006 [Page 5] INTERNET-DRAFT Dynamic Multicast Tree Construction for NEMO Oct, 2005 4. Extensions To complete route optimized multicast on NEMO, our method extended each part of components in mobile network to support multicast. 4.1. Router Advertisement (RA) Message Source option A new option bit named 'S' indicates where this RA message [11] was sent from. If this bit is checked, it means the RA message was from MR, otherwise, AR. shows 'S' bit. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cur Hop Limit |M|O|H|S| Res. | Router Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... Router Advertisement Message with 'S' bit 4.2. Default Multicast Router Information (DmRI) in RA Message This Information is used for AR's and MR's RA message to carry a Multicast Router Address Information and it is an optional extension part of Router Advertisement message [11]. We suggest the type number of this option to 10. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Default Multicast Router Address (128 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Optional Extension in RA message 4.3. Active Router Extension AR may have DmR information, explained above chapter 4.2 in its configure file. When the AR starts up, it must insert the information into its RA messages as an optional part and advertise it. Expires: April 18, 2006 [Page 6] INTERNET-DRAFT Dynamic Multicast Tree Construction for NEMO Oct, 2005 4.4. Mobile Router Extension There are 2 extensions on Mobile Router. The first is RA message propagation with its newly defined 'S' bit and the second is multicast tunnel construction when it starts up in Home Network and it handover to Foreign Network. Note that we supposed multicast router functions on Mobile Router. 4.4.1. Router Advertisement Message Propagation MR must keep the DmR information in its buffer, when it read the information from RA message. And it must insert the information in its RA messages as an optional part as same method as AR did. Finally, it must check 'S' bit in its RA message explained in chapter 4.1. If there is no DmR Information, the MR does not check 'S' bit on RA messages. 4.4.2. Multicast Tunnel Construction The MR must be able to establish a multicast tunnel (multicast route tree) with fixed multicast router and re-establish the tunnel with new multicast router in run-time. Expires: April 18, 2006 [Page 7] INTERNET-DRAFT Dynamic Multicast Tree Construction for NEMO Oct, 2005 5. Operation Flow When Mobile Network starts up firstly, the MR must keep the DmRI in its cache, only if the information is retrieved from RA messages. When the MR received IGMP Group Join messages from its on-link nodes, it must construct multicast route tree onto its DmR as a parent. There are two different cases on it. First, It must construct multicast tunnel with Default Multicast Router it keeps only if the DmRI was retrieved from 'S' bit not checked RA messages, that means AR's RA message. Second, It must construct multicast tunnel with upper MR only if the DmRI was retrieved from 'S' bit checked RA message, that is upper MR's RA message. In opposite to above, the RA message has neither 'S' bit nor DmRI, then the MR is in a network which does not support multicasting. Note that PD mechanism was applied on the mobile network, thus, the multicast tunnel is established between MR's CoA and Multicast Router's Native internet address or between MR's CoA and upper MR's CoA. shows above operation flows. _________________________ _______ | | | | | | | DmR |----| Internet | |______| | | * |________________________| * __|__ * | | * | AR | Access Router with DmRI * |____| * home ______|_____________ RA message with DmRI * link | * __|__ ***************************| | | MR | Mobile Router *******|_____| * ____|__________ RA message with DmRI * | | and 'S' bit * __|__ __|__ * | | | | ******| MR | | MN | |_____| |_____| ****** Multicast Tree Multicast Tree when MR starts up Expires: April 18, 2006 [Page 8] INTERNET-DRAFT Dynamic Multicast Tree Construction for NEMO Oct, 2005 When Mobile Network detects its movement, at that time, there are two different cases on it. First case is that the mobile router already has a multicast route tree with previous DmR or previous upper MR. Second case is that the network moved without multicast service. In Second case of it, it is just like the processes that the network starts up firstly, explained above. But, First case is more complex. In First case, if the MR detects its movement, it must re-establish multicast tunnel with the DmR, it keeps, rapidly. Because the DmR is unique and fixed multicast router information of the previous network and all multicast data in the network was via the DmR, the multicast groups the MR want to listen are, clearly, served by the DmR. Therefore, the multicasting the MR wants is well working without additional delay only by re-establishing multicast tunnel with it. shows above operation flows. _____________________________ | | | | | Internet | | | |____________________________| __|__ ___|____ __|__ | | | Prev. | | | | AR | | DmR | | AR | |____| |_______| |____| foreign ___|___ * * ___|________ home link link | * * | __|__ * * | | * * | MR |******* * |_____| * __________|_____ * | | * __|___ __|___ * | | | | * | MN | | MR |****** |_____| |_____| ****** Multicast Tunnel Multicast Tunnel when MR detects its movement Expires: April 18, 2006 [Page 9] INTERNET-DRAFT Dynamic Multicast Tree Construction for NEMO Oct, 2005 Finally, if the MR read the RA messages in new network multicasting with previous network's DmR, there are three different cases on it. First case is RA message does not contain DmRI. Second case is RA message contains DmRI with 'S' bit, that is the network is nested. Third case is RA message contains DmRI with no 'S' bit. If the case is first one, the MR does nothing more, the multicasting is well working with the DmR in the MR's previous network. If the case is second one, that is the RA messages was from upper MR, then multicast tunnel must be re-established with upper MR, the MR must send IGMP Join messages of all groups it is listening and the MR must update old DmRI with new one. Finally, If multicast data is detected from newly established multicast tunnel, destroy previous multicast tunnel with previous DmR. If the case is third one, then the MR must re- establish multicast tunnel with new DmR, send IGMP Join messages of all groups it is listening and update old DmRI with new one. Finally, if multicast data is detected from newly established multicast tunnel, destroy previous multicast tunnel with previous DmR. shows final multicast tunnel created. _____________________________ _______ | | | New | | | | DmR |-----| Internet | |______| | | * |____________________________| * __|__ ___|___ __|__ * | | | Prev.| | | * | AR | | DmR | | AR | * |____| |____ _| |____| * ____|___ foreign ___|________ home link * | link | * __|__ * | | ********| MR |****** |_____| * _________|_____ * | | * __|___ __|__* | | | | | MN | | MR | |_____| |_____| ****** Multicast Tree Multicast Tree with new DmRI in new RA message Expires: April 18, 2006 [Page 10] INTERNET-DRAFT Dynamic Multicast Tree Construction for NEMO Oct, 2005 6. Conclusion This memo examined and analyzed problems of providing multicast service on NEMO basic support architecture, and the purpose of this memo is that provides optimized route path for multicasting in NEMO. As presented in the previous sections, our mechanism eliminates the complexities of multicast data flows on NEMO environments. Specifically, in our method, A. There is no Pinball Route problem of multicast data B. There is no bi-directional tunnel for multicast data between MR and its HA C. Once a MR has provided multicast service in home network, it can permanently provide multicast service till it is shut down D. MRs in mobile networks have native route path for multicast data E. Minimized multicast tree reconstruction delay This study is a work in progress and need to be improved by any other individual or commercial issues. Specially, this work can be adopted on Next Generation Network's Killer Application such as Mobile Video on Demand, etc. We will add security issue such as Group Key Distribution Mechanism, etc. And also encourage people who are interested in this work to contribute this work. Expires: April 18, 2006 [Page 11] INTERNET-DRAFT Dynamic Multicast Tree Construction for NEMO Oct, 2005 7. Acknowledgement The authors would like to thank people who have given valuable comments on various Mobile Multicast and Network Mobility issues. 8. References [1] D. Johnson, C. Perkins, J. Arkko, Mobility Support in IPv6, RFC 3775, Jun 2004. [2] Thierry Ernst, Network Mobility Support Goals and Requirements, Internet Draft, , May 2003. [3] Thierry Earnst, Hong-You Lach, Network Mobility Support Terminology, Internet Draft, < draft-ietf-nemo-terminology- 00.txt>, May 2003. [4] Vijay Devarapalli, Ryuji Wakikawa, NEMO Basic Support Protocol, RFC 3963, Jan 2005. [5] T. Kniventon, P. Thubert, Mobile Network Prefix Delegation, Internet Draft, , Aug 2005. [6] W. Fenne, Internet Group Management Protocol, version 2, RFC2236. [7] V. Chikarmane et al, Multicast Support for Mobile Hosts Using Mobile IP: Design Issues and Proposed Architecture, ACM/Baltzer Mobile Networks and Applications, vol 3, no 4, pp 365-379, January 1999. [8] Hee-Sook Shin, Young-Joo Suh, and Dong-Hee Kwon, Multicast Routing Protocol by Multicast Agent in Mobile Networks, Proceedings of the Proceedings of the 2000 International Conference on Parallel Processing, pp 271-278. [9] Kuang-Hwei Chi, Chien-Chao Tseng and Ting-Lu Huang, A Framework for Mobile Multicast using Dynamic Multicast Route, The computer journal, vol 42, no 6, 1999. [10] Thubert, P., and Molteni, M., Taxonomy of Route Optimization Models in the NEMO Context, Internet Draft: draft-thubert-nemo- ro-taxonomy-00, Oct 2002 [11] T. Narten, Neighbor Discovery for IP Version 6 (IPv6), RFC 2461 Expires: April 18, 2006 [Page 12] INTERNET-DRAFT Dynamic Multicast Tree Construction for NEMO Oct, 2005 9. Authors' Addresses Kiyong Park Computer Communication Laboratory, Department of Computer Engineering, Konkuk University Hwayang-Dong KwangJun-Gu Seoul Korea Phone: +82-2-450-3537 Fax: +82-2-444-1548 EMail: kypark@cclab.konkuk.ac.kr Sunyoung Han Computer Communication Laboratory, Department of Computer Engineering, Konkuk University Hwayang-Dong KwangJun-Gu Seoul Korea Phone: +82-2-450-3537 Fax: +82-2-444-1548 EMail: syhan@cclab.konkuk.ac.kr Keechoen Kim Next Generation Internet Communication Laboratory, Department of Computer Engineering, Konkuk University Hwayang-Dong KwangJun-Gu Seoul Korea Phone: +82-2-450-3518 Fax: +82-2-453-3518 EMail: kckim@konkuk.ac.kr Jinpyo Hong Computer Communication Laboratory, Information and Computer Engineering, Hankuk University of FS Mohyun-Myun Yongin Kyunggi-Do Korea Phone: +82-31-330-4116 Fax: +82-31-334-3087 EMail: jphong@hufs.ac.kr 10. Full Copyright Statement 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. Expires: April 18, 2006 [Page 13]