REHASH: Integrating Recursive Unicast with Hash - IEEE Xplore

REHASH: Integrating Recursive Unicast with Hash Algorithm to Provide Multicast Service to Receivers Borhanuddin Mohd Ali', Sahar A. Al-Talibl, Sabira Khatun', Sharmala Subramaniam2 I

Department of Computer and Communications Systems Department of Communication Technology and Networks Universiti Putra Malaysia, 43400 Serdang- Selangor, Malaysia E-mail: sahartalib(2ahotmail.com 2

packets do not carry the list of destinations. Branching nodes thus need to keep some state for each group. Zhang et. al [4] introduces the idea of recursive unicast into an existing multicast routing protocol, multicast extension to OSPF (MOSPF) to achieve scalable multicast. To ease address allocation and sender admission control, in [5] Holbrook et al. designed an Explicitly Requested SingleSource (EXPRESS) multicast scheme. Express is an alternative to the IP-multicast model that uses a per-source, channel-based model. Each channel is a service identified by a tuple (S,E) where S is the sender's source address and E is the Express destination address (i.e., a class-D address). Only S may send to (S,E) because receivers subscribed to (S,E) are not subscribed to (S',E), for some other host S'. Thus, data transmitted from two sources to the same address E is only sent to receivers subscribing to both sources. EXPRESS reduces the distribution model from M to N to I to N, simplifying the service. Some proposals tried to simplify the multicast service [6]. The analysis of these works leads us to the proposition of the REHASH multicast routing protocol. REHASH uses the unicast infrastructure to do packet forwarding with smaller routing tables, just as REUNITE and HBH do, as well as it uses EXPRESS channel model to identify a group. Thus it preserves compatibility with IP multicast. REHASH constructs Shortest-Path Tree (SPT) instead of reverse SPTs as most routing protocols do. Besides, its tree management provides enhanced tree stability in the presence of group dynamics and reduces bandwidth consumption. This paper is organized as follows: Section 2 presents REHASH multicast protocol, REHASH tree creation and maintenance are explained in section 3, section 4 gives performance analysis and finally section 5 concludes the paper.

Abstact- A new protocol called REHASH has been devised in this paper that gracefully integrates the idea of recursive unicast with hash algorithm to achieve scalable multicast for overall performance improvement. In this model, data packets have unicast destination addresses. Therefore, REHASH supports pure unicast routers transparently. The key idea of the proposed protocol is to simplify address allocation and implement multicast distribution using recursive unicast hash trees. The branching nodes recursively create packet copies to implement the distribution. REHASH adopts the source-specific channel abstraction to tackle the address allocation and the sender access control problems. Consequently, it provides best routes and is suitable for including QoS and authentication parameters inside hash tree construction algorithm. Additionally, REHASH tree management provides enhanced tree stability in the presence of group dynamics.

Key words: Recursive unicast, hash algorithm, multicast service.

1. INTRODUCTION

After more than a decade of important research and development efforts, the deployment of multicast routing in the Internet is far behind expectations. Therefore, a first motivation for an alternative group communication service is to bypass the lack of native IP multicast routing. Although less efficient and scalable than native multicast routing, such alternative services are suitable for the purpose. A second possible motivation is to go beyond the limitations of classic multicast routing for very specific working environments.

II. REHASH Multicast Protocol

The REUNITE [1] and HBH [2] proposals follow a recursive unicast approach to solve the multicast deployment issue. The idea is to have some REUNITE/HBH-capable routers that act as branching nodes and create copies with modified unicast destination address betveen two hops. It is similar to XCAST [3] except that

1-4244-0000-7/05/$20.00 ©2005 IEEE.

REHASH is a single-source model that has a simple architecture. There is no third-party, and scalability can be maintained by building routing tree by means of explicitjoin signaling to the source. as suggested by Express. With only one source, routing can always be shortest path back to

586

