PAPER Efficient Support for Multicast Applications over VP-Based ATM Networks

Transcription

1 IEICE TRANS. COMMUN., VOL.E83 B, NO.12 DECEMBER PAPER Efficient Support for Multicast Applications over VP-Based ATM Networks Gang FENG and David Siew Chee KHEONG, Nonmembers SUMMARY In this paper, we present a new network design problem that is applicable for designing virtual paths (VP s) in an asynchronous transfer mode (ATM) network to efficiently support multicast applications, especiallyreal-time multimedia applications. We first address several alternatives for the solution and compare their properties. Then we focus on a new solution which sets up a semi-permanent VP layout (VPL) and constructs VC trees for different multicast traffic demand patterns based on the constructed VPL. A three-phase heuristic solution is proposed for designing a good virtual-path layout for a given set of multicast traffic demand patterns. Byvarying the design parameters, we can obtain different VPLs which possess different tradeoffs among some important criteria, namely, the network overhead for a connection setup, routing table resources and control and management cost. Simulations are performed on randomly generated networks to demonstrate the performance and scalabilityof our solution. To the best of our knowledge, there is no prior known work which takes the multicast connection traffic into account for the VP layout design. key words: ÑÙÐØ Ø Ú ÖØÙ Ð Ô Ø Ð ÝÓÙØ ÝÒ ÖÓÒÓÙ ØÖ Ò ¹ Ö ÑÓ 1. Introduction 1.1 Asynchronous Transfer Mode and VP Layout The asynchronous transfer mode (ATM) is expected to be the key technology for the cost-effective implementation of the broadband integrated services digital network (B-ISDN) with the goal of supporting new attractive multimedia applications. ATM provides two types of connection-oriented services: virtual paths (VPs) and virtual circuits (VCs). While a VC is the entity on which data is transferred, a VP is a logical connection established on a sequence of physical links between a pair of nodes. Specifically, the VP concept was motivated by the desire to accomplish the following: (1) reduce setup and switching costs of VCs, which are established on demand by using existing VPs, and (2) reduce network control cost by bundling many connections into single units (VPs). Utilization the advantages provided by the virtual path concept is fundamental to the support of a large number of connection calls, many of which may require stringent Quality of Service (QoS) guarantees. VPs are usually categorized Manuscript received November 26, Manuscript revised June 19, The authors are with Information Communication Institute of Singapore, Nanyang Technological University, Singapore. as permanent VPs, semi-permanent VPs and dynamic VPs. We concentrate on semi-permanent VPs in this paper as they are usually responsible for supporting the bulk of the network traffic. The VC and VP concepts have received much attention in the communication literature, yet the problem of how VP s should be laid out in a given network topology was addressed only in a few works (e.g. [4] [6], [10], [19]). In these works, however, only the pointto-point connection traffic was taken into account. In this paper, we focus on the design of VP layout to efficiently support multicast traffic that is fundamental for many multimedia services in ATM networks. 1.2 Multicast Paradigm ATM is rapidly becoming the dominant transport technology for broadband services, especially for real-time multimedia applications, such as multiparty videoconferencing [9], [15], distance leaning and video distribution. For these applications, video and audio signals usually need to be distributed from one sit to other several sites. It is clear that the multicast capability is essential in these scenarios. In other words, efficient multicast capability is necessarily provided by the network for supporting these applications. Compared to the traditional point-to-point audio or data services, the real-time multimedia applications pose more stringent requirements to the network: (1) Video traffic usually consumes a huge bandwidth resource. As a result, the bandwidth efficiency for supporting the multicast media connections should be as high as possible; (2) The setup time delay for the multicast connections should be small enough, especially for some realtime or interactive multimedia applications. For instance, let us consider a kind of multimedia conferencing called speaker-video conferencing [9]. When there is a change of speaker in the conference session, a new multicast connection for transmitting the video and audio needs to be set up. In this scenario, the set up of the new multicast connection should be done in a very short time to guarantee the conference continuity. (3) For multipoint communications, the control and management are relatively much complicated.

