A Scalable Approach for Core Failure Recovery in Multicasting

A Scalable Approach for Core Failure Recovery in Multicasting G.Manimaran, Anirban Chakrabarti

Abstract

The issue of providing reliable group communication services has been gaining importance due to the proliferation of QoS-aware group applications over the Internet. There are two types of multicasting approaches to support group communication: core-based tree (shared tree) and source-based tree. Core-based tree is becoming popular for many-tomany multicasting due to its scalability property. In this paper, we propose a scalable approach for recovering from core failure, which comprises of three stages: (i) core selection and multicast tree construction, (ii) local failure recovery, and (iii) global failure recovery. As part of global failure recovery, we highlight the importance of core/tree migration.

1 Introduction

The proliferation of Quality of Service (QoS) aware group applications associated with recent advancements in high-speed networks is driving the need for ecient multicast communication services satisfying the QoS requirements of such applications [1, 2, 3]. Multicasting has been a popular mechanism for supporting group communication. In a multicast session, the sender transmits only one copy of each each message that is replicated within the network and delivered to multiple recipients (receivers). For this reason, multicasting typically requires less total bandwidth than separately unicasting message to each receiver. The dierence between multicasting and separate unicasting is best captured by the host group model [4]: \a host group is a set of network entities sharing a common identifying multicast address, all receiving any data packets addressed to this multicast address by senders (sources) that may or may not be members of the same group and have no knowledge of the groups' membership". This de nition implies that, from the sender's point of view, this model reduces the multicast service interface to a unicast one. The de nition also allows the behavior of the group to be unrestricted in multiple dimensions: groups may have local (LAN) or global (WAN) membership, be transient or persistent in time, and have constant or varying membership. Consequently, we have the following types of mul-

New center Tree Rearrangement

Group Creation

Group identifier

Resource Multicast Multicast tree ReserRouting vation

Core Migration

Core Tree quality quality degrades degrades Rearranged tree Session Data Trans established -mission

Reconfigure

Dept. of Electrical and Computer Engg. Iowa State University Ames, IA 50011, USA [email protected], [email protected] Failure Handling

Node/link failure Session life-time expires

Multiple senders Arbitrate join/leave Tx Regulate/ problem Session adapt Control Traffic Control

Session Teardown

graft/prune

COLM Routing Multicast call request

Figure 1: Life-cycle of a QoS multicast session - an event diagram view ticast (or host) groups: (i) dense groups which have members on most of the links or subnets in the network, whereas sparse groups have members only on a small number of widely separated links, (ii) open groups are those in which the sender need not be a member of the group, whereas closed groups allow only members to send to the group, (iii) permanent groups are those groups which exist forever or for a longer duration compared to the duration of transient groups, and (iv) static groups are those groups whose membership remains constant in time, whereas dynamic groups allow members to join/leave the group. A network architecture that aims to provide complete support for multicast communication is burdened with the task of managing the multicast sessions in a manner transparent to the users. This goal of transparent multicast service imposes speci c requirements on the network implementation. To understand the dierent functionalities that such a network must provide, we show in Figure 1 the various steps and events that take place in the \life-cycle" of a typical multicast session. The sequence of phases/steps are: (i) multicast group (session) creation, (ii) multicast tree construction with resource reservation, (iii) data transmission, and (iv) multicast session tear-down. A multicast routing protocol deals with constructing a multicast tree spanning group members taking into account both network and membership dynamics. Four dierent kinds of run-time events that can occur during the transmission phase of a multicast session (refer Figure 1): (i) membership changes,

(ii) node and/or link failures, (iii) transmission problem, (iv) competition among senders  Membership Changes: Since group membership can be dynamic, the network must be able to track current membership during a session's lifetime. Tracking is needed both to start forwarding data to new group members and for stopping the wasteful transmission of packets to members that have left the group (identi ed as COLM (constrained online multicast) routing in Figure 1).  Node and/or Link Failures: During the lifetime of a multicast session, if any node or link supporting the multicast session fails, the service will be disrupted. This requires mechanisms to detect node and link failures and to recon gure (restore) the multicast tree around the faulty components with minimal service disruption (identi ed as Failure Handling in Figure 1).  Transmission Problems: This could include events such as swamped receivers (needing