that source. Express is compatible with the current Internet, since its required functions have been well anticipated by IGMPv3 [7] (for 1Pv4) and MLDv2 [81 (for IPv6). Edge routers can send source-specific (S.G) joins using IGMPv3 for designated Express multicast groups. Express has already been allocated a space of experimental addresses by the Intemet Assigned Numbers Authority (IANA) for which joins from receivers are expected on a per-source basis [9]. REHASH has nearly the same function as in REUNITE and HBH. The difference is that one entry table in REHASH stores the hash addresses of the sub-trees, for which each leads to a chain of receivers that join the distribution tree and to each of which a unicast packet needs to be sent. Packets can be replicated based on the number of receivers referenced by each hash address. In this case, the protocol can serve a larger number of receivers (up to thousands). The idea is then to separate the routing information into two tables: a Multicast Control Table (MCT) stored in the control plane and a Multicast Forward Table (MFT) installed in the data plane. Non-branching routers simply keep group information in their MCT, as branching nodes keep MFT entries used to recursively create packet copies that reach all group members. As receivers join the group, REHASH populates its tables to construct the hash distribution tree. This tree is a shortest path tree that consists of sub-trees, each of which has receivers with their IP addresses hash to the same location in the hash table.

REHASH uses two message types: (i) join message, which is unicasted periodically by each receiver towards the root; and (ii) tree message, which is multicasted periodically by the root along the multicast delivery tree to refresh the softstate of the tree. Join messages are used to create and refresh the receiver entries in MFT, while tree messages are used to create and refresh the entries in MCT and to refresh the group entries in MFT. Each router RK in S's distribution tree has either a MCT or MFT. MCT has one single entry to which two timers are associated tOl and tO2. At the expiration of tOl, the MCT becomes stale and at the expiration of tO2 the MCT is destroyed. In REHASH, a receiver's address is maintained by only one node in the group's delivery tree. To multicast a packet, the root sends a copy of the packet to each hash address in its list, which leads to the related sub-trees. Similarly, when a branching node forwards such a packet, it sends a copy of the packet to each receiver in its own list. This procedure continues recursively until packets reach all leaf nodes of the tree, i.e., all receivers. The receiver ri sends join (S,ri) upstream toward the source > S and the route is: ri > R>S . S uses hash algorithm to build sub-trees from the IP addresses of r1 rooted at S (Source Specific Trees) for multicast distribution (figure 1). It is one of the characteristics that differentiate REHASH from other routing protocols. In this case, it becomes easier to deal with each sub-tree separately, besides it improves the scalability of the distribution tree.

Hash Table

Figure 1 illustrates REHASH tree construction mechanism.

LIII~ ,-\ (f

Hash fnction

5:source

node

Hash key for receivers r6,r8

Hash key for receivers

r2,r5.r1o,r15,r23,r4O,r7

[lash key for

receivers r1,r3,r4

S: source node rn:

receivers

Sub-tree 3

Root

-

* tree

-* sub-tree -* leafs

Figure 1: REHASH Tree construction mechanism

587

MFTs

S R3 S R5rl 5| S r23r7R8r5

S r2r4oRio

S forwards I copy to R3 R3 replicate 2 copies to R5, rI5 R5 replicates 4 copies to r23,r7,R8,r5 (i

S:source node

R1: routers ri: receivers MFT: Multicast

Forwarding Table

R8 replicates 3 copies to r2,r40,R1o

RIO forwards I S rio

copy to rio -

-

-

-

Figure 2: REHASH Multicast Forwarding States at Routers for sub-tree 2 Figure I illustrates how the receivers are grouped after sending their join messages to the source node. A detailed description of the grouping scheme for multicasting can be found in [101. For clarity, a simple topology is shown in figure 1. There are 12 receivers grouped after applying hash algorithm into 3 sub-trees as follows: 2 receivers (r6 and r8) in sub-tree 1, 7 receivers (r2, r5, ri0, r15, r23, r4o and r7) in sub-tree 2, and 3 receivers (r1, r3 and r4) in sub-tree 3.

maintains a much smaller per group forwarding table than other IP multicast protocols in a network with a large number of sparse groups. A Joining a group

Suppose rI5 in Figure 2 joins the group by sending a join message towards S. Upon receiving this message, R3, which is part of the multicast tree, becomes a branching node. This is accomplished by removing the MCT entry for the group and creating an MFT entry for r15. From now on, data packets and tree messages send toward rI5 by S will be replicated and sent to r]5 by R3. A receiver periodically sends join messages to refresh the MFT entry at the router it joins. These join messages are discarded at the router and will not be propagated further.

III. REHASH TREE CREATION and MAINTENANCE To describe the tree creation and maintenance operations, a detailed example has been used shown in Figure 2. S is the source and the root of a group, R3, R5, R8 and RIO are router nodes, r2, r5, ri0, rl5, r23, r40 and r7 are the receivers that constitute sub-tree 2 elements. If a router R, is traversed by a multicast group's delivery tree, the router will maintain an entry either in its MFT (in the case that the tree branches at the router) or in its MCT (in the case that the tree does not branch). Only MFT needs to be maintained on the data plane, while MCT needs to be maintained on the control plane. That is, when a data packet arrives, only MFT needs to be looked up. In contrast, MCT needs to be looked up only when control messages (join or tree) are processed. Therefore. by partitioning per group multicast state into forwarding and control state, REHASH

B. Leaving the group

To leave a group, a receiver simply stops sending join messages. Consider the case where r23 decides to leave the group in Figure 2. Since the MFT entry for r23 at R5 is no longer refreshed, after a time period of tOI seconds, R5 concludes that r23 has left. However, R5 cannot stop sending data to r23 immediately, since other receivers (r7 and r5 in this example) might receive data that are replicated from those sent to r23. Thus,

588

before S can remove the MFT entry for r23 and terminate the unicast flow, it must allow these receivers sufficient time to discover a new branch point to receive data from. To accomplish this, S maintains the MFT r23 for an additional tO2 seconds, but marks it as being not alive. During this time period, S keeps sending data and tree messages to r23. However, these tree messages are marked stale to indicate that the data flow to r23 is to be tom down after the time period tO2 is elapsed. When other R,'s (R3 and Rs in this example) receive such a tree message with the stale bit set, it removes the corresponding entry from its MCT. As a result, the next join messages from r7 or r5 reach S and new MFT entries for them are created at S. From now on, S begins sending data and tree messages to r7 and r5 and these packets pass through nodes R3 then R5. The tree messages are processed by the routers as described before. The MFT entries for r7 and r5 at S are refreshed by subsequent join messages from r7 and r5 respectively. During the time period until the stale MFT entry for r23 at S is removed, r5 and r7 will receive some duplicate data packets. After tO2 seconds, the stale state at S, R3 and R5 for r23 is removed. S therefore no longer sends any data or tree messages to r23, and rs and r7 will stop receiving duplicate data packets. Figure 2 illustrates how the packets are replicated by branching routers in REHASH based on the information that have been saved at MFT for each one.

(D

IV. PERFORMANCE ANALYSIS


-

subscribe

CD 0

0.8-E 0.6 0.40.2 -

subscribe

Number of subscribed receivers Figure 3: Results for Hash Tree of size 1K receivers

Receiver average delay U)

ws) '1)~

unsubscribe

>vt

The required modules that emulates a source specific multicast hash tree has been built that can handle up to thousands of nodes. The tree can handle the receiver's arrival and departure easily besides the required updates. Another parameters such as QoS, authentication, or routing could be added for further analysis. The average delays have been calculated for different number of nodes. Figures 3 and 4 show early results that were obtained from the simulation. Figure 3 shows that the average time for a receiver to subscribe (hash table size = 1007) is between 0.8msec and 0.9msec. While the average time to unsubscribe is always below 0.2msec. Figure 4 shows that increasing the receivers to ten folds do not affect the average subscription or departure time.

a a

11)

> 0 C>000 CD C)0 C )0 C >0a 0 00 0000C t r C ) )O CO N-