2 2662 IEICE TRANS. COMMUN., VOL.E83 B, NO.12 DECEMBER 2000 Therefore, the cost for controlling and managing the connections should be small. In an ATM network, the service connections are usually set up by constructing VC connections through VPs [4], [6], [10]. Our solution will also be based on the VP layout (VPL). The design of VP layout of an ATM network is closely related to the degree how the abovementioned requirements can be satisfied. A good VP layout design can efficiently support those multicast applications with QoS guaranteed and with high network resource utilization at a low management cost. Therefore, the VP layout should be deliberately designed for accommodating multicast traffic. 1.3 Related Work on VP Layout Design Most of the existing work on ATM networks considers the pure VP approach for VPL in which each node is connected to every other node through a direct VP [10] [13]. However, this approach may not be feasible for large networks. In Ref. [4], the problem of designing a VPL such that a VC is routed through multiple VPs has been addressed. The VPL design problem, addressed in [13], is formulated as an optimization problem in which the objective is to minimize the control and transmission cost. An iterative algorithm based on heuristics is proposed to obtain a near optimal solution. The idea there is to search for an optimal solution in the solution space, i.e. in the set of all possible VPLs of the given network. However, the number of possible VPLs even for a small network is very large, thus ruling out the possibility of an exhaustive search. Hence, a heuristic search method is proposed for searching in the solution space. Beginning with an initial feasible solution, the algorithm iteratively improves the current solution so as to reach a near optimal solution. The VPL problem in [7] is addressed in two steps. In the first step a restricted case of the VPL, where a particular node is to be connected to all other nodes in the network, is considered. An algorithm for finding a VPL for this restricted case by decomposing the network and operating on the network recursively is given. Using this solution as a building block, a solution for the VPL design problem for the general case is then developed. The expression of the equation for an important design parameter, threshold, is obtained for a worst case scenario, which rarely occurs in real networks. Hence, the obtained VPL was not optimal in most of the cases. Another problem with this method is that, it does not take into account, the traffic requirement between node pairs. In [4], the VPL design problem is formulated as an optimization problem where the objective is to minimize the switching cost and the call setup time, subject to the constraint of the size of the routing tables at switches. This algorithm works as follows. Initially a set of paths between all node pairs in the network is found and assigned as VPs. If at any switch, the size of the routing table exceeds a threshold, then two minimum cost VPs that are passing through this switch (called a violating switch) are combined. The VP combining operation in [4] is done without considering the global layout of the VPs thus resulting in suboptimal solutions. In this paper, we propose a VPL design algorithm whose algorithmic complexity is better than that of the algorithm proposed in [4] which also aims at minimizing the switching and transmission cost and control and management cost. All the above works [4], [7], [13] deal with the VP layout design for only point-to-point traffic. The only work related to VP network layout problem considering multicast traffic can be found in [8]. However, that work is mainly focused on the routing in VP network, where VP tree is used. That is, it is assumed that a set of unidirectional VP s are defined from each node to all other nodes. This assumption is not realistic as the total VPI number needed is too large to accommodate even for a moderate size network. Recently, O. Gerstel, et al. presented in [19] a method for designing virtual paths in an ATM network to efficiently support client/server applications. A greedy solution was proposed to optimize the network overhead for a request/response and the utilization of bandwidth. In addition, they studied a new efficient bandwidth allocation scheme which is tailored for client/server applications over ATM networks. 1.4 Contribution of This Paper In this paper, we discuss methods for efficiently supporting multicast applications, especially real-time multimedia applications over an ATM network by setting up semi-permanent VP s. Our algorithm aims at minimizing the transmission, switching, control and management cost by properly designing the VP network. Unlike the existing works on VP layout design which assume only point-to-point connections, we take into account multicast connections as well as point-topoint connections which can be viewed as a special case of multicast connections. We discuss several alternatives for the solution, compare their properties, and focus on a new solution which can tune to the tradeoff among the network overhead for a connection setup, the utilization of bandwidth and routing table resources and control and management cost. A three-phase heuristic solution for designing a good virtual-path layout for a given set of multicast traffic demand patterns is proposed. To the best of our knowledge, our work in this paper is the first algorithm for designing VP layout considering the multicast traffic. The remainder of the paper is structured as follows.

3 FENG and KHEONG: EFFICIENT SUPPORT FOR MULTICAST APPLICATIONS 2663 In Sect. 2, we explore the spectrum of possible solutions to the problem and overview the desirable properties of a good VPL. In Sect. 3, the design problem which stems from efficiently supporting multicast traffic over ATM networks is formulated. A mathematical model is defined. We present our solution to the problem in Sect. 4 and in Sect. 5 we focus on the main problem solved in the paper (namely, the VP layout for multicast applications) and present heuristic for it. The simulation results demonstrating the performance and the scalability of our solution are presented in Sect. 6 and finally we summarize the results in Sect Feasible Solutions 2.1 Feasible Solutions To support multicast services in an ATM network, several straightforward solutions can be used. However, each of these schemes has its drawbacks in terms of the scalability, bandwidth efficiency, setup delay or cost of control and management. These methods are: (1) Multiple point-to-point VC scheme This scheme makes use of the existing point-to-point communication and control protocols to set up a pointto-point connection from the source to each destination. It is simple but is also bandwidth wasteful as it usually requires identical cells to flow through the same physical links. (2) Pure VC tree scheme This method creates a permanent VC tree for each possible multicast connection. Whenever a multicast request arrives, a connection can be established with no setup overhead. The main drawback of this solution is that these VC s must be maintained (e.g., when a physical link fails), a network-management overhead that is not justifiable if they are not frequently utilized. Another major drawback in the case of CBR and VBR traffic is its inefficient bandwidth allocation each such VC requires allocated bandwidth that cannot be reused by any other sessions. This is especially problematic when the multicast size is very large. (3) VP tree scheme This scheme creates only VP s that span a single physical link. Then a multicast connection can be established by making use of these VPs. This solution is optimal in its degree of reuse, since a VP may be shared by all connections for which the chosen physical route includes the appropriate link. However, this solution results in very long setup times and is thus impractical when the physical network is sparse and VC s traverse a large number of links. It might be a viable solution for dense networks. (4) Multiple point-to-point VP scheme In this scheme, multiple VPs from the source to all the destinations are created. A multicast connection can be set up via setting up VCs through these VPs. The setup delay is very small. Similar to scheme (1), however, this scheme is very wasteful in bandwidth resources. (5) Point-to-multipoint VP scheme This scheme creates a permanent point-to-multipoint VP for each possible multicast connection request. This solution has the advantage over pure VC tree scheme that the individual VC multicast connections are only created upon request; hence, if many multicast group members are connected to the same switching node, they are supported by the same VP. In this case a VC setup is necessary for every connection request, but this VC involves only a single point-to-multipoint VP, thus its setup is very efficient. A main disadvantage of this solution is that the allocated bandwidth to each such direct VP may be reused only by multicast group members that are connected to the same switching node. In this scheme, a point-to-multipoint VP needs to be set up for each combination of multicast nodes which is a huge number even for a moderate size network [9]. As discussed earlier, large VP number also reduces the efficiency of VP-based fault recovery. We use an example to illustrate the above schemes. Consider a multicast connection with 1 source and 4 destination switching nodes. Figures 1(a) (e) demonstrates the five above-mentioned solutions on the same network. 2.2 Our Solution for the Example To clearly show our idea to the solution, let us assume there is another multicast traffic pattern in addition to the existing one in the example of Fig. 1. The locations of the multicast source and destinations and our solutions of the VP layout are shown in Fig. 2. To overcome the shortcomings of the above scheme 2 and scheme 3 solutions, our solution devised is essentially an intermediate solution between the above extremes. Of course the solution can be tuned to become either of these two extremes, but also any intermediate alternative, thereby displaying a tradeoff between the setup time and the amount of necessary resources at every network element (i.e., link, switch). Actually as shown in the next section, our solution may be tuned to produce many different VP layouts, and the solutions depicted in the figure are only two options. Our solution is a kind of VP augmented VC multicasting scheme. This is a VC multicasting method augmented by point-to-point VPs, as shown in Fig. 2 (in the figure we have not depicted the VCs for the sake of simplicity). The crux is how to design the VPs to optimize the global VP layout performance (the total VP number, the number of VPs on a link) while satisfying the requirements by individual connections (e.g., connection setup delay, management cost). In Fig. 2, some VPs are shared by two multicast connections. For solution 1, 6 VPs are used for connection 1 while 5 VPs are used for connection 2. The total VP number in the