ow control), overloaded intermediate nodes (needing congestion control), or faulty packet transmissions (needing error control). The trac control mechanism, working in conjunction with the schedulers at the receivers and the intermediate nodes, is responsible for performing the necessary control activities to overcome these transmission problems. (identi ed as Trac Control in Figure 1).  Competition among Senders: In a manyto-many multicasting, when multiple senders share the same multicast tree (resources) for data transmission, resource contention occurs among the senders. This will result in data loss due to buer over ow, thus triggering transmission problems. This requires a session control mechanism that arbitrates transmission among the senders. (identi ed as Session Control in Figure 1). In Figure 1, Tree Rearrangement and Core Migration can be invoked when the quality of the tree degrades due to membership dynamics or when node/link failure occurs.

1.1 Multicasting Approaches

Multicast routing algorithms can be classi ed into two main approaches: source-based tree and center-based tree. Source-based Tree Approach: The sourcebased tree approach uses a shortest path tree rooted at the sender/source. The branches of the tree are the shortest paths from the sender to each group members. The shortest paths are usually

shortest delay paths. When this approach is employed for many-to-many multicasting, a separate tree must be constructed for each sender. Sourcebased routing is currently employed in DistanceVector Multicast Routing Protocol (DVMRP) [5] (which is based on Reverse Path Forwarding (RPF) [6]) over MBone [7], dense-mode Protocol Independent Multicasting (PIM-dense) [8], and Multicast Open Shortest Path First (MOSPF). Core-based Tree Approach: The other type of protocols, called center-based tree, constructs a multicast tree spanning the members whose root is the center or core node. These protocols are highly suitable for sparse groups and scalable for large networks such as the Internet. Core Based Tree [9] is a well known example of this type. When a node wishes to transmit a message to the multicast group, it sends the message towards the core. The message is distributed to the group members along the path to the core and once the message reaches the core, it is distributed to the remaining group members. Requests to join or leave the group are processed by sending the request towards the core. When a join request (from a new node) reaches a tree node, the tree node becomes the point of attachment for the new node. When a node leaves the group, a part of the tree, between the node and the nearest tree node whose degree is greater than two, is pruned. Recently, some hybrid routing protocols like sparse-mode PIM (PIM-sparse) [8] and the Multicast Internet Protocol (MIP) [10] have been proposed. These allow a receiver to switch from the shared tree to shortest path tree.

1.2 Failure Handling

The problem of handling network dynamics in the context of multimedia applications is an important issue due to the importance of the data involved and optimality considerations. This motivates the need for mechanisms that handle network dynamics due to addition of new nodes or failure of node and/or link. For an on-going multicast session, it may be possible to obtain a better multicast tree with the addition of a new node. The most important aspect of network dynamics is failure handling because failure introduces service disruption. For unicasting, one type of failure handling approach is the protection based approach [11, 12, 13] wherein dedicated protection mechanisms, such as redundant (backup) channels operating in hot standby, are employed to cope with failures. The primary and backup channels are usually node disjoint. This approach is more suitable for hard real-time communication wherein every packet is critical. The other type is the restoration based approach [14] wherein a dedicated mechanism is used to detect node and link failures. On detection of a failure, an attempt is made to reroute (re-

store) the channel around the faulty nodes/links with minimal service disruption. This approach is useful if occasional packet losses are tolerable (such as in multimedia applications) and restoration is initiated only when a permanent failure is detected. With multimedia multicasting, the problem is much more complicated than with unicasting, as resource reservations are shared and group dynamics interact with network recon gurations. Very little is known as to how to deal with such problems [15]. The use of the protection based approach for multicasting is prohibitively expensive in terms of resource usage as it requires one or more backup trees for each primary tree, and hence not scalable. Moreover, for dynamic groups, this approach does not suit well as the structure of the tree itself changes with time. Therefore, it is more appropriate to use restoration based approach. In core-based multicasting, the main problem is that it has a single point of failure at the core. If the core fails, then the whole multicast session would be disrupted. To provide reliable multicast services, the multicast routing protocols need to be equipped with mechanisms for handling core failures as well as node/link failures. These mechanisms need to take into account several design considerations, such as scalability, fast recovery, and less protocol overhead, in order for them to be widely deployable over the Internet. As of today, very little work (e.g., [16, 17, 18] for link/node failure in core-based trees) has been done on failure recovery in multicast communication and hence this topic needs further research [3]. In [16, 17], protocols have been proposed to recover from link/node failure. Whereas, in [18], protection based mechanisms (i.e., employing backup paths) have been proposed for tolerating link/node failure. To the best of our knowledge, there has been no prior work which deals with core failure. The mechanisms proposed for link/node failure recovery cannot be directly extended to core failure recovery as core is special node in a multicast tree.

2 Proposed Core Failure Recovery Mechanism

The objective of this paper is to propose a scalable mechanism for core failure recovery in multicast trees. In order to provide more insight into the problem, we rst identify the issues in core based trees and then present the various stages of our approach.