Number of subscrbed receivers Figure 4: Results for Hash Tree of size 10K receivers V. CONCLUSIONS

We have presented our proposed REHASH protocol that implements data distribution through recursive unicast hash tree. The idea of recursive unicast originally proposed in REUNITE. The efficiency of many of the proposed work (e.g., XCAST, REUNITE, HBH and REHASH), does not depend on the number and location of routers offering the service, even though partial deployment is still possible. If routers are placed at the natural branching points (usually within the backbone), efficiency can be high. If the routers are closed to end nodes the link stress is significantly higher. Furthermore, an Express-like scheme can be used in IPv6. If the first part of the IPv6 address is placed in the first part of the 120-bit multicast address, domains can claim implicit ownership of address spaces. Using IPv6 satisfies most, if not all, of the properties for a good allocation scheme, and is already supported by vendors and the IETE. Finally, it should be noted that many of the techniques discussed in this article could complement each other, as well as IP multicast. ,

589

REFERENCES [1] 1. Stoica. T. S. Eugene Ng, and H. Zhang, "REUNITE: a recursive Unicast approach to Multicast," Proc. IEEE INFOCOM2000, Mar. 2000, pp. 1644-53. [2] L. H. M. K. Costa, S. Fdida, and 0. C. M. B. Duarte," Enabling the progressive Multicast Service Deployment", Sixth IEEE Symposium on Computer & Communications, 3-5 July 2001. [3] R. Boivie et al., "Explicit Multicast (Xcast) Basic Specification," work in progress, draft-ooms-xcastbasic-spec-03.txt, June 2002. [41 B. Zhang and H. T. Mouftah," Providing Multicast through Recursive Unicast", IEEE Commz Magazine, Vol. 43 No. 1, January 2005. [5] H.W. Holbrook and D.R. Cheriton, "IP multicast channels: EXPRESS support for large-scale singlesource applications:' in Proceedingsof ACM SIGCOMM"99, Cambridge, Massachusetts, Aug. 1999. [6] C. Diot, B. N. Levine, B. Liles, H. Kassem, and D. Balensiefen. "Deployment issues for the IP multicast service and architecture"'. IEEE Network, pages 78-88, Jan. 2000. [7] Cain, B., Deering, S., Kouvelas, I. and A. Thyagarajan," Internet Group Management Protocol, Version 3.", RFC 3376, October 2002. [8] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6". RFC 2710, October 1999. Numbers Assigned Authority, [9] Internet

http://www.isi..edu/in-notes/iana/ assignments/multicast-addresses [10] S.Al-Talib, B. M. Ali, V. Prakash, and M. H. Habaebi, "A Grouping Scheme for Secure Multicasting in Mobile IPv6", IEEE, 4th NCTT2003, 14-15 January 2003, UiTM Shah Alam, Malaysia.

590