4 2664 IEICE TRANS. COMMUN., VOL.E83 B, NO.12 DECEMBER 2000 (a) Multiple point-to-point VC scheme (b) Pure VC tree scheme (c) VP tree scheme (d) Multiple point-to-point VP scheme (e) Point-to-multipoint VP scheme Fig. 1 Feasible solutions to support a multicast connection. VP layout is 8 and the maximum number of VPs on a link is 2. For solution 2, 5 VPs are used for connection 1 while 4 VPs are used for connection 2. The total VP number in the VP layout is 7 and the maximum number of VPs on a link is also 2. But the VP hops for both connections in solution 2 is more than that in solution 1. For individual connections, the less VP hops used the better (the next subsection will describe the performance metrics used in detail). In this example, if there are already a large number of VPs using link 24, we may prefer solution 1 to solution 2. It seems that the above solutions are trivial as only two connections are considered in the example. But in realistic situation, many multicast connections coexist in the same network. Then the problem of designing VP layout to optimize the global VPL performance while satisfying the requirements of individual connections becomes very complicated. 2.3 Desirable Properties of a Good VPL The following metrics are usually to be considered in designing a VPL [4], [10], [19]. These performance metrics have to be optimized for obtaining a good VPL. 1. Bandwidth resource consumption. When designing VP network, an important factor is the bandwidth resource consumption, especially for multicast applications. Existing unicast method for point-

5 FENG and KHEONG: EFFICIENT SUPPORT FOR MULTICAST APPLICATIONS 2665 Fig. 2 (a) Solution 1 (b) Solution 2 Our solutions to support two multicast connections. to-point connections is no longer valid in this case as the media traffic usually consumes much more bandwidth resources than data traffic. If the QoS class is CBR or VBR, the fact that a VC uses a VP reduces the available bandwidth on that VP. Therefore, the amount of reserved bandwidth for a VC is proportional to its VP hops. Therefore, the VP hops within a connection should be kept as low as possible. 2. VC connection setup delay. A low VC connection setup time improves the connection management [4]. The VC connection setup delay is directly proportional to the number of VPs that are concatenated to form the VC. That is, the VP hops within a VC multicast connection should be minimized for the following reasons. As discussed below, a feasible solution for most networks relies on setting up VC s, for a specific conferencing session, and within the same session another VC multicast connections should be set up promptly. Note that this setup procedure could be much more completed than that for point-topoint connection, especially when the multicast group size is large. As a result, the overhead of a lengthy connection setup due to high VP hop count in a multicast VC connection for such Variable Multicast VC connection VC s may exceed the necessary time for the data transfer itself. The setup overhead of a VC is directly proportional to the number of VP s that are used by the VC along its route (i.e., its VP hops). This stems from the fact that only at the end of each VP, the network layer software must be involved in setting up the VC routing tables in support of the new VC. In other words, the processing at the VP terminating nodes involves updating of routing table and VP bandwidth allocation table. 3. Switching delay. Switching delay should be minimized, as it is one of the important components in determining the transmission delay between any two nodes in a network. Hence, the path chosen for a VC should be of minimum length in terms of the number of nodes that are to be traversed from the source to the destination within the multicast connection. 4. Number of total VPs. The number of VPs that are to be configured in a network for connectivity is important. Keeping the number of VPs to minimum improves network management. This, in turn, improves the fault tolerance of the network. Further, a low number of VPs increases the scalability of the network [4]. 5. Number of VPs that share a link. The number of VPs that are carried by a link should be small. The number of used VP routing entries at a given port processor 2 is equal to the number of incoming VP s that use the attached link. This holds since the VPI of a cell that belongs to such a VP is used by the port processor as an index into its VP routing table. It is more convenient to think of as the maximum number of VP s that share a link, rather than a limit on the routing table load. An important fault tolerance issue that stems from the above is based on a VP rerouting protocol suggested in [3] for recovering the network from link failures: upon a link failure, the network reroutes VP s that use the faulty link to other paths in the network, thereby achieving a low overhead migration of all VC s that use the faulty link (and thus use the rerouted VP s) to alternative routes. The overhead of this recovery process is clearly proportional to the number of VP s that share the link. 6. Multiple paths. Several self-healing schemes have been proposed for ATM networks which can perform recovery from failures by rerouting VPs [3]. A concept of backup VPs has been used to provide rapid recovery from failures. A backup VP is a second VP established between the end points of an existing VP. It is desirable to have VPs with multiple alternative paths for improved fault tolerance. 3. Problem Formulation In this section, we formulate the design problem of VPL for supporting multicast traffic. For our VPL design problem, we make the following assumptions. Among them, assumptions 1 4 are also used in almost all relevant works [3] [6], [10], [12]. 1. The physical network consists of nodes intercon-