2.1 Issues in Core-based Trees

The main issues associated with Core Based Trees are as follows:

 Core Selection: In core-based trees, since the trees are rooted at the core node, core selection is an important issue because location

Core Failure Recovery

Core Selection & Tree Construction

Main & Candidate Cores Selection

Local Recovery

Multicast Tree Construction

Global Recovery

Core Evaluation & Tree Constrn.

Core/Tree Migration

Figure 2: Schematic of the proposed core failure recovery approach of the core in uences the tree structure (and cost) which in turn determines the delay experienced by individual receivers.  Core Failure: In core-based trees, core is a single point of failure. If the core fails, there is a large amount of service disruption as many of the receivers cannot receive the data sent by the senders. Therefore, core failure recovery is an important issue.  Core Degeneration: If the group is highly dynamic, then the core `degenerates' with time [19]. This means that in a core-based tree approach, the performance of the core will deteriorate with time for dynamic groups. Performance is measured in terms of the total bandwidth consumed by the multicast session (i.e., cost of the tree) and the delay experienced by individual receivers in receiving the packets sent by the senders.  Tree Migration: When the core of a multicast tree deteriorates, core migration is invoked to move the tree from the current core/tree to a new core/tree which can oer better performance. During core/tree migration, the receivers may experience packet loss and the multicast session may consume more bandwidth than required. These two quantities are to be minimized.

Outline of our Approach: The proposed approach has three parts (shown in Figure 2): (i) Core Selection and Tree Construction, (ii) Local Failure Recovery (LFR), and (iii) Global Failure Recovery (GFR), of which the rst one is invoked as part of multicast tree construction and the latter two are invoked in response to core failure. LFR is a short-term recovery mechanism, whereas GFR is a long-term recovery mechanism.

2.2 Core Selection and Tree Construction

Core selection is the rst step in Core Based multicasting. The optimal core selection is an NPcomplete problem and usually requires complete network topology and exact group membership details. A number of heuristics have been proposed in [20, 21] for core selection and are evaluated in [22]. In all the core selection algorithms, a certain number of nodes called the potential cores express their willingness [21] to become the core of the tree. Each of them evaluate certain weight, which is generally a function of delay or bandwidth or both and `bid' to become the `core' node. The node having the best weight, is chosen as the core node. In this paper, we propose a mechanism for fault recovery when the core fails. In our algorithm, we prune the list of potential cores according to link constraint and then prune the list further according to path constraint. The nal pruned list is called candidate cores. The main and the candidate cores are selected as follows:

 The rst step is to select a set1of potential

cores, based on some heuristics , such that these potential cores satisfy link constraint. The link constraint, for a given potential core, states that there must be an alternate path between any two neighbor nodes bypassing itself. The rationale behind the link constraint is that, there must be a path bypassing the core. This ensures that if the core fails, there is always an alternate route for the Local Failure Recovery mechanism to carry on. In the Figure 3, the node referred to as the core satis es the link constraint as there is a path bypassing it indicated by the dotted lines. So, in case of core failure, R0 can bypass the core and send packets along the backup path to R3.

 Among the potential cores, the one that can

construct a tree with the minimum weight function is chosen as the main core. As explored in [21], weight functions are generally functions of bandwidth and delay. A very common weight function used is delay-bandwidth product. In [21, 20] several weight functions have been discussed. Our algorithm is independent of the weight function used to evaluate the core, as long as the potential core satis es link constraint and path constraint.

 Each of the potential cores (other than the

main core) must also satisfy path constraint which states that: for a given potential core, there must be a path bypassing the main core

1 In this paper, we do not address the problem of developing such heuristics.

in the multicast tree rooted at it. The potential cores that pass both link and path constraints are called candidate cores. The rationale behind the path constraint is that, the tree created by the candidate cores, when the main core fails must not be aected by the main core. So, in case of core failure one of the candidate cores will take over the responsibility of the main core without being aected by the failure of the current core. Thus, our core selection algorithm not only incorporates the traditional QoS issues but supplements them with the fault tolerance features. Then, a multicast tree is constructed rooted at the (main) core using a known multicast routing algorithm (references in [1, 2, 3]).

2.3 Local Failure Recovery

