Reliable Mobile Multicast Protocol (RMMP): A Reliable Multicast Protocol
for Mobile IP Networks'
Chien-An Ke and Wanjiun Liao
Department of Electrical Engineering
National Taiwan University
Taipei, Taiwan
[email protected]
Abstract This paper proposes a new protocol, ReliableMobile Multicast Protocol (RMMP), for mobile networks using Mobile IP. Unlike existing mobile multicast solutions
that employ bi-directional tunneling for roaming terminals
to receive multicast datagrams and which is inefficient in
packet delivery, wastes system resources and results in long
service latency, RMMP ensures reliable multicast service
for mobiles by using remote subscription. Remote
subscription, however, suffers from the out-of:synch problem when data are received from the same multicast group but from different subnets while roaming from one subnet to another, thereby causing packet losses for roaming terminals. With RMMP, the mobility agent (foreign or home agent) in Mobile IP, in addition to providing mobility management, is extended to serve as the reliable multicast agent for mobiles, and routes the difference in data sequence to other agents in the adjacent subnets via tunneling. As a result, RMMP provides reliable mobile multicast services while enjoying lower delivery
cost, less service latency and better routing efficiency. Keywords: Reliable multicast, mobile multicast, Mobile IP, reliable mobile multicast protocol, RMMP
I. INTRODUCTION
IP multicasting is a key technology for many existing and emerging applications on the Internet. It avoids transmitting packets from a sender to each recipient separately, and delivers multicast datagrams unreliably i s in IP unicast. Reliable multicast enables the reliable delivery of unreliable multicast datagrams to group participants. To accommodate mobile nodes, reliable mobile multicast ensures reliable delivery of multicast services for wireless
mobile terminals even while roaming.
In recent years, some efforts have been made to achieve mobile multicasting. However, the problem of reliable mobile multicast has attracted less attention [l-21. IETF Mobile IP [3] defines two
options for routing multicast datagrams to mobile nodes, namely, remote subscription and bi-directional tunneling. Existing mobile multicast approaches are based on bi-directional tunneling to accommodate the join and leave dynamics in group participation and seamless roaming for mobiles [4-51. With bi-directional tunneled multicast, a foreign agent routes the datagrams with incorrect source addresses from visiting mobiles back to the home agents of the mobiles in the respective home networks via tunneling, thereby incurring the inefficiencies of triangular routing. With remote subscription, on the other hand, a mobile re-subscribes to the joined group on the newly visited foreign network while roaming. The remote subscription multicast, however, due to network dynamics in packet delivery, suffers from the out-of-synch problem when datagrams are received from the same multicast group but from different subnets while roaming from one subnet to another, thereby causing packet losses for roaming terminals.
'
This work is supported by the National Science Council, Taiwan, under grant number NSC 89-2219-E-002-004, and grantnumber NSC 89-E-FAOG-2.
1488
In this paper, we propose a new protocol called RMMP is designed to support reliable multicast Reliable Mobile Multicast Protocol (RMMP), based for mobile IP networks. The mobility agent, in on Mobile IP remote subscription to provide both addition to mobility management, also serves as a reliable multicast datagram delivery and efficient proxy of reliable multicast services for mobiles. On routing mechanism but avoid the out-of-synch behalf of the mobiles in its affiliated subnet, the problem. With RMMP, the mobility agent (foreign mobility agent must join the multicast group of agent or home agent), in addition to providing interest, and aggregate the feedbacks collected from mobility management, is extended to assume the the mobiles to the reliable multicast agent in use. responsibility of reliable multicast handling for From the perspective of the reliable multicast agent, mobiles, and is easily integrated with existing reliable the mobility agent is a group participant periodically multicast protocols to support mobility. As a result, acknowledging data reception, and for the mobiles, RMMP provides reliable mobile multicast services the mobility agent serves as the reliable multicast while enjoying both low service latency as in remote agent.
subscription and high routing efticiency as in Mobile
IP routing optimization. The table maintained by a mobility agent to ensure reliable multicast service consists of three The rest of the paper is organized as follows.
Section I1 presents the proposed protocol, RMMP. Finally, the paper is concluded in Section 111.
major components: a serving list, a tunneling list, and a packet delivery status list, on a per-group basis. Fig.
1 shows an example of the table maintained by a mobility agent. A serving list maintains the registered mobiles participating in the group, say G, in the affiliated network. A tunneling list records the
mobiles previously registered with this agent but are currently roaming to adjacent networks managed by other foreign agents and requesting to recover the lost datagram due to the out-of-synch problem. A packet delivery status list is created for each multicast packet received. It maintains the feedback status fiom every mobile host under the management of the
II.
PROTOCOL
DESCRIPTION
This section describes RMMP in details. In the following, we will first present the data structure of the table maintained by each mobile agent for reliable multicast service, followed by the detailed operation of the protocol.
A . Basic Mechanism
Figure I . The data structure of the table in a mobile agent
respective mobility agent. Upon receipt of a multicast packet with a sequence number of n, the agent creates an entry in the cache as shown in Fig. 2. Every host in the serving list will be added to the packet delivery status list. For example, in Fig. 2, the serving list contains three hosts, namely MH#1, MH#2, and MH#3. 0 indicates that the corresponding host has not acknowledged the reliable reception of the packet yet. If an ACK is received, ,the flag is changed to 1.
The entry is removed only when all the MH’s in the packet delivery status list have acknowledged.
retransmits the lost packet to MH-A for recovery
purpose. The Join operation is summarized in Fig. 3.
I I I I
Figure 2. A packet delivery status list
B.
Operation: An Overview%.
Multicast packets Sender3 . Create a cache f o r Group G 4 . Add MH A t o the serving list
E
Figure 3. Join operation
When a mobile host, say MH-A, roams to a
visited network, say subnetl, the mobile is first registered with the foreign agent FA], as in Mobile
IP
unicast. If the mobile would like to join a multicast
group, say group G, the mobile
issues a
join2message for group G to FAI. FA1 then sends an
IGMP-join message for the multicast group G to the immediately neighboring multicast router on behalf of the mobile if there is no other mobiles participating in group G in subnetl. Upon joining group FA1 creates a cache entry, temporarily
storing data received from group G FA1 adds MH-A to the serving list of multicast for group G MH-A periodically acknowledges packets received in subset1 to FA1 during its visit, and FA1 in turn
periodically acknowledges packets received by all the mobiles under its management to the reliable agent in use in the system. Upon detecting a lost packet, FA/
When mobile MH-A roams across service
boundary (say from subnetl to subnee), a handoff is performed so as to ensure multicast datagrams are correctly received. MH-A is registered with the new
foreign agent FA2, as in Mobile IP. In addition, the
mobile sends a join message for group G to FAt.
Again, FA2 sends an IGMP-join message for group G
to the immediately neighboring multicast router on behalf of mobile MH-A if there is no other mobiles
participating in group G in subnet2. Upon receiving a
new packet in subnet2, the mobile checks if there is any offset in data packets fiom subnet2 to subnetl. If the packets arrived in subnet2 behind those in subnetl due to network dynamics, the mobile sends a leave message with zero offset to the old agent FAI.
Otherwise, the mobile treats the offset as packet losses in subnet2 and asks FA2 to retransmit the
losses for recovery. If FA2 can recover the requested
packets from its cache, the mobile sends FAI a leave
message with zero offset; otherwise, MH-A sends
FA1 the leave message with an offset block, say [a$],
to be tunneled from FA1 to FA2, where offset block is
the difference in data sequence to be recovered between two subnets. On receipt of a leave message from a mobile host, if the leave message carries a non-zero offset block [a,b], FA1 then removes the
host from the serving list to the tunneling list; otherwise, FA1 just deletes the mobile from the
serving list. If MH-A is moved to the tunneling list
with offset block [a$], FA1 tunnels data from a to b
in the cache entry to FA2. FA2 acknowledges the
receipt of the tunneled packets to FA1 as if FA2 were
currently in subnetl. FA1 removes MH-A from the
tunneling list after the retransmission. Once both the serving list and the tunneling list are empty, FA1
which may or may not be an IGMP-Join report.
deletes the cache entry of group G and issues an IGMP-leave message to the multicast router to leave the group.
) 1 1 2 1 3 ) 5 )
. Tunneling lost packets 1 4 , 6 ,
. ACK on receipt of pkt r 4 . 6 . 7
- - -
PA2
F A 1 4
Figure 4. An example in handoff
For example, in Fig. 4, upon moving from subnetl to subnet2 and detecting the un-repaired data packets in subnet2, i.e., MH-A has packets of [l, 2,3, 51 and FA2 caches only packets of [9,10,11,12],
MH-A sends a leave message with a non-zero offset
block of [4,6,7,8] to FAI to request retransmissions. FAI then moves MH-A from the serving list to the tunneling list, and encapsulates the requested packets to FA2 via tunneling.
Note that while we have merely described roaming across two subnets, the protocol is able to handle subsequent handoffs across multiple subnets during a reliable multicast session.
m.
CONCLUSION
In this paper, we have described the proposed protocol, RMMP, for reliable multicast in Mobile IP networks. Based on remote-subscription, RMMP is superior to bi-directional tunneled multicast protocols for mobiles in terms of lower delivery cost, less service latency, and better routing efficiency.
We have also conducted simulations to
compare RMMP with existing reliable mobile multicast protocols. For example, Fig. 5 demonstrates that RMMP is superior to the ring approach proposed in [2] in terms of buffer requirement in each mobility agent. Due to space limitation, we did not include any other results in the paper. We will report the performance comparison of RMMP with other reliable multicast protocols for mobile networks in the future.
0.W 0.05 0.10 0.15 0.20 0.25 Emr Rae(%)
Figure 5. Performance comparison
REFERENCES
K. Brown and S . Singh, “RelM: Reliable multicast for mobile networks,” Technical Report, Department of Computer Science, University of South Carolina, Sept. 1995.
I. Kilolaidis and J. J. Harms, “A Logical Ring
Reliable Multicast Protocol for Mobile Nodes,” Proc. IEEE ICNP ’99, pp. 106-1 13.
C. Perkins, “IP Mobility Support,” RFC 2002, Mobile IP Working Group, Oct. 1996.
T. G Harrison et al. “ Mobile Multicast (MOM)
Protocol: Multicast Support for Mobile Hosts,” Proc. ACM MobiCom ‘97, Budapest, Hungary, pp.
151-160, Sep. 1997.
[SI C. L. Williamson et al. “Performance Evaluation of the MOM Mobile Multicast Protocol,” ACMBaltzer Mobile Networks and Applications, v.3 no.2, pp. 189