6 2666 IEICE TRANS. COMMUN., VOL.E83 B, NO.12 DECEMBER 2000 nected by single physical links. The physical links are bi-directional and the capacity available on a link can be used in either direction. Capacity is assigned to VPs deterministically, i.e. statistical multiplexing among VPs is not considered. However, statistical multiplexing within a VP is allowed. 2. VPs are coupled in pairs of unidirectional routes in opposite directions. It was shown that such a configuration of VPs improves connection management [4], [6]. As in [6], we refer to such pairs of VPs as VP pairs. 3. We assume that each node can switch both VPs and VCs. This assumption is implied by an architecture in which VP and VC routing tables reside in every node/port-processor in the network. 4. Point-to-multipoint VP is not used. The multicast connection is set up by setting up the VC multicast tree through the VP s in the network. This assumption is verified by two facts: (1) we can make use of existing call setup protocol to deal with the multicast connection setup. (2) as mentioned above, point-tomultipoint VP scheme is not feasible for a reasonable size network as the VP number needed could be too large. In addition, we assume that all the switches are multicast-capable. 5. For a multicast connection, there is an explicit setup delay requirement. This requirement is a kind of quality-of-service (QoS) required by the applications and guaranteed by the network for the services. Of course, in realistic implementations, it is plausible that many nodes will switch VPs exclusively or some nodes are not multicast-capable; however, incorporating this fact into the model complicates it with details that may damage the insight into the problem, which motivated this work. In this work, we do not assume any scheme for mapping services to the VPs. The two schemes proposed in the literature are based on the concepts of complete sharing and service segregation [9], [10]. In the complete sharing based scheme, a VP can be used by all traffic classes, i.e. traffic streams of different QoS classes can share VPs. In case of service mapping based on the concept of complete segregation, only one traffic class can use a VP. Hence, in this case multiple VPLs are to be designed for an ATM network, one VPL for each traffic class. Since our proposed VPL design algorithm does not depend on the mapping of services to VPs, it can be used along with any of the VP service mapping schemes. In order to formulate the VPL design problem, we define a graph theoretical model for it. The communication network can be represented as an undirected graph G(V,E) where V is the set of nodes and E is the set of edges between the nodes. The set of nodes V, and the set of edges E, correspond to the switches and the physical links interconnecting the switches in the network, respectively. We need the following definitions to allow a formal treatment of the problem. Definition 1: A multicast traffic demand pattern M i is a tuple M i (s i,d i,ρ i ) where s i V : source switching node for the multicast connection of M i D i \s i V : set of destination switching nodes for the multicast connection of M i ρ i : expected traffic load for the multicast traffic demand pattern (MTDP) M i. i Γ: sequence number in Γ and Γ is the set of all multicast connection types. Observation 1: We focus on the VPL design for multicast traffic in this paper. However, point-to-point connection can be deemed as a special case of multicast connection and the point-to-point traffic can therefore also be included. In this case, D i =1. Observation 2: In case of VP service mapping based on the complete sharing concept, the traffic between a pair of nodes is expressed as the equivalent bandwidth requirement for satisfying different traffic streams. A traffic stream is a traffic flow of distinct QoS. In the case of complete segregation based VP service mapping, the expected traffic is expressed as the equivalent bandwidth requirement for satisfying a particular traffic stream. Let P (G) be the set of all possible paths in G. The Virtual Path Layout (VPL) design problem can be defined as finding a virtual path layout Ψ,Ψ=(G,I) where G =(V,E ) is a virtual graph and I: E P (G) is a mapping function. In the virtual graph G, V is the set of all nodes of the physical network and a virtual edge ξ =(v 1,v 2 ) E represents a virtual path pair between nodes v 1 and v 2. The function I(ξ) maps each virtual edge ξ =(v 1,v 2 ) to its corresponding route (path) in G. We term this path the elicited path of ξ. Definition 2: A multicast tree T i =(V i,e i ) for traffic demand pattern M i is a sub-graph in G rooted from source s i and spanning each destination of D i, where V i V is the set of vertices and E i E is the set of links in T i. Definition 3: A virtual path tree Ti =(V i,ei ) for the traffic demand pattern M i, is a tree rooted from the source switching node s i spanning all the destination switching nodes in D i with edges being virtual paths. Definition 4: The hop-count of a virtual path tree Ti, H(T i ), is defined as the number of edges (VPs) in the virtual path tree Ti. Observation 3: As mentioned above, a multicast connection of traffic pattern M i is set up through a VC tree based on the VP layout. Actually, only the VPs in the VP tree Ti are used. The setup delay is related to the number of VPs in Ti, i.e., the hop-count H(Ti )oft i.

