Connection Link Connection Member Intermediate Switch. Connection Link Receiver member Intermediate Switch Source member

Transcription

1 Proceedings of the 996 IEEE International Conference on Distributed Computing Systems, pp 5-, Hong Kong, May 996 A Lightweight Protocol for Multipoint Connections under Link-State Routing Yih Huang and Philip K McKinley Department of Computer Science Michigan State University East Lansing, Michigan 88 fhuangyih, mckinleyg@cpsmsuedu Abstract In this paper, we propose a protocol for the construction and maintenance of multipoint connections (MCs) The protocol is based on link-state routing: information regarding multipoint connections is broadcast to network switches, which perform all computations locally The protocol is generic in that it can be used with MCs of dierent types, including symmetric MCs, receiveronly MCs, and asymmetric MCs Results of a simulation study show that this generality can be achieved with negligible (in normal trac periods) to moderate (in very busy periods) signaling overhead Introduction A multipoint connection (MC) is a network entity that denes the routing of data packets among participants in a multi-party conversation The growing importance of multipoint connections in computer networking and telecommunications is demonstrated by several recent developments, including wide use and distribution of IP-multicast [] and related protocols [], the addition of multicast extensions to the OSPF Internet routing protocol [], the development of the MBONE Internet multicast backbone [], and the ongoing development of multicast protocols for asynchronous transfer mode (ATM) networks [5] This work was supported in part by DOE grant DE-FG0-9ER567, and by NSF grants MIP-90066, CCR-95088, and CDA990 An MC is a virtual topology, dened by routing tables and other state information in the network, which allows the participants to communicate with one another When the network is modeled as a graph, an MC for a given subset of the nodes consists of a subgraph such that any member of the set can reach all other members Not all applications require the same MC functionality We distinguish three dierent types of MCs, as follows Symmetric MC Every participating node in the MC can be both a sender and a receiver A typical application that may be supported by a symmetric MC is a teleconference, since every member may both speak and listen Figure (a) shows a symmetric MC with ve members The problem of determining an optimal symmetric MC topology is the well-know minimum Steiner tree problem [6] Receiver-only MC Members of this type of MC constitute the receivers of one or more communication sessions The delivery of a packet to a receiver-only MC consists of two stages In the rst stage, the packet is delivered to any node on the MC In the second stage, this contact node forwards the packet to the other MC members, as illustrated in Figure (b) The core-based tree (CBT) multicast protocol [], suggested recently by the Internet community, makes use of receiveronly MCs, with the restriction that only one distinguished node { the core node { can be the contact point Asymmetric MC Members of an asymmetric MC

2 are distinguished as senders and/or receivers Typical applications of asymmetric MCs include video broadcasting and remote teaching Sourcerooted shortest-path trees that are destined for a common IP multicast address and constructed by the MOSPF multicast protocol [] form a typical asymmetric MC A multicast virtual connection dened by the ATM UNI standard [7] is another example, with the restriction that there can be only one sender per connection Figure (c) shows a single-source asymmetric MC Connection Link Connection Member Intermediate Switch Link used by sources to contact the MC Connection Link Connection Member Intermediate Switch the rest of the network is referred to as the ingress switch of that host The protocol presented in this paper is intended to construct and maintain MCs among switches, rather than hosts A switch is said to be a member of a connection if one or more of its attached hosts are interested in the connection When a host wants to join or leave a connection, it sends this request to its ingress switch, which takes an appropriate action according to the MC protocol An MC protocol may take advantage of the underlying unicast routing protocol, which is responsible for discovering much of the network status information needed by the MC protocol Such information includes the delays between switches, the link capacities, and switch workloads Changes in network status are termed network events, or simply events (a) a symmetric MC (b) a receiver-only MC Connection Link Receiver member Intermediate Switch Source member Link-state routing (LSR) [8] is an increasingly important type of unicast routing An LSR protocol makes complete knowledge of the network available to all switches The local status of each switch is learned by the network via the ooding of link-state advertisements (LSAs) Based on received advertisements, each switch maintains a complete local image of the network, which it uses to compute routing table entries The Open Shortest Path First (OSPF) protocol [8] is one of the most well-known LSR unicast protocols (c) an asymmetric MC Figure Three types of multipoint connections An MC is dynamic if its member list changes over time; otherwise, it is static Dynamic MCs are more dicult to construct and manage than static MCs, but nd much more application in practice For example, conferencing applications, video distribution, and replicated le services, all must support dynamic sender and/or receiver group memberships We are interested in the design of ecient protocols to implement dynamic MCs An MC protocol is a network protocol that denes the set of rules and conventions by which MCs are constructed and maintained, and is executed among processing entities within a communications network The network usually consists of three major components: hosts, switches, and communications links The switch (or switches) that connect a particular host to In this work, we develop a distributed and generic MC protocol, called D-GMC, which retains the advantages and working principles of LSR, but which incurs lower computational overhead than other approaches The methods we advocate are general enough to accommodate all three types of MCs discussed above Moreover, the protocol is independent of the particular algorithm used to compute the MC topology; algorithms for both Steiner trees and source-rooted trees can be accommodated Evaluation of dierent algorithms for computing dynamic MC topologies can be found in [9] The remainder of this paper is organized as follows Section discusses alternative LSR-based MC protocols and their limitations Section describes the operation of the D-GMC protocol and the advertisement format used Section presents the results of a simulation study, in which the behavior of the D-GMC protocol is evaluated under various workloads Section 5 discusses related work Finally, in Section 6, we conclude the paper with the a brief discussion of the merits and applicability of the D-GMC protocol

3 LSR-Based MCs An LSR protocol can be extended to support multiparty communication by distributing MC membership information in LSAs [] Switches in the network collect these advertisements and maintain member lists and MC topology information for all active MCs The dierences among LSR-based MC protocols lie in how topology computations are triggered The MOSPF protocol [], a multicast protocol suggested by the Internet community, is an extension of the unicast OSPF protocol [8] In MOSPF, the addresses of the hosts listening to a multicast address are broadcast in group-membership LSAs, and routers maintain complete member lists for all active multicast addresses Upon receiving such a datagram for a multicast address M, the router consults its local database for the member list of M and computes a shortestpath tree, rooted at the source of the datagram, that reaches all hosts listening to M The router then saves this topology information in a routing cache and forwards the datagram along the appropriate out-going links This forwarding will trigger further topology computations at other routers The MOSPF approach of on-demand, data-driven topology computations is well-suited to the construction of source-rooted trees, but has drawbacks in other scenarios First, a receiver-only MC topology computation cannot be triggered by packets from senders Second, an on-demand approach cannot be applied if quality of service (QoS) negotiation is needed prior to data transmission Third, source-rooted trees are not desirable for symmetric communication, due to construction and maintenance costs of multiple trees An alternative approach to MC topology computation is to follow the \spirit" of LSR: upon receiving a membership LSA, each switch updates its local database and invokes a procedure to compute a new topology for each MC aected by the event This method of topology computation is said to be eventdriven, and is general enough to support multiple MC types The cost of this generality is redundancy in computation In a network with n switches, a single event could trigger n redundant computations for every existing MC Such high overhead renders this protocol impractical In the following discussion, this event-driven MC protocol will be referred to as the brute-force LSR-based MC protocol The proposed D-GMC protocol is an event-driven MC protocol that maintains the full generality of brute-force LSR-based MC routing We emphasize that LSR-based MC protocols, such as MOSPF and D-GMC, are not intended for direct implementation in very large networks or internets [0] LSR itself is generally intended for use in a set of networks under one administrative authority (in Internet terminology, an Autonomous System) which typically contains a few hundred switches and possibly several thousand hosts Scalability can be addressed by introducing a routing hierarchy into large networks The combination of an LSR protocol and routing hierarchy is under consideration for the ATM PNNI (Private Network-Network Interface) standard In this paper, we present the \basic" D-GMC protocol; its extension to hierarchical networks is part of our ongoing work The D-GMC Protocol In the D-GMC protocol, only the switches that detect events are required to compute new MC topologies These new topology proposals are carried in LSAs and are ooded through the network LSAs that advertise events, such as changes in link/nodal status and MC membership dynamics, are termed event LSAs Their corresponding ooding operations are termed event oodings A major problem that the D-GMC protocol must address is the proposal of multiple, inconsistent MC topologies by switches that detect dierent events at nearly the same time This problem is solved in the D-GMC protocol by introducing timestamps to LSAs Every switch maintains a timestamp associated with its local image of each MC Timestamps allow switches to detect proposals that are based on incomplete or obsolete information A timestamp T is an n-tuple of natural numbers, where n is the number of switches in the network The x-th component of T, denoted by T [x], species how many events have been heard from switch x Given two timestamps A = (a 0 ; : : : ; an?) and B = (b 0 ; : : : ; bn?), we say that A B if ai bi, for all i = 0; : : : ; n? We say that A > B, if A B and A 6= B MC LSA Format Two types of LSAs are distinguished: MC LSAs and non-mc LSAs Non-MC LSAs are processed by the underlying unicast protocol, while MC LSAs are used by the D-GMC protocol In a network consisting of n switches, an MC LSA is a tuple (S; F; V; G; P; T );

4 where S f0; ; : : : ; n? g is the source address of the LSA, F fmc; mcg is a ag that identies this LSA as either an MC LSA or a non-mc LSA, V fjoin, leave, link, noneg species an event from the source switch S, G identies the MC to which this LSA is relevant, P is a (possibly NULL) topology proposal, and T is a timestamp When P is present, it encodes a complete topological description of the MC G A non-mc LSA is a tuple (S; F; D); where S is the source of the LSA, F with value mc indicates that the LSA is used for the advertisement of a link/nodal event, and D encodes a description of the event The exact format of link/nodal event descriptions is dened by the underlying unicast LSR protocol, and is not discussed further An MC LSA can indicate an event of type \link" when a link/nodal event aects the topology of an MC An example is shown in Figure, where switch x intends to join connection C, switch y intends to leave connection C, and switch u detects that one of its incident links has gone down Let us assume that the malfunctioning link is used by both connections C and C The three events trigger ve advertisements: one for the join event, one for the leave event, and three for the link event In general, a link/nodal event will cause the ooding of exactly one non-mc LSA, followed by k MC LSAs, where k is the number of MCs whose topologies are aected by the event Consequently, an MC receives its own set of LSAs regarding relevant events, and protocol activities associated with dierent MCs proceed independently Therefore, the algorithms of the D-GMC protocol are presented in a per-mc manner without loss of generality Timestamps Every switch in the network maintains three timestamps for each MC: the received timestamp R, the expected stamp E, and the current topology timestamp C When necessary, we use the notation Rx;m, Ex;m, and Cx;m to denote the three timestamps at switch x for MC m However, in most of the discussion, one or both subscripts will be omitted Figure gives an abstract representation of the three timestamps associated with the local image of a given MC The y-th element in the timestamp R for MC m at switch x, denoted Rx;m[y], records the number of events that switch x has heard from switch y pertaining to MC m The timestamp E maintains information about LSAs that are expected, but which have not yet Events Switch x joins connection C Link (u,v) goes down Switch y leaves connection C Advertisements MC LSAs for C (processed by LMC) S F V G P T x mc join C S F V G P T u mc link C S F D u mc Non MC LSAs (processed by unicast LSR) MC LSAs for C (processed by LMC) S F V G P T u mc link C S F V G P T y mc leave C Figure Events and LSAs in the D-GMC protocol Switch x: state information for given MC R x Increment R[x] y EventHandler() Local event (at switch x) occurs that affects this MC Increment E[x] E C Increment R[y] Save state in C whenever local image is changed x ReceiveLSA() LSA with timestamp T arrives from switch y Update timestamp E to reflect any new information : For every element E[i], set E[i] = max(e[i], T[i]) Figure Representation of timestamps R, E, and C arrived E is updated whenever an LSA arrives and reects any new information gleaned from that LSA's timestamp Specically, the value of Ex;m[y] indicates that switch x should expect to hear Ex;m[y]? Rx;m[y] events from switch y relating to MC m The times-

5 tamp C describes the state upon which the current local image of the MC is based When compared with the R or E timestamp, the C timestamp can be used to determine whether the current local image is obsolete Protocol Entities and Algorithms Two MC protocol entities, EventHandler() and ReceiveLSA(), execute at every network switch EventHandler() is invoked whenever an event occurs at the switch This routine creates and oods an event LSA, which describes the event and may also contain a new topology proposal ReceiveLSA() is activated whenever LSAs are present in the mailbox of a switch This routine reads the incoming LSAs and updates locally stored state information accordingly If inconsistencies are detected among received and local information, a new topology proposal is constructed and ooded by way of a triggered LSA Both of the two entities use the timestamps R, E, and C Timestamp accesses are assumed to be atomic to avoid race conditions between the two entities The EventHandler() algorithm is given in Figure The algorithm is presented in a per-mc manner, that is, when an event occurs, this routine is invoked for every connection aected by the event In addition to the ooding of an MC LSA carrying the event, the routine must decide whether to compute a new topology proposal for the MC The decision is based on a comparison of timestamps E and R of the MC (line ) If E indicates that other LSAs are expected, then EventHandler() defers to ReceiveLSA() to receive those outstanding LSAs and to decide whether to compute and broadcast a new topology (see Figure 5) This information is passed to ReceiveLSA() by setting a shared variable, make proposal ag, equal to TRUE (line 7) There is one make proposal ag variable for each connection m As with the three timestamps, the make proposal ag variables are shared between EventHandler() and ReceiveLSA(), and access to them is assumed to be atomic If a new topology is to be computed, then the current value of R is saved (line ) prior to the computation Before the proposal is broadcast, R is compared against the saved value of R (line 6) to ensure that the new topology is not already obsolete If they are dierent, then again EventHandler() defers to ReceiveLSA by setting make proposal ag to TRUE (line ) Otherwise, the proposal is broadcast (line 7) The algorithm for the ReceiveLSA() entity is given Algorithm: Event Handler Input: switch ID x, event ev, and connection m /* All variables are for connection m at switch x */ /* Subscripts are omitted in presentation */ : R[x] = R[x] + ; E[x] = E[x] + : IF (R E) : /* there are no known outstanding LSAs */ : old R = R /* save current R */ 5: Construct a new topology proposal P for the connection 6: IF (old R = R) /* proposal is still valid */ 7: Flood the MC LSA (x; 0; ev; m; P; R) 8: C = old R 9: make proposal ag = FALSE 0: Update routing entries for incident links in m according to P : ELSE /* ood, but defer to ReceiveLSA() to make proposal */ : Flood the MC LSA (x; mc; ev; m; null; old R) : make proposal ag = TRUE : ENDIF 5: ELSE /* ood, but defer to ReceiveLSA() to make proposal */ 6: Flood the MC LSA (x; mc; ev; m; null; R) 7: make proposal ag = TRUE 8: ENDIF Figure The algorithm for EventHandler() in Figure 5 This entity is invoked whenever there is at least one LSA for connection m in the mailbox For every such LSA, the routine rst checks if the LSA contains an event (line 5) (a triggered LSA may contain a topology proposal, but no event) It updates the local member list of connection m and advances the R timestamp as necessary (lines 7-8) Next, the existence of any outstanding LSAs is recorded in E (line 0) The LSA is then checked for a topology proposal If one is present, the decision to accept or ignore it is based on a comparison of the LSA's timestamp T and the value of E If T E, then the proposal is based on all events known to this switch, and the proposal and its timestamp are accepted and recorded in local variables (line -) The make proposal ag for connection m is set to FALSE (line ), since an up-to-date topology for the connection has been accepted Otherwise, the LSA is further examined for any inconsistency problem: if its x-th component, T [x], does not reect all local events at switch x, then the switch should plan to construct a new topology proposal by setting its make proposal ag variable to TRUE (though it may need to process additional LSAs rst) After consuming all the LSAs in the mailbox, the

6 Algorithm: ReceiveLSA() Input: switch ID x, connection ID m, and the network size n : candidate proposal = NULL : candidate proposal stamp = C : WHILE (there are LSAs for MC m in mailbox) : Get next LSA ` = (S; mc; V; m; P; T ) 5: IF (V 6= none), /* an event LSA */ 7: R[S] = R[S] + 8: Update member list of m, if V 6= link 9: ENDIF 0: FORALL 0 y < n, E[y] = max(e[y]; T [y]) : IF (T E) and (P 6= NULL), : candidate proposal = P : candidate proposal stamp = T : make proposal ag = FALSE 5: ELSE IF (R[x] > T [x]), /* inconsistency detected */ 6: make proposal ag = TRUE 7: ENDIF 8: ENDWHILE 9: IF (make proposal ag ), (R E), and (R > C), 0: old R = R /* save current R */ : Compute a new topology proposal P : IF (there are no LSAs in mailbox for MC m) and (old R = R), : Flood (x; mc; none; m; P; R) : E = R /* bring E up to date */ 5: candidate proposal = P 6: candidate proposal stamp = C 7: make proposal ag = FALSE 8: ELSE 9: candidate proposal = NULL 0: ENDIF : ENDIF : IF (candidate proposal 6= NULL), /* accept the proposal */ : C = candidate proposal stamp : Update routing entries for incident links in m according to candidate proposal 5: ENDIF Figure 5 The algorithm for ReceiveLSA() ReceiveLSA() entity decides at line 9 whether a new proposal should be computed, primarily depending on the value of the make proposal ag variable Two optimizations are also included in the decision: a switch should receive all the LSAs that it is expecting before performing any topology computation (condition R E) and should avoid proposing a topology based on the same set of events as the current topology (condition R > C) Moreover, two conditions must be satised before the proposal is actually ooded: ) there cannot be any LSAs in mailbox at the end of the topology computation, and ) the value of R must not have been advanced since the computation started If the proposal is still up-to-date at the end of computation, it is broadcast to the other switches and stored locally (lines ); otherwise, it is withdrawn MC Creation and Destruction The creation and destruction of an MC requires no special mechanisms When the rst member of an MC advertises its presence, the other switches allocate necessary data structures for the MC and accept the topology proposal contained in the advertisement When a switch detects an empty member list of an MC, local data structures corresponding to the MC are deleted 5 Topology Computation Algorithm Although the D-GMC protocol is designed to be independent of the underlying topology computation algorithm, for eciency reason two types of computations need to be distinguished: incremental update and from-scratch computation This is because MC topologies, such as source-rooted shortest-path trees or Steiner trees, are computationally expensive Computing a new topology from scratch for every membership or network change is not desirable Whenever possible, an implementation should invoke an incremental update algorithm, which adds a tree branch to reach a new member or removes a branch from a leaving member Brand-new MC topologies are computed only when the network conguration changes adversely and/or the present topology deviates signicantly from an optimal one 6 Correctness of the Protocol Due to space limitations, proofs of correctness of the D-GMC protocol are omitted; full details can be found in [] Performance Evaluation The main objective of the D-GMC protocol is to reduce the overall computational load on network switches, while supporting a variety of dierent MC types In most situations, there is only one topology computation and one ooding operation per event This compares very favorably with the MOSPF protocol, which requires a topology computation at every switch involved in the MC However, it is also important to

7 study the the behavior of the D-GMC protocol when several events occur in a short period of time Such situations raise the concern of cascading reactions among switches A simulation study was conducted to investigate the behavior of the D-GMC protocol under such circumstances The simulator is based on the CSIM simulation package [] Additional simulation results can be found in [] Simulation methodology We use the symbol Tc to represent the time to compute a topology, and Tf to denote the ooding diameter of the network, that is, the time to complete a ooding operation in the worst case Our experiments are designed to evaluate the D-GMC protocol under dramatically dierent Tf -to-tc ratios in order to test whether the protocol can be applied to diverse network settings and MC types We dene the time Tf + Tc to be a round In this study, only membership-change events are simulated Two event-generating methods are used In the rst, events are clustered in a short period of time and conict with each other Such very busy periods may be found at the beginning period of a multi-party conversation In the second event-generating method, events are relatively evenly distributed over long periods of time We are interested in the following performance metrics: topology computations per event, ooding operations per event, and convergence time The rst metric reveals the computational overhead incurred by an MC protocol, the second measures the communication overhead, and the third represents the protocol's responsiveness to member changes Simulation Results We conducted three sets of experiments In these experiments, networks containing up to 00 switches were simulated In each set of simulations, 0 graphs were generated randomly for each network size Experiment (topology computation dominates): This set of simulations are used to investigate situations in which per-hop LSA transmission time is signicantly less than Tc The values of the simulation input parameters correspond to results we observed in our own ATM testbed when multipoint connections are established [] Specically, AAL- 5 per-hop transmission time for a 5-byte packet is approximately s, and per-hop signaling time when adding a new member to an MC is approximately 0-50 s Figure 6 shows the results under these parameter values The mean values are presented along their 95% condence intervals The number of topology computations per event, across the entire network, is plotted in Figure 6(a) The D-GMC protocol generates fewer than 5 topology computations during the bursty period for all cases In most of the cases, the D-GMC protocol generates fewer than 5 advertisements per event, as shown in Figure 6(b) The price we pay is the time to reach consensus among switches, 0 to 5 rounds in most cases, as shown in Figure 6(c) Proposals per event (a) proposals per event Convergence Time Floodings per event Network size (b) oodings per event (c) convergence time (in round) Figure 6 (Experiment ) Bursty event generation, high computation time, with 95% condence intervals Experiment (communication time surpasses computation time): This experiment is designed to investigate the behavior of the D-GMC protocol when a ooding operation takes longer than a topology computation a situation that may occur in WANs In all cases, the ooding diameter Tf is signicantly larger than the topology computation time Tc The results are given in Figure 7 As we can see, this combination of parameter values incurs more topology computations per event than that of the previous experiment However, the computational overhead is still well un-

8 der control The number of ooding operations per event also increases slightly to approximately 0 The convergence time is slightly better than that of the rst set of experiments, possibly due to the long duration of a round Proposals per event Floodings per event Network size Proposals per event (a) proposals per event Flooding operations per event Network size (b) oodings per event Figure 8 (Experiment ) Normal trac periods (a) proposals per event (b) oodings per event Convergence Time (c) convergence time (in round) Figure 7 (Experiment ) Bursty event generation, high communication time Experiment (\normal" trac periods): In normal periods, most of the events are suciently separated that they are handled individually The results of this experiment are presented in Figure 8 The D- GMC protocol operates smoothly and eciently in this setting, in terms of both topology computations per event and ooding operations per event In fact, both ratios are very close to 0, demonstrating the minimal overhead imposed by the protocol for sparse membership updates The convergence times are not presented here because our denition of convergence time does not apply to sparse events, which seldom conict with each other 5 Related Work Multicast protocols have made signicant progress in recent years, primarily in the Internet community [,,, 5, 6] and for ATM networks [5, 7] In addition to the MOSPF protocol discussed in previous sections, the CBT multicast protocol [] is designed to construct and maintain receiver-only MCs (shared delivery trees) for the groups of hosts listening to IP multicast addresses An MC constructed by the CBT protocol has the restriction that only one designated switch, the core, can be contacted by senders The topology of a CBT connection is dened by the unicast paths between the core and the group members This protocol has the advantage of ecient use of network resources, but suers from trac concentration [7] The selection of the core switch presents another problem: a good choice depends on the locations of connection members in the communication network Since many networks, such as public telecommunications networks, do not typically reveal their internal topologies to users or applications, selection of a good core node may be impossible The D-GMC protocol does not incur this problem ATM multicast protocols [5, 7] follow the singlesource asymmetric MC approach The only sender, called the root, is responsible for adding or dropping receivers A new receiver must contact the root via an predetermined registry procedure This membership maintenance procedure and the single-source restriction impose considerable overhead on multiparty sessions For example, an N-participant teleconference would require the construction and maintenance of N dierent -to-(n? ) connections Furthermore, for a single membership change, the N senders must be contacted and each of the -to-many connections must be modied

9 6 Conclusions We have developed a generic and ecient protocol for the construction and maintenance of dynamic multipoint connections under link-state routing The protocol retains the merits of LSR (every switch holds complete knowledge and computes locally), while reducing computational overhead dramatically compared to other approaches Simulation results promise the applicability of the protocol under a wide variety of applications and network settings Being a link-state routing protocol, the D-GMC protocol has the intrinsic advantage in fault tolerance The protocol handles faulty components in the network through topology computations triggered by link/nodal events However, the ability of the protocol to survive disastrous situations, such as network partitioning, remains for further study Due to its ability to accommodate dierent types of MCs and the popularity of LSR, we see immediate potential applications of the proposed protocol In the Internet, dierent types of MCs are presently built by dierent multicast protocols The generality and eciency of the D-GMC protocol open the possibility of using one protocol for all purposes The same argument applies to ATM networks, which currently suer from the lack of group addresses and the absence of standards for symmetric and receiver-only MCs Further Information A number of related papers and technical reports of the Communications Research Group at Michigan State University are available via anonymous ftp and world-wide web The respective addresses are ftp://ftpcpsmsuedu/pub/crg and References [] S E Deering and D R Cheriton, \Multicast routing in datagram internetworks and extended LANs," ACM Transactions on Computer Systems, vol 8, pp 85{0, May 990 [] A J Ballardie, A New Approach to Multicast Communication in a Datagram Internetwork PhD thesis, Department of Computer Science, University College London, May 995 [] J Moy, \Multicast extensions to OSPF" Internet RFC 58, March 99 [] M R Macedonia and D P Brutzman, \MBone provides audio and video across the Internet," IEEE Computer, April 99 Also available at [5] G Armitage, \Support for multicast over UNI based ATM networks" Internet Draft draft-ietfipatm-ipmc-05txt, May 995 [6] P Winter, \Steiner problem in networks: A survey," Networks, pp 9{67, 987 [7] A Forum, ATM User-Network Interface (UNI) Specication Version Prentice Hall, September 99 [8] J Moy, \OSPF version " Internet RFC 58, March 99 [9] M Imase and B M Waxman, \Dynamic Steiner tree problem," SIAM Journal on Discrete Mathematics, vol, pp 69{8, August 99 [0] J Moy, \MOSPF: Analysis and experience" Internet RFC 585, March 99 [] Y Huang and P K McKinley, \A lightweight protocol for multipoint connections under link-state routing," Tech Rep MSU-CPS-95-8, Department of Computer Science, Michigan State University, East Lansing, Michigan, Oct 995 [] H D Schwetman, \CSIM: A C-based, processoriented simulation language," Tech Rep PP , Microelectronics and Computer Technology Corporation, 985 [] C C Huang and P K McKinley, \Communication issues in parallel computing across ATM networks," IEEE Parallel and Distributed Technology, vol, no, pp 7{86, 99 [] S Deering, \Host extensions for IP multicasting" Internet RFC, August 989 [5] D Waitzman, C Partridge, and S Deering, \Distance vector multicast routing protocol" Internet RFC 075, November 988 [6] S Deering, D Estrin, D Farinacci, V Jacobson, C gung Liu, and L Wei, \Protocol independent multicast (PIM): Motivation and architecture" Internet Draft draft-ietf-idmr-pim-arch-0ps, January 995 [7] L Wei and D Estrin, \The trade-os of multicast trees and algorithms," in International Conference on Computer Communications and Networks (Also available as Internet Draft 995), September 99