Efficient algorithm for mobile multicast using anycast group

Deakin Research Online Deakin University’s institutional research repository DDeakin Research Online Research Online Th is is t h e a u t h or s fin a l pe e r r e vie w e d ve r sion of t h e it e m pu blish e d a s: Jia, W., Zhou, Wanlei and Kaiser, J. 2001, Efficient algorithm for mobile multicast using anycast group, IEE proceedings- communications, vol. 148, no. 1, pp. 14-18. Copyr igh t : 2001, IEEE z zyxwvutsr zyxwvutsrqp Efficient algorithm for mobile multicast using anycast group W.Jia, W.Zhou and J.Kaiser Abstract: The authors present a novel and efficient multicast algorithm that aims to reduce delay and communication cost for the registration between mobile nodes and mobility agents and solicitation for foreign agent services based on the mobile IP. The protocol applies anycast group technology to support multicast transmissions for both mobile nodes and homeiforeign agents. Mobile hosts use anycast tunnelling to connect to the nearest available homeiforeign agent where an agent is able to forward the multicast messages by selecting an anycast route to a multicast router so as to reduce the end-to-end delay. The performance analysis and experiments demonstrated that the proposed algorithm is able to enhance the performance over existing remote subscription and bidirectional tunnelling approaches regardless of the locations of mobile nodesihosts. 1 Introduction Mobile computing requires wireless communication, mobility and portability. Mobile multicast [I] is an important service for mobile applications through wireless and connection to the Internet, such as email communication, query database, retrieving infomyation, video conferencing through wired networks etc. The provision of a multicast service to mobile nodes is a complex task especially in the wireless environment. The physical constraints of mobile coimnunications typically include low bandwidth of link layer connection, high error rates, and temporary disconnection. IP multicast [2] provides unreliable multicast delivery for wired networks. In mobile multicast communications, two issues are of primary importance: one is for mobile nodes and mobility agents to discover each other’s presence, and another is the datagram routing efficiency. Traditional multicast research discussed reliability of message delivery in the multicast group in guaranteeing properties such as total ordering, atomicity, dynamic group membership and fault-tolerance etc. [3]. Some well known wireless multicast systems have been developed. Forwarding pointers and location-independent addressing to support mobility has been discussed [4], but the multicast service is unreliable. A host view management protocol (HVMP) has been developed that provides reliable multicast for mobile nodes [5]. However, it does not allow dynamic group membership. Brown and Singh [6] have proposed a protocol that allows dynamic group changes and reliable multicast message delivery with different network architectures. Multicast tunnelling is proposed zyxwvut zyxwvutsrq for forwarding multicast packets from one foreign network to another when the mobility agent receives packets addressed to mobile nodes that are nomadic [7]. I . I Problems with mobile IP Mobile IP [l] defined three approaches to support mobile connection and multicast: first, agent discovery, where home agents (HAS) and foreign agents (FAs) may advertise their availability on each link for which they provide service. A newly arrived mobile node can send a solicitation on the link to learn if any prospective agents are present. Secondly, remote subscription, when a mobile node is away from home, it registers its care-of address (an IP address at the mobile node’s current point of attachment to the Internet when it is not attached to the home network [l]) with its home agent. Depending on its method of attachment, the mobile node will register either directly with its home agent or through a foreign agent, which will forward the registration to the home agent. Thirdly, bidirectional tunnelling multicast, in this case unicast tunnels are used to encapsulate and to send multicast packets over the Internet when the intermediate routers cannot handle multicast packets. For multicast datagrams to be delivered to the mobile node when it is away from home, the home agent has to tunnel the datagrams to the care-of address. A mobile node is addressed on its home network that is known as its ‘home address’. Agent discovery may require more advertisements and solicitation messages. Remote subscription is inefficient for dynamic membership and location change of mobile nodes. Bidirectional tunnelling multicast may cause the tunnel convergence problem with packet duplication [5] (Fig. 1). zyxwvu zyxwvutsrqponmlkjihgfedc 0IEE, 200 I IEE Proceding.Y online no. 20010211 DOI: 10.1049/ipconi:20010211 Paper first receivcd 9th August 1999 and in revised foiiii 24th JUIY2000 W. Jia is with the Department of Computer Science, City University of Hong Kong, 83 Tat Chee Avenuc, Hong Kong W. Zhou is with the School of Computer Science and Mathematics, Dcakiii University,662 Blackbum Road, Melbourne, Australia J. Kaiser is with the Department of Computer Sti-uctures. University of Ulm, James-Fraiick-Ring, 89069 Ulm, Geimany Fig. 1 Bi&ctionnl tLmelled multicuyt metl?od FA - roreign agent; FN work; MH niohilc host ~ foreign network; HA ~ 14 ~ zyxw zyxw home agent; HN ~ home net- IEE P~~~c.-Coriiinun., Vol. 14R, No. 1. Febrirrrrji 2001 Authorized licensed use limited to: DEAKIN UNIVERSITY LIBRARY. Downloaded on December 21, 2008 at 18:05 from IEEE Xplore. Restrictions apply. zyxwvutsr 1.2 Motivation of the research The anycast address and service have been defined for Internet protocol version 6 (IPv6) [7]. It is a comniunication for a single sender sending to the ‘nearest’ member in a group of receivers, preferably only one of the servers that supports the anycast address [8]. It uses a unicast address and the router can register the anycast address for its interface. Anycast is useful when a host requests a service from a server in a group but does not care which server is used. Anycast can simplify the task of finding an appropriate server. For example, users can use the anycast address to choose the mirrored FTP sites and to connect to the nearest (available) server. To improve the efficiency in terms of mobile IP on multicast communication, particularly in terms of the three issues mentioned above, we propose a novel efficient mobile multicast protocol (MMP), taking advantage of anycast routing technology. The MMP has two aims: first, mobility agents (MAS, both HAS and FAs) anycast group to facilitate flexible connections for mobile nodes. Using a well known anycast address, the HAS need not multicast/ broadcast router advertisement and the mobile nodes may register directly through the well known anycast address of the anycast agent groups so as to reduce the connection cost for the mobile nodes. Secondly, an anycast address is configured by a group of multicast routers on the subnet that are designed to support a specific multicast group. Using anycast can dynamically select the paths to the multicast router to reduce the end-to-end multicast delay. The second issue has been considered in [9, 101 and we omit the discussion in this paper due to lack of space. Our mobile multicast protocol (MMP) 2 Before describing the protocol, the following assumptions are made (see Fig. 2 for example of MMP topology): A set of hosts and mobile nodes forms a multicast group G. Each individual mobile node has knowledge of the multicast group id to which it wishes to transmit and accept multicast messages. HA and FA are special routers that provide service for the attachment of mobile nodes. There is at least one MA in each subnet. VL(G),records the IDS of foreign mobile nodes that belong to G that visit this MA; the away list, AL(G), records the IDS of mobile nodes in G that departed (or were disconnected) from this MA; finally, the tunnelling list, TL(G), records the IDS of foreign agents that are interested in transnlissiodreception of multicast packets for G. The MMP is designed in three major phases that work interactively: (i) Initialisation phase: configurations of multicast and anycast group for routers, mobility agents and mobile nodes; (ii) Registration and membership phase: registrations and reformation for the dynamic membership of mobile nodes; (iii) Multicast transmission phase: multicast packet transmissions and deliveries for the group of members including station hosts and mobile nodes. 2. I Phase 1: Initialisation (i) Membership initialisation for a given group of G: an individual MA sets ML(G) = VL(G) = AL(G) = TL(G) = 0. (ii) Multicast tree formation: The core-based tree (CBT) technique is used to build a multicast propagation tree for the routers (called a CBT tree). One router is selected as the core (or root) of the tree. To establish such a tree, MAS that provide multicast service for G must join the CBT tree by linking themselves to the core [lo, 111. All routers including MAS in the tree are called ontree routers. (iii) Mobility agent anycast group configuration: the mobility agents that offer attachment for mobile nodes in G form an anycast group [9]. All the mobility agents that provide connections for G can register through well known group reserved anycast address GA [8] and configure one of its interfaces to accept the registration for home/foreign mobile nodes. Our protocol defines that the agents in the same anycast group GA will share the same authentication for mobile node registrations, i.e. MAl E GA and MA2 E GA imply that both MA, and MA2 agree to delegate connection authentication and multicast packet delivery to each other for the mobile nodes that were previously attached to another party. (iv) Ontree router anycast group configuration: for the group G, virtual anycast address T A is assigned to and configured by all routers in the CBT tree for group G [9]. The router configurations are classified as ontree and offtree: Ontree router configuration: For a multicast group G, when the CBT tree is built, all ontree routers (including the core) are selected to join an anycast group with anycast address TA which is advertised to the network (broadcast by the core). T A may be considered as some ‘temporay’ anycast address as long as the CBT tree exists. For any ontree router, there is a forwarding information base (FIB) used as its multicast routing table [9, 111. An entry in the FIB has the form <G, inputinterface, output-interfaces>. Offtree router configuration: Upon reception of address T A broadcast from the core in the CBT tree, the offtree routers, including those foreign agents, that are interested in transmitting multicast packets to G will assign TA as an interface entry by configuring with <TA, G> mappings in the routing table. The anycast routing table enables the router to dynamically select a ’better’ path to reach the CBT tree among multiple paths even in the presence of link or hop failure. For details of fault-tolerant CBT routing algorithms, we refer interested readers to [IO]. zy zyxwvuts zyxwvutsrqpo zyxwvutsrqponmlkj zyxwvutsrqponmlkj zyxwvutsrqponmlkjihg Fig.2 M M P topology aid mobile coiiiiectiom MA MH inobility agent mobilc host nctwork HN home nctwork R - router does not support multicast M R - router supports multicast tunnel from MA to MR FN - ~ ~ - foreign ~ A multicast router can configure its interface to route both multicast and anycast packets [9]. Each MA maintains four lists for the dynamic memberships of mobile nodes in multicast group G: the membership list, ML(G), contains the IDS of members in group G; the visitor list, IEE P i o c -Cummiin, Vol 148. No 1. FeLviioiy 2001 Authorized licensed use limited to: DEAKIN UNIVERSITY LIBRARY. Downloaded on December 21, 2008 at 18:05 from IEEE Xplore. Restrictions apply. 15 zyxwvutsrq zyxwvuts zyxwvut 2.2 Phase 2: Dynamic member registration and connection With the proposed anycast group, a mobile node may learn existing agents by caching the anycast address through DHCP or SLP services [12, 131. In the register message of mobile node, normally the D-bit is set to enable the mobile node to receive/decapsulate incoming multicast packet [ 11. MMP allows membership changes to be made to a multicast group G. A mobile node is allowed to join or leave a multicast group at will. The concept of dynamic group membership is similar to the host view and supervisor host [14]. To join a multicast group G in the home network, a mobile node must register through the home agent. In the current mobile IP, a mobility agent must also broadcast advertisement messages periodically (similar to ICMP advertisement messages [15]) and the mobile node has to send a solicitation message to contact the agent when it hears no advertisement for a certain period of time. This phase is designed to reduce the cost of advertisement using an anycast group by the following steps: Step 1. Mobile node home registration: A mobile node MII must register through its home agent and join G for multicast message transmission. The registration can be accomplished through anycast connection by using GA to connect to the ‘nearest’ MA in its home network. On establishment of the connection between MA and Mn, two cases must be considered: Case 1: The MA is an ontree router of G: Similar to the mobile IP [I], the MA performs the corresponding authentication and mobility binding such as care-of address (CA) assignment to Mn (denoted as CA(Mn)) and calls Znsert(CA(Mn)),ML(G)) to insert CA of Mn into membership list ML(G). Case 2: The MA is an offtree router. Similar to case I , the MA must first check authentication of Mn, then calls Insert(CA(Mn),ML(G)).The following subcases must be considered: Subcase 1: The MA is a multicast router and uses GA to join CBT tree for G by sending join-request to the ‘nearest’ ontree router in TA[9, 101. Subcase 2: The MA is not a multicast router. It builds an anycast tunnel to the ‘nearest’ ontree router so that a single ‘tree trunk‘ is grafted on the CBT tree [IO]. Step 2. Mobile node visits a foreign network: A mobile node Mn originally registered in MA, E GA in subnet 1 and moves to foreign network subnet 2 to connect with MA2. Two cases must be considered: Case 1:MA2 E GA,since both MA, and MA2 are in GA, they are in the same authentication group. Mn may use address GA to make contact with MA2 for registration. On checking authentication and acceptance for Mn, MA2 executes Insert(CA(Mn), VL(G)). On the other hand, MA1 calls Move(CA(Mn), ML(G), AL(G)) to move CA of M n from the membership list ML(G) to the away list AL(G). Case 2: MA2 @ GA, MA2 does not provide service for multicast group G. Thus, MA2 applies a bidirectional tunnelling approach similar to the mobile IP [l]. Upon acceptance of the visit of Mn, MA2 calls Insert(CA(Mn), VL(G)).Since MA2 is not an ontree router, it sets a tunnel to MA1 and the later calls Insert(id(MA2), TL(G))to record the tunnelling information for MA2. Step 3. Mobile node leaves: When a mobile node leaves its home network, it should notify its home agent MA by sending a deregistration message. The latter calls Move(CA(Mn), ML(G), AL(G)). If ML(G) = VL(G) = TL(G) = {}, i.e. the MA has neither a mobile node attached to G nor any tunnel for visitor members in G, then the MA uses an IGMP message to notify its up-link node until ‘core’ to trim this branch from the CBT tree WI. Step 4. Foreign mobile nodehgent leuves: An MA may set up a specific timeout for the foreign mobile nodes in list V L ( 0 . When the timer expires, the MA just deletes the node ID from its VI,(@. A similar approach can be applied for the management of list TL(G). 2.3 Phase 3: Multicast transmission phase (i) Multicast transmission: A mobile node may generate a multicast message m intending to send to G. Message m is thus transmitted to home agent MA. When MA receives m, it first encapsulates m with a multicast header and then imbeds m within an anycast address TA into an anycast packet mA. The packet is then routed to the address TA using dynamic anycast routing algorithms [9]. When a router in T A receives the anycast packet, it strips off the anycast header of mA into m and propagates it across group G. For a visited mobile node Mn, if it wants to send the multicast packet, the packets can be forwarded through the FAs. As in the mobile IP, a co-located care-of address on the foreign network is required and used as the source address for multicast packets to group G. (ii) Multicust pucket reception-delivery: When an MA receives an encapsulated multicast packet m from a router on the CBT tree, it strips the multicast header from the packet and makes the packet delivery to the IDS in ML(G) and VL(G).The packet is also tunnelled and retransmitted to the agents in TL(G)when TL(G)is not empty. Note that if the mobile node is using a co-located care-of address, it should use this address as the source IP address of its IGMP [16] (membership) messages; otherwise, it is required to use its home address for multicast transmissions. zyxwv zyxwvutsrqp zyxwvutsr I6 3 Performance This Section presents the performance analysis for the MMP protocol and demonstrates experimental results to show the availability of the protocol by simulation results, in particular, it compares the complexity of MMP with remote subscription (RS) and bidirectional (BD) approaches in terms of number of broadcasb‘multicast packets and end-to-end delay of multicast. Table 1: Performancecomparisons Operations Protocols Number of messages (m/bcasts) Agent discovery Mobile IP MMP 1 0 1 0 Registration on HA RS 2 2 1+2A 2A 4 1+4A 2A MMP Registration on FA 3. I BD MMP 2 Delay (’) zyx Analysis To analyse the performances of the MMP protocol, we use the following metrics for the comparison of MMP with methods proposed in mobile IP [I]: number ofnzessages ( h c u s t s ) , this is the number of messages (including multicast and broadcast) required for the corresponding operation. I E E P,oc.-Cumnziin., Vol. 148, Nu. I , February 2001 Authorized licensed use limited to: DEAKIN UNIVERSITY LIBRARY. Downloaded on December 21, 2008 at 18:05 from IEEE Xplore. Restrictions apply. zyxwvutsrqpon zyxwvutsrqp delay, this is the total delays in seconds to accomplish the operation and A is used to measure a single multicast/ broadcast (minimum) transmission delay. According to the mobile IP, the agent discovery requires the MA to send a broadcast for agent advertisement. Mobile nodes use these advertisements to determine their current point of attachment to the Internet. The advertisement is sent at a maximum rate of once every second (hence the delay). Therefore, for a mobile node, it has to wait for the advertisement and then it discovers the presence of MA. With MMP, in the presence of anycast address G,4, mobile nodes are aware of the presence of MA. Thus no agent advertisement is required. For registration of a mobile node, we differentiate the registration on the HA from that on the FA. If the registration is on the HA, in terms of message number, MMP is the same as the protocols based on mobile IP. But the delay is shorter as MMP does not wait for the advertisements of HA. Only the transmission delay of two messages is taken into account. Mobile IP makes use of bidirectional tunnelling for a mobile node to register lo a foreign network under the assumption that its HA is a multicast router. The mobile node tunnels IGMP messages to its HA and the HA forwards the multicast datagram down the tunnel to the mobile nodes. It is known that four messages are required: one is the request from a mobile node to FA, then FA relays the request to HA. HA, in turn, sends back a message of acceptance or denial to FA and then FA relays the final status to the mobile node. While in MMP, if the FA is in the same anycast group as that of the HA, only two messages are required: the registration through FA is the same as through HA. For the delay analysis, the reasoning is similar to the above argument. recipients is done by scheduling from the source to a mobility agent, and then to the mobile nodes. To simplify the simulation, the topology of LANs is located on an x-y coordinate as shown in Fig. 3. The network topology between the LANs is not drawn for simplicity. The simulation experiments were conducted using a multi-factor experimental design. The warm-up period used for the simulations was 20% of the simulation time t, which is an input parameter. After the warm-up period, the simulator collects simulation statistics relating to the mobile multicast until the end of the simulation. We execute ten simulations for each set of workload parameters and obtain the mean value. 3.3 Simulation results The experiment compares the effectiveness of multicast delivery of MMP with bidirectional tunnelling in terms of message delivery delay and number of delivered messages. The simulation considers one multicast group with up to 90 (mobile) nodes across nine LANs, and 8500 multicast messages are generated within 2500s. Lo 1401 zyxwvutsrq zyxwvutsrqp zyxwvutsrqp zyxwvutsrq 3.2 Simulation model In the simulation, we consider 16 local area networks (LANs) with a maximum of 90 mobile nodes. Each LAN has two mobility agents (i.e. one HA and one FA). All mobile nodes are allowed to roam in the network at random. The residency time for each mobile node to stay at a network (home or foreign) is drawn from an exponential distribution with a mean of r time units. The travel time for going between subnets is exponentially distributed with a mean of (d0.9) * 0.1 time units. Thus, mobile nodes spend 10% of their time in transition, and 901%of their time connected to a LAN. In addition, each mobile node has a probability p of losing the connection with a local mobility agent. X 0 9 18 27 36 45 54 63 72 81 90 multicast group size (no. of mobile nodes) Fig. 4 Messcige delivery dehys N = 9, 8500 messagcs generated -+-W- MMP bidircctioiial tunnelling 9000 r 9I7000 E 6000 U 4 5000 > ._ 4000 c 3000 a 5 2000 S 1000 zyxwvutsrq 0000zyxwvutsrqp (3000 0 Y LAN9 LAN10 LAN11 LAN12 Fig. 3 LAN15 36 45 54 63 72 81 90 MMP bidireclional Luiinclling LAN16 Network topology of sirnukition We assume that each multicast group has only one source for generating multicast messages in ratio of A. time units. The delivery of each multicast message to the group 11% 27 Fig. 5 Number. of delivered nie,s.suge.s N = 9, 8500 messagcs generated -U- LAN14 18 multicast group size (no. of mobile nodes) -e- LAN13 9 Proc.-Comnum, Vol. 148. N o I , F t h i n r y 2001 zyxwvut Fig. 4 shows that our protocol can provide a better multicast service to mobile nodes as the message delivery delay is lower than that of bidirectional tunnelling. The high delay demonstrates the transmission overhead in the tunnel from home network to foreign network of bidirectional tunnelling. Fig. 5 shows that about 90% of the generated Authorized licensed use limited to: DEAKIN UNIVERSITY LIBRARY. Downloaded on December 21, 2008 at 18:05 from IEEE Xplore. Restrictions apply. 17 messages were delivered to the mobile nodes by MMP and about 50’31 of the generated messages were delivered by the bidirectional tunnelling protocol. For MMP, two situations may affect the delivery of multicast messages to the mobile nodes: first, the node may be in transit state; and secondly, the node may be attached to a network with poor link connection due to the noise environments. The unsuccessful deliveries in bidirectional tunnelling may be caused by inconsistent information in home network about the location of its mobile nodes. 4 Conclusions zyxw zyxw zyxwvutsr zyxwvut MMP extends the mobile IP with anycast address group technology for agent discovery, registration of mobile nodes and delivery of multicast packets. The utilisation of an anycast address for the mobility agent group can reduce the cost and delay when the mobile nodes register with mobility agents between subnets without impacting its performance. In contrast to bidirectional tunnelling and remote subscriptions, MMP is more efficient in terms of delivery delay and throughput of multicast packets. The cost of employing the anycast addredgroup is that the multicast routers involved in the group have to manage the anycast addresses. This management may be taken as a setup cost and will not compromise the (run time) dynamic performance of MMP. In this sense, MMP will extend the performance of mobile IP, especially when multicast services are desired. 5 Acknowledgments This work was partially sponsored by the City University of Hong Kong under grants 7001060, and UGC (University Grant Council) Hong Kong under grants 9040352 CityU 1059/98E and 9040511 CityU 1076100E. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing 1x the official policies or endorsements, either express or implied, of the UGC Hong Kong or the City University of Hong Kong. 6 10 11 12 13 14 15 16 References PERKINS, C.E.: ‘Mobile IP: design principles and practices’ (Addison Wesley, 1998) DEERING, S.: ‘Host extensions for IP multicasting’. IETF Network Working Group Request for comment 1 1 12, 1989 JIA, W., KAISER, J., and NETT, E.: ‘ R M P Fault-tolerant group communication’, IEEE Micro, 1996, 16, (15), pp. 59-67 PARTRIDGE, C., MENDEZ, T., and MILLIKEN, W.: ‘Host anycasting service’. IETF Network Working Group, Request for comment 1546, 1993 CHIKARMANE, V., WILLIAMSON, G.L., MACKRELL, W.L., and BUNT, R.B.: ‘Multicast support for mobile hosts using mobile IP: design issues and proposed architecture’. Department of Computer Science, University of Saskatchewan, Saskatoon, 1997 BROWN, IC, and SINGH, S.: ‘RclM: Reliable multicast for mobile networks’. Technical Report, Department of Computer Science, University of South Carolina, Columbia, 1996 DEERING, S., and HINDEN, R.: ‘Internet Protocol version 6 (1Pv6) specilication’. IETF Network Working Group, Request for comment 1883, 1995 JOHNSON, D., and DEERING, S.: ‘Reserved IPv6 Sunnet anycast address’. IETF Network Working Group, Request for comment 2526, 1999 JIA. W.. XUAN. D.. and ZHAO. W.: ‘Integrated routine aleorithms for kycist messages’, IEEE Cornrhm. Mug.,”2000, 38, (lk p< 48-53 JIA, W., ZHAO, W., XUAN, D., and XU, G.: ‘An efficient fault-tolerant multicast routing protocol with core-based tree techniques’, IEEE Twns. P~inilldDi,wib. Syst., 1999, 10, (IO), pp. 984-999 BALLARDIE, A.: ‘Core based trces (CBT version 2) multicast routing’. IETF Network Working Group Rcquest for comment 2189, I997 DROMS, R.: ‘Dynamic host coiifiguration protocol’. IETF Network Working Group, Request for comment 1541, 1993 VEIZADES, J., PERKINS, C., and KAPLAN, S.: ‘Service location protocol’. IETF Network Working Group, Request for comment 2165, 1997 ACHARYA, A., and BAKER, A.: ‘Badrinath IP m~ilticastextensions for mobile internetworking’. Department of Computer Science, Rutgers University, 1996 DEERING, S.: ‘ICMP router discovery messages’. IETF Request for comment 1321, 1991 FENNER, W.: ‘Internet group management protocol, version 2’. IETF Network Working Group, Request for comment 2236, 1997 zyxwvu zyxwv IEE P,oc.-Coinniun.. Vol. 148, Nu. I . l7ebmory 2001 Authorized licensed use limited to: DEAKIN UNIVERSITY LIBRARY. Downloaded on December 21, 2008 at 18:05 from IEEE Xplore. Restrictions apply.