7 FENG and KHEONG: EFFICIENT SUPPORT FOR MULTICAST APPLICATIONS 2667 Definition 5: The load L(e) on a link e E is the number of virtual path pairs ξ E that include link e in their elicited paths. It can be represented as: L(e) = {ξ E e I(ξ)}. Definition 6: The load of a given VP layout Ψ is L(Ψ) = max e E L(e). Definition 7: The load on VP routing table for switch v, denoted as R{v}, is the number of occupied entries in the VP routing table. Observation 4: The number of used VP routing entries at a given port processor is equal to the number of incoming VPs that use the attached link [6]. This is verified by the fact that the VPI of a cell that belongs to such a VP is used by the port processor as an index into its VP routing table. On the other hand, the total number of VPs going through a switch must not exceed the maximum number of VPs which can be supported by the switch. The maximum number of VPs may be different for each switch due to the varying number of permanent VPs supported per switch. This maximum number is usually much less than 2 8 : R{v} =2 8 the number of permanent VPs going through the switch the number of dynamic VPs going through the switch [4]. With the above definitions, the VPL design problem is to find a virtual topology over the physical network and to assign bandwidths to the VPs in such a way that the transmission and switching cost, and control and management cost are minimized. The VPL design problem can now be expressed in the following way: Given G, M i, (i Γ) Hi, i Γ R (v), v V Find Ψ=(G,I), F Minimizing Subject to C x + C y H(Ti ) <H i, i Γ R(v) <R (v), v V where F = {f e e E }, f e is the capacity assigned to the VP e; C x is the transmission and switching cost; C y is the control and management cost. As introduced in Sect. 2, C x is directly proportional to average number of VPs concatenated to form a VC multicast connection, i.e., the average hop-count of a VP tree, and the number of switching nodes within a VC multicast connection. C y is directly proportional to two factors: the total number of VPs in the designed VP layout and the average number of VPs carried by each physical link. Hi is the predetermined maximum hop-count of the VP tree Ti. It is determined by the connection setup delay requirement for a multicast call of the traffic demand pattern M i R (v) is the maximum allowed number of occupied entries in the VP routing table of switch v. Obviously there is no explicit expression for relationship between the optimization objective and the design parameters. The objective function is also associated with the constrained factors. In addition, it was also shown that the VP layout problem is NP-complete [6]. The problem of VPL design for multicast traffic can be viewed as a generalization of the VPL design for point-to-point traffic. The above optimization problem is thus NP-complete too. In the next section, we propose a heuristic based solution for the VPL design problem. 4. The Proposed Solution 4.1 General Framework Our solution for this problem is based on three main phases. Phase 1: Routing phase Given the topology of the network and the amount of available bandwidth on each link, we find a tree that spans all of the destination s switching nodes, the source s switching node, and all necessary intermediate nodes for each of the MTDP. All of the routes of VC s set up for the connection request of this MTDP will be included in this tree; hence, it is termed the multicast base tree (MBT for short). There are several different sets of properties that may be desirable for a MBT. Each such set yields a different tree, and the possible options are discussed below. Between these options we have chosen to focus on a MBT with the following properties. The tree cost is as small as possible in terms of its propagation and processing delay. The allotted bandwidth on each tree link is large enough to accommodate the required bandwidth for all VP s that use that link Phase 2: VP Layout (VPL) design In this phase, we determine a set of VP s that enable constructing multicast trees for individual MTDP M i (i Γ) using the paths in the corresponding MBT, so that the transmission and switching cost, the control and management cost are minimized. This phase is the central focus of the paper. In Sect. 5 we formally define the problem in this phase and present a heuristic algorithm for it. Phase 3: Run-time adjustment While the above two phases are performed during a design phase, this phase pertains to the run-time aspects of the service. These aspects include variations in the In this paper, we denote a switch at node v V as switch v for simplicity.

8 2668 IEICE TRANS. COMMUN., VOL.E83 B, NO.12 DECEMBER 2000 protocols for setting up (and taking down) VC s for the connection and protocols for dynamically changing the design of phase 1 and phase 2, upon a request of a multicast party to join/withdraw from the service. An overview of the three stages is given below. For sake of brevity, we do not extend the description of phase 1 and phase 3 beyond this overview and focus in the rest of the paper on phase 2. Overview of Phase 1: In this paper we assume that all the multicast connections with the same source and destinations use a same tree. There are a few different options for a MBT, depending on the resource constraints and cost model. MBT-1 Minimize the tree cost: min C = c e e T where the cost c e is a predefined function for link e in the tree T, such as the cost for bandwidth usage per time unit. It can also be the transmission delay on each link. This is the MBT mentioned earlier that is assumed in the rest of the paper due to its good characteristics, reasonable cost model, and algorithmic feasibility. This tree is hard to find algorithmically. The problem is identical to the Steiner tree problem, which is NPhard, but many heuristics are known to solve it with an approximation factor of two [16]. A simplified definition for tree cost is the number of edges within the tree. MBT-2 Minimize the tree cost: min C = c e subject to delay(p sd ) < delay, e T d D i where P sd is the path from source s to destination d, delay(p sd ) is the packet transmission delay on path P sd and delay is a delay bound for a multicast session. This type of tree is reasonable, especially for real-time multimedia applications, as most multimedia have a packet transmission delay bound. In this paper, however, we do not consider MBT-2 for three reasons: (1) we focus on the VPL layout design and the routing phase is not our concern in this paper; (2) the construction of MBT-2 is even more difficult than that of MBT-1. We have studied this problem in [18] and an efficient algorithm for constructing MBT-2 can also be found in [7]. MBT-3 Maximize the average residue capacity on the tree: max R = r e /size(t ) e T where r e is the residue capacity of link e and size(t )is the number of edges in tree T. This cost function is difficult to be used for the routing phase as the residue capacity on a link is a dynamic parameter in the network, but the VPL design is usually for a semi-permanent occasion. MBT-4 Any Tree for Which the Bandwidth Used Per Link Does Not Exceed the Available Bandwidth: While MBT-1 only considers links that can support VP s, it may be useful to also consider links with less free bandwidth. Such an approach may yield a feasible solution in places where MBT-1 cannot find one. The main drawbacks of this approach are: (1) it yields solutions that tightly fit into the available bandwidth and may leave no room for expanding the MBT to support more traffic and (2) it is algorithmically hard to find. Overview of Phase 2: This phase is based on a heuristic procedure called VP Layout Design, which is described in detail in Sect. 5. For each MBT constructed in phase 1, a set of paths (called simple paths) is selected. The simple paths from all MBTs are sorted as a priority queue. Then a heuristic algorithm is used to obtain VPs from this queue. The idea is to select only those paths as VPs which can be used by more traffic patterns and more traffic, so that the number of VPs required to be configured for a particular traffic demand is minimized. Once a path is selected from the set of candidate VPs, all the routes that contain the selected VP are removed from the set of routes generated in the first phase. The process of selecting VPs is continued until the set of routes, found in the first phase, becomes empty. In the next section, we will present this phase in detail. Overview of Phase 3: The run-time protocols for multicast connections in VP-based ATM networks can be divided into two categories: protocols that make use of the VP layout constructed in phase 2 for multicast connections and protocols that update the VP layout. The protocols in first category deal with the VC setup/teardown for each connection request. Actually they are essentially identical to regular VC setup/teardown protocols. The protocols in second category deal with the changes in the VP layout. When some new multicast connection requests arrive and the existing VP layout cannot satisfy the requirements, one or more new VPs may need to be set up. This updates the VP layout and reduces its optimality. On the other hand, it is not cost-effective to reconstruct the whole layout in an optimal manner using above phase 2 for each new possible request. Therefore, a practical compromise would be to occasionally reconstruct the whole layout, when some certain performance metrics of the current VP layout deteriorates severely. 5. Heuristic for VPL Design We first address the idea of the VP layout design algorithm and then give a formal pseudocode description for the algorithm.