When the multicast tree is constructed, four special nodes are identi ed (shown in Figure 3): (i) `upstream neighbor' - the neighbor node in the upstream path to the core, (ii) `upstream LFR neighbor' - the node at which the path bypassing the core (backup path) hits the main tree, (iii) `downstream neighbor' - similar to (i) in the downstream path, and (iv) `downstream LFR neighbor' - similar to (ii) in the downstream path. As shown in the gure, there can be multiple `downstream neighbor' and `downstream LFR neighbor' but only one `upstream neighbor' and 'upstream LFR neighbor'. In the Figure 3, the solid lines indicate the links which are part of the existing tree. The dotted lines indicate the backup path, which would be used when the core fails. During multicast tree construction, the backup paths are identi ed without reserving resources along them. Once a failure is detected, the corresponding backup path is activated by reserving resources along the path. The intuition behind identifying these special nodes lies in the fact that we are aiming at a scalable core failure recovery mechanism. Core is a special node in a multicast session with several specialized responsibilities. When the core fails, these responsibilities need to be locally transferred without causing too much disruption in service. For this reason, the upstream and downstream neighbors are useful. In the Figure 3, R0 ? R3 shown is dotted lines is the least path bypassing the core. Since, R0 and R3 are the end points of the sub-path created by the dotted lines, they need to know when the core fails. For this reason, the neighbors send periodic `keep alive' message to nd out whether the core is alive or not. Also, the LFR upstream and downstream neighbors are periodically noti ed whether the core is alive or not. When these neighbors learn that the core has failed, one of them takes over as the core and invoke the local recovery mechanism to create the backup path bypassing

R0

R1 core R4

R5

R0: upstream LFR neighbor R1: upstream neighbor R3, R5, R6: downstream LFR neighbors R3, R4: downstream neighbors

R3

R6

R7

R8

multicast tree LFR path

Figure 3: Illustration of special nodes for Local Failure Recovery (LFR) the failed core. In the Figure 3, when the core fails R1 informs R0 that the core has failed while R4 informs R5 and R6 about the same. Since R3 acts both as `downstream neighbor' and 'downstream LFR neighbor', it gets to know about the core failure immediately. After the `LFR neighbors' have been noti ed, the backup paths indicated by dotted lines are reserved. After the Local Failure Recovery mechanism, the weight of the resultant tree is evaluated. If the resultant weight drops below a certain threshold (which is generally decided beforehand), the Global Recovery mechanism is triggered. The global recovery mechanism can also be invoked when there is no core failure and the quality of the current tree has deteriorated beyond a threshold due to dynamic join and leave of group members. In the gure 3, nodes R0 and R3 constantly send `keep alive' messages to keep track of whether the core is alive or not. When the core fails, R0 creates the backup path and takes over as the core of the tree. But, the new path contains many more hops than the original path. As a result, the weight of the tree may increase above the cut-o value triggering Global Failure Recovery mechanism.

2.4 Global Failure Recovery

In the Local Failure Recovery mechanism, when the core fails the neighbors are responsible for local rerouting as discussed above. But local rerouting may result in performance deterioration, as the overall cost of the tree may increase. Referring to the gure 3, we see that the R0 ? R3 path increased the hoplength by 1, after local rerouting. Most multicast sessions evaluate the quality of the tree either in time-driven or event-driven fashion. Because of the local rerouting if the quality of the tree falls below a certain cut-o, another node from the list of candidate cores should take over as the main core. We call this Global Failure Recovery mechanism. Though, it should be kept in mind that the Core/Tree migration may be triggered because of other factors like new members joining/leaving the group. The global recovery mechanism deals with the following: (i) the selection/evaluation of a new

core online from the set of candidate cores, (ii) constructing a new multicast tree online (rooted at the new core), and (iii) and migrating members from the current tree to the new tree. While the core evaluation involves selecting a best core from the set of candidate cores available and the tree construction is similar to the initial tree construction, the core/tree migration is an unique issue which is discussed below.

2.4.1 Core/Tree Migration

