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 sup-port multicast applications, especiallyreal-time multimedia ap-plications. 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 pro-posed for designing a good virtual-path layout for a given set of multicast traffic demand patterns. Byvarying the design parame-ters, we can obtain different VPLs which possess different trade-offs among some important criteria, namely, the network over-head for a connection setup, routing table resources and control and management cost. Simulations are performed on randomly generated networks to demonstrate the performance and scala-bilityof 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: multicast,virtualpathlayout,asynchronous trans-fermode
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 implemen-tation of the broadband integrated services digital net-work (B-ISDN) with the goal of supporting new attrac-tive 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 connec-tion established on a sequence of physical links between a pair of nodes. Specifically, the VP concept was mo-tivated by the desire to accomplish the following: (1) reduce setup and switching costs of VCs, which are es-tablished on demand by using existing VPs, and (2) reduce network control cost by bundling many connec-tions into single units (VPs). Utilization the advan-tages provided by the virtual path concept is funda-mental 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, 1999. Manuscript revised June 19, 2000.
†The authors are with Information Communication
In-stitute of Singapore, Nanyang Technological University, Sin-gapore.
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 at-tention in the communication literature, yet the prob-lem 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 point-to-point connection traffic was taken into account. In this paper, we focus on the design of VP layout to effi-ciently supportmulticast trafficthat is fundamental for many multimedia services in ATM networks.
1.2 Multicast Paradigm
ATM is rapidly becoming the dominant transport tech-nology for broadband services, especially for real-time multimedia applications, such as multiparty videocon-ferencing [9], [15], distance leaning and video distribu-tion. 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 net-work 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 real-time or interactive mulreal-timedia applications. For in-stance, let us consider a kind of multimedia confer-encing called speaker-video conferconfer-encing [9]. When there is a change of speaker in the conference ses-sion, a new multicast connection for transmitting the video and audio needs to be set up. In this sce-nario, 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.
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 net-work is closely related to the degree how the above-mentioned requirements can be satisfied. A good VP layout design can efficiently support those multicast ap-plications with QoS guaranteed and with high network resource utilization at a low management cost. There-fore, 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 for-mulated as an optimization problem in which the ob-jective 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. Begin-ning with an initial feasible solution, the algorithm it-eratively 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 find-ing a VPL for this restricted case by decomposfind-ing the network and operating on the network recursively is given. Using this solution as a building block, a solu-tion 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 net-works. 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 require-ment between node pairs.
In [4], the VPL design problem is formulated as an optimization problem where the objective is to min-imize the switching cost and the call setup time, sub-ject 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 min-imum cost VPs that are passing through this switch (called aviolating 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 net-work to efficiently support client/server applications. A “greedy” solution was proposed to optimize the net-work overhead for a request/response and the utiliza-tion of bandwidth. In addiutiliza-tion, 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 sup-porting multicast applications, especially real-time multimedia applications over an ATM network by set-ting up semi-permanent VP’s. Our algorithm aims at minimizing the transmission, switching, control and management cost by properly designing the VP net-work. 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-to-point 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 solu-tion which can tune to the tradeoff among the net-work 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.
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 de-fined. 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 appli-cations) and present heuristic for it. The simulation results demonstrating the performance and the scala-bility of our solution are presented in Sect. 6 and finally we summarize the results in Sect. 7.
2. Feasible Solutions
2.1 Feasible Solutions
To support multicast services in an ATM network, sev-eral 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 point-to-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 physi-cal 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 solu-tion 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 phys-ical link. Then a multicast connection can be estab-lished by making use of these VPs. This solution is op-timal 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 disadvan-tage of this solution is that the allocated bandwidth to each such “direct” VP may be reused only by mul-ticast 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 multi-cast 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) demon-strates 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 solu-tions 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 interme-diate 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 net-work 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 mul-ticasting scheme. This is a VC mulmul-ticasting 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 op-timize 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., con-nection setup delay, management cost). In Fig. 2, some VPs are shared by two multicast connections. For so-lution 1, 6 VPs are used for connection 1 while 5 VPs are used for connection 2. The total VP number in the
(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 num-ber of VPs on a link is also 2. But the VP hops for both connections in solution 2 is more than that in so-lution 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 met-rics 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 multi-cast applications. Existing unimulti-cast method for
point-(a) Solution 1
(b) Solution 2
Fig. 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 band-width 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 connec-tion management [4]. The VC connecconnec-tion 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 fea-sible 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-to-point 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 mul-ticast VC connection for such “Variable Mulmul-ticast 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 band-width 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 net-work for connectivity is important. Keeping the num-ber of VPs to minimum improves network management. This, in turn, improves the fault tolerance of the net-work. Further, a low number of VPs increases the scal-ability 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 incom-ing 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 max-imum 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 over-head 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 fail-ures 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 rele-vant works [3]–[6], [10], [12].
intercon-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 mul-tiplexing within a VP is allowed.
2. VPs are coupled in pairs of unidirectional routes in opposite directions. It was shown that such a configu-ration 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 architec-ture 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 assump-tion 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-to-multipoint 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 pro-posed 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 algo-rithm 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 commu-nication network can be represented as an undirected graphG(V, E) whereV is the set of nodes andEis the set of edges between the nodes. The set of nodes V, and the set of edgesE, 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 patternMi
is a tupleMi≡(si, Di, ρi) where
si ∈V: source switching node for the multicast con-nection ofMi
Di\si⊂V: set of destination switching nodes for the multicast connection ofMi
ρi: expected traffic load for the multicast traffic de-mand pattern (MTDP)Mi.
i ∈ Γ: sequence number in Γ and Γ is the set of all multicast connection types.
Observation 1: We focus on the VPL design for mul-ticast traffic in this paper. However, point-to-point con-nection can be deemed as a special case of multicast connection and the point-to-point traffic can therefore also be included. In this case,|Di|= 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 map-ping, the expected traffic is expressed as the equivalent bandwidth requirement for satisfying a particular traf-fic 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 avirtual path layout Ψ, Ψ = (G∗, I) whereG∗ = (V, E∗) is a “virtual” graph andI: E∗ → P(G) is a “mapping” function. In the virtual graphG∗,
V is the set of all nodes of the physical network and a “virtual” edge ξ = (v1, v2) ∈ E∗ represents a virtual
path pair between nodesv1 and v2. The functionI(ξ)
maps each virtual edgeξ= (v1, v2) to its corresponding
route (path) inG. We term this path theelicited path
ofξ.
Definition 2: A multicast treeTi= (Vi, Ei) for traf-fic demand patternMiis a sub-graph inG∗rooted from source si and spanning each destination ofDi, where
Vi ⊂V is the set of vertices andEi ⊂E is the set of links inTi.
Definition 3: A virtual path tree Ti∗ = (Vi, Ei∗) for
the traffic demand patternMi, is a tree rooted from the source switching node si spanning all the destination switching nodes inDi with edges being virtual paths.
Definition 4: The hop-count of a virtual path tree
Ti∗,H(Ti∗), is defined as the number of edges (VPs) in
the virtual path treeTi∗.
Observation 3: As mentioned above, a multicast connection of traffic pattern Mi 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 inTi∗, i.e., the hop-count H(Ti∗) ofTi∗.
Definition 5: The load L(e) on a link e ∈ E is the number of virtual path pairsξ∈E∗that include linke
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(Ψ) = maxe∈EL(e).
Definition 7: The load on VP routing table for switch† v, denoted asR{v}, is the number of occupied entries in the VP routing table.
Observation 4: The number of used VP routing en-tries 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 28:
R{v}= 28 − 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, Mi, (i∈Γ) Hi∗, ∀i∈Γ R∗(v), ∀v∈V Find Ψ = (G∗, I), F Minimizing Cx+Cy Subject to H(Ti∗)< Hi∗, ∀i∈Γ R(v)< R∗(v), ∀v∈V
where F ={fe|e∈E∗},feis the capacity assigned to the VPe;Cxis the transmission and switching cost;Cy
is the control and management cost. As introduced in Sect. 2, Cx is directly proportional to average number of VPs concatenated to form a VC multicast connec-tion, i.e., the average hop-count of a VP tree, and the number of switching nodes within a VC multicast con-nection. Cy 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
treeTi∗. It is determined by the connection setup delay
requirement for a multicast call of the traffic demand
pattern MiR∗(v) is the maximum allowed number of occupied entries in the VP routing table of switchv.
Obviously there is no explicit expression for rela-tionship between the optimization objective and the de-sign parameters. The objective function is also associ-ated 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 prob-lem 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 themulticast 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 prop-erties.
• 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 Mi
(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 de-sign 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
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 differ-ent options for a MBT, depending on the resource con-straints and cost model.
MBT-1—Minimize the tree cost: minC=
e∈T ce
where the cost ce is a predefined function for link e
in the treeT, 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 characteris-tics, reasonable cost model, and algorithmic feasibility. This tree is hard to find algorithmically. The problem is identical to the Steiner tree problem, which is NP-hard, but many heuristics are known to solve it with an approximation factor of two [16]. A simplified def-inition for tree cost is the number of edges within the tree.
MBT-2—Minimize the tree cost: minC =
e∈T
ce subject todelay(Psd)<delay∗, d∈Di
where Psd is the path from sources to destination d,
delay(Psd) is the packet transmission delay on pathPsd
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, how-ever, 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 con-struction 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:
maxR=
e∈T
re/size(T)
wherereis the residue capacity of linkeandsize(T) is the number of edges in treeT. This cost function is dif-ficult to be used for the routing phase as the residue ca-pacity on a link is a dynamic parameter in the network,
but the VPL design is usually for a semi-permanent oc-casion.
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 solu-tions 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 calledVP Layout Design, which is described in detail in Sect. 5. For each MBT con-structed 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 se-lected VP are removed from the set of routes generated in the first phase. The process of selecting VPs is con-tinued 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 mul-ticast 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 cat-egory 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 com-promise 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 al-gorithm and then give a formal pseudocode description for the algorithm.
5.1 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 Ti = (Vi, Ei), denoted as ξ, is a sequence of distinct vertices
v1, v2, . . . , vn, ξ ∈ Ei. The set of simple paths in Ti
is denoted asSP(Ti).
A simple path may include multiple links. For the example of Fig. 2, SP(T1) = {18,12,246,23,37}
and SP(T2) = {37,32,245,219}. Note that the
sim-ple 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 asLength(ξ).
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 sub-paths.
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 asW(ξ), and the total traffic load onξ, denoted asY(ξ). Then simple paths in Φ are arranged in a priority queue (non-increasing queue), de-noted asQ, according to their lengths. If multiple sim-ple paths have the same length, the sequence is deter-mined 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 continu-ally 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 Qare selected. This pro-cedure begins from the top of Qto 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 leastY0units of traffic load;
(b) the path is a simple path for at leastW0trees 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 parametersW0and
Y0 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 inQthat 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 partition-ing succeeds or not. This is because that partitionpartition-ing 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 traf-fic 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 andY values of the path to the new generated paths and put the new paths toQ. The process of selecting VPs is continued until all the paths inQchecked. The final remaining paths inQare 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 proce-dure in psedocode form is shown in Fig. 3. Several func-tions used there are defined as follows:
1. Ti=MinCost Tree(Mi): 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(Ti), v): For a given set of simple paths of tree Ti, this function computes the load of
Fig. 4 The pseudocode of procedureConditionCheck().
Fig. 5 The pseudocode of procedureVPDrop().
VP routing table on switching node v, i.e., the total number of the VPs going throughv and the VPs have a termination at node v.
3. Path Sort(Φ): This function sorts the simple paths in the set Φ to a priority queueQaccording to the their length and the traffic load.
4. Partition(ξ, z, p1, p2): This function partitions a
path ξ by its sub-path z. That is, the part z is re-moved from the pathξ, the remainder is two sub-paths
p1and p2: ξ−z=p1+p2.
5. 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 queueQ.
6. Condition Check(Q, ξ, zi) = 0: When a path ξ is partitioned by a sub-path zi, 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. 4.
7. VP Drop(ΦV P, Ti, Hi∗): This function is used to
im-prove the VPL solution by removing some unnecessary VPs. A description of this function in psedocode is given in Fig. 5.
5.3 Computing Complexity of the Algorithm
Letn 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 ofO(mn2) [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-tion takes at mostO(k) time, and the remainder takes
O(1) time. Therefore line (23) to (49) of the algo-rithm takes O(4k2m2k) = O(m2k3) time. Finally, the VP Drop() function takes at mostO(2kmk) =O(mk2) time. As a result, the computing complexity of the entire algorithm is O(mn2) +O(m2k3) +O(kn2) =
O(mn2) +O(m2k3). 6. Simulation Results
We employ the similar method used in literature [7], [18] to generate random graphs. Nodes are placed ran-domly in a rectangular coordinate grid by generating uniformly distributed random numbers for thexandy
coordinates. A directed edge is placed fromutovwith probability
p(u, v) =βe−dLα(u,v)
where d(u, v) is the Euclidean distance between uand
v, Lis the maximum distance between two nodes and
α and β are two parameters that control the charac-teristics 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 ran-dom edge costs match typical values for costs used in the NSFNET backbone network [7], [18]. Our simula-tion experiments are base on randomly generated net-works. 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 be-tween 1 and 10 units. All the multicast groups are generated by randomly placing the source and destina-tions on the graphs.
The performance metrics we have taken for ana-lyzing 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 con-catenated for setting up a VC connection between a
Fig. 6 Total number of VPs vs.W0 andY0.
source-destination pair. The VP hopcount factor de-termines 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 parametersW0,Y0and the
con-straintsHi∗,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 parametersW0,Y0 has to be found. Varying their
val-ues,different VPLs can be obtained. The designer can get a tradeoff between some performance metrics by using different values ofW0andY0.
Figure 6 shows the total number of VPs configured with varying values of W0 and Y0. In this figure, we
have assumed that there is no constraint on the hop-count of connections or the load of the routing table. We can see that a small variation in the value of W0
or Y0 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 hop-count 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
Y0for the proposed algorithm (W0=∞).
Figure 8 and Fig. 9 shows the maximum load and average load on a link versusY0. In these two figures,
we have assumed W0 = ∞, that is, the total number
of VPs is controlled only by selecting Y0. From these
figures, it is very clear that whenY0becomes 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
Fig. 7 Average hopcount for 3,5 and 1 destination MTDPs vs.
Y0.
Fig. 8 Maximum load vs.Y0 for the proposed heuristic.
Fig. 9 Average load vs.Y0for the proposed heuristic.
the value of Y0 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 varyR∗(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 2028.
Fig. 10 The total VP number in VPL vs.R∗(v).
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 prob-lem 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 require-ments.
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 fo-cused 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 connec-tions. 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 parametersW0 andY0from the performance plots
ob-tained for different values of them.
References
[1] The ATM Forum, ATM, User-Network Interface Specifica-tion, version 3.0.
[2] C. Partridge, Gigabit Networking, Addison-Wesley, Read-ing, MA, 1994.
[3] R. Cohen and A. Segall, “Connection management and rerouting in ATM networks,” IEEE INFOCOM’94, pp.184– 191, Toronto, Ont., Canada, 1994.
[4] S. Ahn, R.P. Tsang, S.R. Tong, and D.H.C. Du, “Vir-tual path layout design on ATM networks,” IEEE INFO-COM’94, pp.192–200, Toronto, Ont., Canada, 1994. [5] M.H. Ammar, S.Y. Cheung, and C.M. Scoglio, “Routing
multiple connections using virtual paths in an ATM net-work,” IEEE INFOCOM’93, pp.98–105, San Francisco, CA,
1993.
[6] O. Gerstel, I. Cidon, and S. Zaks, “The layout of virtual paths in ATM networks,” IEEE/ACM Trans. Networking, vol.4, pp.873–884, Dec. 1996.
[7] V.P. Kompella, J.C. Pasquale, and G.C. Polyzos, “Multi-cast routing for multimedia communication,” IEEE/ACM Trans. Networking, vol.1, no.3, June 1993.
[8] M.H. Ammar, A.Y. Cheung, and C.M. Scoglio, “Routing multipoint connections using virtual paths in an ATM net-work,” INFOCOM’93, pp.98–105.
[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, 2000.
[10] I. Chlamtac, A. Farago, and T. Zhang, “Optimizing the system of virtual paths,” IEEE/ACM Trans. Networking, vol.2, no.6, pp.581–587, 1994.
[11] M.J. Lee and J.R. Yee, “A design algorithm for reconfig-urable ATM networks,” Proc. IEEE INFOCOM’93, pp.144– 151, 1993.
[12] K. Murakami and H.S. Kim, “Virtual path routing for sur-vivable ATM networks,” IEEE/ACM Trans. Networking, vol.4, no.1, pp.22–39, 1996.
[13] M. Aydemir and Y. Viniotis, “Deterministic algorithm for VP assignment in ATM networks,” Computer Communica-tions, vol.19, pp.1036–1050, 1996.
[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 Manage-ment, San Diego, CA, USA, 1997.
[15] Y.W. Leung and Tak-shing Yum, “Connection optimization for two types of videoconferences,” IEE Proc. Commun., vol.143, no.3, June 1996.
[16] P. Winter, “Steiner problem in networks: A survey,” Net-works, vol.17, pp.129–167, 1987.
[17] L. Kou, G. Markowsky, and L. Berman, “A fast algorithm for Steiner trees,” Acta Informatica, vol.15, pp.141–145, 1981.
[18] G. Feng and T.S.P. Yum, “Efficient multicast routing with delayconstraints,” International Journal of Communication Systems, vol.12 I.3, pp.181–195, 1999.
[19] O. Gerstel, I. Cidon, and S. Zaks, “Efficient support for client/server applications over heterogeneous ATM net-works,” IEEE/ACM Trans. Networking, vol.6, no.4, Aug. 1998.
Gang Feng received his B.Eng. and M.Eng. degrees in Electronic Engineer-ing from the Universityof Electronic Sci-ence and Technologyof China, in 1986 and 1989, respectively, and the Ph.D. degrees in Information Engineering from The Chinese Universityof Hong Kong in 1998. He joined the Information Commu-nication Institute of Singapore, Nanyang Technological Universityin August 1999. 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 Elec-tronic Science and Technologyof China. Dr. Feng’s research interests include routing and performance evaluation for high-speed 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 cur-rentlythe Director of Information Com-munication 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 Commu-nication Engineering, Imperial College in 1987. After a six and a half years stint in the industry, he joined NTU as a Lec-turer in 1986 and was appointed Associate Professor in 1999. He was seconded to National Computer Board (NCB) as the DeputyDirector, ICIS in August 1995 and man-aged the transfer of ICIS from NCB to NTU in 1996. 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.