9 FENG and KHEONG: EFFICIENT SUPPORT FOR MULTICAST APPLICATIONS Description of the Heuristic for VP Layout Design We give several definitions used in the description of the VPL design heuristic: Definition 8: A simple path in a tree T i =(V i,e i ), denoted as ξ, is a sequence of distinct vertices v 1,v 2,...,v n, ξ E i. The set of simple paths in T i is denoted as SP(T i ). A simple path may include multiple links. For the example of Fig. 2, SP(T 1 ) = {18, 12, 246, 23, 37} and SP(T 2 )={37, 32, 245, 219}. Note that the simple paths are not the same with the virtual paths in Fig. 1(a). Definition 9: The length of a simple path ξ is the number of edges included, denoted as Length(ξ). Definition 10: A sub-path is a part of a path. That is, a path contains the sub-path. Definition 11: A path is partitioned by a sub-path with the reminder of the path being one or two subpaths. In the first phase, we have obtained a multicast tree for each of the given MTDPs. For each of these trees, a set of simple paths can be abstracted. The simple paths for all the traffic patterns form a set of candidate VPs, denoted as Φ. If multiple MBTs have the same simple path, only one is put into Φ. For each simple path ξ = Φ, we compute the number of MBTs that includes ξ, denoted as W (ξ), and the total traffic load on ξ, denoted as Y (ξ). Then simple paths in Φ are arranged in a priority queue (non-increasing queue), denoted as Q, according to their lengths. If multiple simple paths have the same length, the sequence is determined by the traffic load on it. Specifically, the simple path with larger load is placed in front of the one with smaller load in the queue. In this way, the sorting of the simple paths is done in the order of their path lengths and then the traffic load on them. Let Path Sort() be the function representing this sorting procedure. The VP layout design is performed by continually selecting a simple paths from Q and determining whether it can be converted to a VP for the VP layout, until all the simple paths in Q are selected. This procedure begins from the top of Q to ensure that longer path with larger traffic load is always selected first. At each step, a simple path is selected for inclusion in the VPL if one of the following three conditions is satisfied: (a) the path satisfies at least Y 0 units of traffic load; (b) the path is a simple path for at least W 0 trees found in phase 1; (c) the path length is one, i.e. the path is an edge in the physical network. The idea is to select only those paths as VPs which can be used by more traffic. Thus, the parameters W 0 and Y 0 are related to the load, the hop-count of trees for different traffic demand pattern, and the total numbers of VPs in the VPL. Once a path is selected from the set of candidate VPs, all the simple paths in Q that contain the selected VP are partitioned using the selected VP. This implies that all the partitioned simple paths have been checked and do not satisfy the above 3 conditions. At this moment, we need to check if this partitioning succeeds or not. This is because that partitioning results in (1) the increase of load on routing table on two intermediate switching nodes in the path; (2) the increase of the hop-count of some involved VP trees. If any constraint is violated, the partitioning for this path is failed and aborted. Otherwise, the new (one or two) paths are checked if the paths are already there in Q or not. If yes, two steps are proceeded to: (1) the traffic load on these paths are incremented by the traffic load of the split route; (2) the paths which contain the selected VP are then removed from the set of routes. This is done to avoid the selection of paths, which are subpaths of already selected VPs, which do not actually satisfy the above criteria for VP selection. If no, assign W and Y values of the path to the new generated paths and put the new paths to Q. The process of selecting VPs is continued until all the paths in Q checked. The final remaining paths in Q are then converted to VPs. Now the current set of VPs is the initial solution to the VPL design problem. In the next step, some of the VPs selected in the earlier step are dropped to improve the solution. A VP is removed if the hop-count constraint for involved trees is not violated. The final step is to assign capacity to individual VPs of the VP layout, so that the traffic demand on the network can be satisfied. In this work, we do not consider blocking probability when assigning capacities to the VPs. The capacity that is to be assigned to a VP can easily be found using the MTDPs and the set of trees that were generated in the first phase of the VPL design algorithm. It is possible to improve the capacity assignment scheme by taking the required blocking probability limit into consideration. However this is beyond the focus of this paper. 5.2 Algorithm A formal description of the VP Layout Design procedure in psedocode form is shown in Fig. 3. Several functions used there are defined as follows: 1. T i = MinCost Tree(M i ): Given a MTDP, the graph and the edge cost, this function computes a minimum cost tree. In this paper we use the KBM algorithm [17] to compute the tree for individual MTDPs. 2. Compute Load(SP(T i ),v): For a given set of simple paths of tree T i, this function computes the load of

10 2670 IEICE TRANS. COMMUN., VOL.E83 B, NO.12 DECEMBER 2000 Fig. 3 The pseudocode of ÎÈ Ä ÝÓÙØ Ò procedure.