Once a new core has been selected, the old tree needs to be migrated to the new tree. This process is called `Tree Migration'. Tree migration basically involves moving members from one tree to the other. When members are moved from one tree to another receivers would not be getting continuous service resulting in service disruption. This can be minimized by providing additional resources. Thus a trade-o exists between service disruption and resource wastage. We de ne both the term in the following way:

 Service Disruption (SD) is de ned as the

amount of time a receiver will not be able to receive the multicast data during the core migration process.  Resource Wastage (RW) is de ned as the amount of excess resource (bandwidth) that remain idle multiplied by the duration for which it is idle. RW

X

R?1 = R1 (tjoini ? tleavei ); 0

i=0

where R is the number of receivers, tjoini is the time at which receiver i joins the new tree, and tleavei is the time at which receiver i leaves the old tree. 0

Tree migration can be achieved in several ways. New tree may be constructed before deleting the old tree resulting in no service disruption but very high resource wastage. The other extreme is to delete the old tree and then construct the new tree, resulting in very low resource wastage but very high service disruption. Some hybrid schemes can also be carried out.

3 Conclusions

In this paper, we have presented an approach for scalable core failure recovery in multicast trees. The proposed approach constitutes core selection and tree construction, local failure recovery, and global failure recovery. As part of the global failure recovery, we have highlighted the importance of

core (tree) migration. Currently, we are developing algorithms for core selection and local failure recovery and carrying out simulation studies to evaluate the eectiveness of the algorithms.

References

[1] C. Diot, W. Dabbous, and J. Crowcroft, \Multipoint communications: A survey of protocols, functions and mechanisms," IEEE J. Select. Areas Communications, vol.15, no.3, pp.277-290, Apr. 1997.

[2] J. Hou and B. Wang, \Multicast routing and its QoS extension: Problems, algorithms and Protocols," IEEE Networks, Jan./Feb. 2000. [3] L. Sahasrabuddhe and B. Mukherjee, \Multicast routing algorithms and protocols: A tutorial," IEEE Network, Jan./Feb. 2000. [4] D.R. Cheriton and S. Deering, \Host groups: A multicast extension for datagram internetworks," in Proc. Data Communications Symposium, pp.172-179, 1985. [5] S. Deering, C. Partridge, and D. Waitzmann, \Distance vector multicast routing protocol," RFC 1075, Nov. 1988. [6] Y.K. Dalal and R.M. Metcalfe, \Reverse path forwarding of broadcast packets," Communications of the ACM, vol.21, no.12, pp.10401048, Dec. 1978. [7] H. Eriksson, \MBone: The multicast backbone," Communications of the ACM, vol.37, no.8, pp.54-60, Aug. 1994. [8] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, C. Liu, and L. Wei, \The PIM architecture for wide-area multicast routing," IEEE/ACM Trans. Networking, vol.4, no.2, pp.153-162, Apr. 1996. [9] T. Ballardie, P. Francis, and J. Crowcroft, \Core-based trees (CBT): An architecture for scalable inter-domain multicast routing," in Proc. ACM SIGCOMM, pp.85-95, 1993. [10] M. Parsa and J.J. Garcia-Luna-Aceves, \A protocol for scalable loop-free multicasting, IEEE J. Select. Areas Communications, vol.15, no.3, April 1997. [11] A. Banerjea, \Simulation study of the capacity eects of dispersity routing for faulttolerant real-time channels," in Proc. ACM SIGCOMM, pp.194-205, 1996.

[12] S. Han and K.G. Shin, \A primary-backup channel approach to dependable real-time communication in multihop networks," IEEE Trans. Computers, vol.47, no.1, pp.46-61, Jan. 1998. [13] R. Sriram, G. Manimaran, and C. Siva Ram Murthy, \An integrated scheme for establishing dependable real-time channels in multihop networks," in Proc. ICCCN, pp.528-533, 1999. [14] J. Anderson, B. Doshi, S. Dravida, and P. Harshavadhana, \Fast restoration of ATM networks," IEEE J. Select. Areas Communications, vol.12, no.1, pp.128-138, Jan. 1994. [15] J.C. Pasquale, G.C. Polyzos, and G. Xylomenos, \The multimedia multicasting problem," Multimedia Systems, vol.6, no.1, pp.4359, 1998. [16] C. Shields and J.J. Garcia \Ordered Core Based Tree Protocol' in Proc. IEEE INFOCOM, 1997. [17] L. Schwiebert and R. Chintalapati, \Improved fault recovery for core based trees," Computer Communications, vol.23, no.9, Apr. 2000. [18] W. Jia, W. Jhao, D. Xuan, and G. Xu, \An Ecient Fault-Tolerant Multicast Routing Protocol with Core-Based Tree Techniques," IEEE Trans. Parallel and Distributed Systems, pp 984-999, Oct. 1999. [19] C. Donahoo and Zegura, \Core migration for dynamic multicast routing," in Proc. ICCCN, 1995. [20] C. Donahoo and E. Zegura, \Core selection methods for multicast routing," in Proc. ICCCN, 1995. [21] D.G. Thaler and C.V. Ravishankar, \Distributed center location algorithms," IEEE J. Select. Areas Communications, vol.15, no.3, pp.291-303, Apr. 1997. [22] E. Fleury, Y. Huang, and P.K. McKinley, \On the performance and feasibility of multicast core selection heuristics," in Proc. ICCN, pp.296-303, 1998.