11 FENG and KHEONG: EFFICIENT SUPPORT FOR MULTICAST APPLICATIONS 2671 Fig. 4 The pseudocode of procedure ÓÒ Ø ÓÒ (). Fig. 5 The pseudocode of procedure ÎÈ ÖÓÔ(). VP routing table on switching node v, i.e., the total number of the VPs going through v and the VPs have a termination at node v. 3. Path Sort(Φ): This function sorts the simple paths in the set Φ to a priority queue Q according to the their length and the traffic load. 4. Partition(ξ,z,p 1,p 2 ): This function partitions a path ξ by its sub-path z. That is, the part z is removed from the path ξ, the remainder is two sub-paths p 1 and p 2 : ξ z = p 1 + p Re Arrange(Q): In the algorithm, when a path in Q is partitioned, one or two new sub-paths might be added to Q. This function re-arranges the priority queue Q. 6. Condition Check(Q, ξ, z i ) = 0: When a path ξ is partitioned by a sub-path z i, this function checks that whether the constraints of the routing table load on the involved switching nodes and constraints for the involved MTDPs are satisfied. A description of this function in psedocode is given in Fig VP Drop(Φ VP,T i,hi ): This function is used to improve the VPL solution by removing some unnecessary VPs. A description of this function in psedocode is given in Fig Computing Complexity of the Algorithm Let n be the number of nodes in the graph, m be the maximum number of destinations of a MTDP and k be the total number of MTDPs under consideration. The first phase of the algorithm uses KMB algorithm to compute the minimum cost trees. This algorithm has a worst case time complexity of O(mn 2 ) [17]. For the second phase, the computing of the load of the VP routing table on the nodes takes O(kn) time. As for a specific MTDP with m destinations, the maximum number of simple paths included is smaller than 2m (worst case is for the binary tree), the total number of simple paths is 2km. That is, the outer while loop from line (23) to (49) executes at most 2km times. The inner for also executes at most 2km times. In the inner for iterations, the Condition Check() func-

12 2672 IEICE TRANS. COMMUN., VOL.E83 B, NO.12 DECEMBER 2000 tion takes at most O(k) time, and the remainder takes O(1) time. Therefore line (23) to (49) of the algorithm takes O(4k 2 m 2 k)=o(m 2 k 3 ) time. Finally, the VP Drop() function takes at most O(2kmk) =O(mk 2 ) time. As a result, the computing complexity of the entire algorithm is O(mn 2 )+O(m 2 k 3 )+O(kn 2 ) = O(mn 2 )+O(m 2 k 3 ). 6. Simulation Results We employ the similar method used in literature [7], [18] to generate random graphs. Nodes are placed randomly in a rectangular coordinate grid by generating uniformly distributed random numbers for the x and y coordinates. A directed edge is placed from u to v with probability p(u, v) =βe d(u,v) Lα where d(u, v) is the Euclidean distance between u and v, L is the maximum distance between two nodes and α and β are two parameters that control the characteristics of the graph produced. Increasing β increases the average vertex degree of the graph and increasing α increases the ratio of longer edges relative to shorter ones. These two parameters allow the generation of a wide variety of random graphs. The edges costs are randomly selected from the set {1, 2,...,10}. The random edge costs match typical values for costs used in the NSFNET backbone network [7], [18]. Our simulation experiments are base on randomly generated networks. Several random networks are checked. As the results for the proposed algorithm exhibit the similar trends, we describe the experiments conducted on only one network which has 100 nodes 152 links (α =0.22, β =0.10). Let there be 300 MTDPs with 3 destinations, 300 MTDPs with 5 destinations and 1000 MTDPs with one destinations (point-to-point connections). Each of the MTDPs has a traffic load uniformly distributed between 1 and 10 units. All the multicast groups are generated by randomly placing the source and destinations on the graphs. The performance metrics we have taken for analyzing the VPL design are: a. Total number of VPs. The total number of VPs configured in the VPL is an important aspect in determining the cost of control and management of the network. b. Maximum and average Load. We define the term load as the number of VPs that are carried by a link. This performance metric is an indicative of the cost of control and management, and recovery for a link failure. c. Average VP hopcount. This is the average number of VPs that are to be concatenated for setting up a VC connection between a Fig. 6 Total number of VPs vs. W 0 and Y 0. source-destination pair. The VP hopcount factor determines the connection setup delay and transmission delay for a VC connection. Since there is no VPL design algorithm proposed in the literatures, we cannot compare the performance of our algorithm with others. Instead, we mainly investigate the effect of the design parameters W 0, Y 0 and the constraints H i, R (v) on the performance metrics of VPL through the simulation experiments. For designing a good VPL, considering the above mentioned performance metrics, a suitable value for the parameters W 0, Y 0 has to be found. Varying their values, different VPLs can be obtained. The designer can get a tradeoff between some performance metrics by using different values of W 0 and Y 0. Figure 6 shows the total number of VPs configured with varying values of W 0 and Y 0. In this figure, we have assumed that there is no constraint on the hopcount of connections or the load of the routing table. We can see that a small variation in the value of W 0 or Y 0 decreases the total number of VPs required for connectivity considerably. For the comparison purpose, the pure VP based and the pure VC based VPL designs are also plotted. Now let us assume that maximum load of routing table on every node is fixed at 120, the maximum hopcount for MTDPs of 3, 5 and 1 destinations are fixed at 20, 35 and 10, respectively. In Fig. 7, the average VP hopcount value for the 3-destination, 5-destination and point-to-point MTDP are plotted as a function of Y 0 for the proposed algorithm (W 0 = ). Figure 8 and Fig. 9 shows the maximum load and average load on a link versus Y 0. In these two figures, we have assumed W 0 =, that is, the total number of VPs is controlled only by selecting Y 0. From these figures, it is very clear that when Y 0 becomes larger, the average VP hopcount, maximum and average load on a link also become larger. In other words, the fewer total number of VPs can be only obtained at the expense of more hopcount for the connections and larger load on the link. These results are expected, since increasing

13 FENG and KHEONG: EFFICIENT SUPPORT FOR MULTICAST APPLICATIONS 2673 Fig. 7 Y 0. Average hopcount for 3,5 and 1 destination MTDPs vs. Fig. 10 The total VP number in VPL vs. R (v). Fig. 8 Fig. 9 Maximum load vs. Y 0 for the proposed heuristic. Average load vs. Y 0 for the proposed heuristic. 7. Conclusion In this paper we have studied the problem of efficiently supporting multicast applications in an ATM network. We first discussed several simple solutions to the problem and explained why they do not scale well to large networks and their drawbacks. We then presented our solution, which can be tuned to adjust various requirements. Our solution is based on three main phases, among which the second phase (that deals with laying out the VPs for individual multicast traffic patterns) is the most complex, and in the second half of the paper we focused on it. We devised formalism for the problem and presented a fairly fast algorithm for solving it. In the first phase of the proposed algorithm, a set of multicast trees for individual multicast traffic demand pattern is found. In the second phase, a set of VPs is selected from a set of candidate VPs. The proposed heuristic approach minimizes the number of VPs required for connectivity of the VPL, by selecting only those VPs which are being used by a large number of VC connections. The proposed solution is flexible in the sense that the designer can achieve different VPLs based on the cost functions associated with different networks. This is achieved by choosing a suitable value for two design parameters W 0 and Y 0 from the performance plots obtained for different values of them. References the value of Y 0 resulted in smaller number of VPs for the VPL. To gain some insight into the effect of constraint R (v) on the VPL designed, we first fix Hi as large enough and vary R (v) (assume all nodes have the same constraint of routing table load). Figure 10 shows the total VP number of the VPL vs. R (v). We can see that the total VP number increase with the R (v). When R (v) is larger than 170, the total VP number almost reaches its maximum value [1] The ATM Forum, ATM, User-Network Interface Specification, version 3.0. [2] C. Partridge, Gigabit Networking, Addison-Wesley, Reading, MA, [3] R. Cohen and A. Segall, Connection management and rerouting in ATM networks, IEEE INFOCOM 94, pp , Toronto, Ont., Canada, [4] S. Ahn, R.P. Tsang, S.R. Tong, and D.H.C. Du, Virtual path layout design on ATM networks, IEEE INFO- COM 94, pp , Toronto, Ont., Canada, [5] M.H. Ammar, S.Y. Cheung, and C.M. Scoglio, Routing multiple connections using virtual paths in an ATM network, IEEE INFOCOM 93, pp , San Francisco, CA,

14 2674 IEICE TRANS. COMMUN., VOL.E83 B, NO.12 DECEMBER [6] O. Gerstel, I. Cidon, and S. Zaks, The layout of virtual paths in ATM networks, IEEE/ACM Trans. Networking, vol.4, pp , Dec [7] V.P. Kompella, J.C. Pasquale, and G.C. Polyzos, Multicast routing for multimedia communication, IEEE/ACM Trans. Networking, vol.1, no.3, June [8] M.H. Ammar, A.Y. Cheung, and C.M. Scoglio, Routing multipoint connections using virtual paths in an ATM network, INFOCOM 93, pp [9] G. Feng and T.S.P. Yum, Traffic analysis for multiparty videoconferencing in virtual path based ATM networks, International Journal of Communication Systems, vol.12, Issue 1, pp.79 96, [10] I. Chlamtac, A. Farago, and T. Zhang, Optimizing the system of virtual paths, IEEE/ACM Trans. Networking, vol.2, no.6, pp , [11] M.J. Lee and J.R. Yee, A design algorithm for reconfigurable ATM networks, Proc. IEEE INFOCOM 93, pp , [12] K. Murakami and H.S. Kim, Virtual path routing for survivable ATM networks, IEEE/ACM Trans. Networking, vol.4, no.1, pp.22 39, [13] M. Aydemir and Y. Viniotis, Deterministic algorithm for VP assignment in ATM networks, Computer Communications, vol.19, pp , [14] G. Woodruff, N. Perinpathan, F. Chang, P. Appanna, and A.L. Garcia, ATM network resources management using layer and virtual network concept, Proc. Fifth IFIP/IEEE International Symposium on Integrated Network Management, San Diego, CA, USA, [15] Y.W. Leung and Tak-shing Yum, Connection optimization for two types of videoconferences, IEE Proc. Commun., vol.143, no.3, June [16] P. Winter, Steiner problem in networks: A survey, Networks, vol.17, pp , [17] L. Kou, G. Markowsky, and L. Berman, A fast algorithm for Steiner trees, Acta Informatica, vol.15, pp , [18] G. Feng and T.S.P. Yum, Efficient multicast routing with delayconstraints, International Journal of Communication Systems, vol.12 I.3, pp , [19] O. Gerstel, I. Cidon, and S. Zaks, Efficient support for client/server applications over heterogeneous ATM networks, IEEE/ACM Trans. Networking, vol.6, no.4, Aug Gang Feng received his B.Eng. and M.Eng. degrees in Electronic Engineering from the Universityof Electronic Science and Technologyof China, in 1986 and 1989, respectively, and the Ph.D. degrees in Information Engineering from The Chinese Universityof Hong Kong in He joined the Information Communication Institute of Singapore, Nanyang Technological Universityin August Before that, he worked for about one year in the Department of Electronic Engineering, CityUniversityof Hong Kong as a postdoc. From 1989 to 1995, he was with the Research Institute of Information Systems, University of Electronic Science and Technologyof China. Dr. Feng s research interests include routing and performance evaluation for highspeed networks, multimedia networks, TCP enhancement over heterogeneous networks. Recently, he branches out to work on reliable multicast, active network, flow and congestion control in the Internet. David SiewChee Kheong is currentlythe Director of Information Communication Institute of Singapore (ICIS), School of EEE, Nanyang Technological University. He obtained his B.Eng. in Electrical Engineering from Universityof Singapore in 1979 and MSc. in Communication Engineering, Imperial College in After a six and a half years stint in the industry, he joined NTU as a Lecturer in 1986 and was appointed Associate Professor in He was seconded to National Computer Board (NCB) as the DeputyDirector, ICIS in August 1995 and managed the transfer of ICIS from NCB to NTU in In January 1997, he was appointed as the Director of the Institute. His research interests include E-Commerce, Traffic Shaping, Neural Networks and Network Performance. He is a member, IEEE and a senior member, SCS, Singapore.