Hop By Hop Multicast Routing Protocol ∗
Lu´ıs Henrique M. K. Costa1,2, Serge Fdida1, and Otto Carlos M. B. Duarte2 [email protected], [email protected], [email protected] 1 Laboratoire d’Informatique de Paris 6 2 Grupo de Teleinformatica´ e Automac¸ao˜ Université Pierre et Marie Curie Universidade Federal do Rio de Janeiro 4, place Jussieu - 75252 P.O. Box 68504 - 21945-970 Paris Cedex 05 - France Rio de Janeiro - RJ - Brasil
ABSTRACT The IP Multicast architecture is completed by group ad- IP Multicast is facing a slow take-off although it is a hotly dressing and routing protocols. A multicast group is iden- debated topic since more than a decade. Many reasons are tified by a class-D IP address which is not related to any responsible for this status. Hence, the Internet is likely to topological information, as opposed to the hierarchical uni- be organized with both unicast and multicast enabled net- cast addressing model. Therefore, multicast address alloca- works. Thus, it is of utmost importance to design protocols tion is complicated and multicast forwarding state is diffi- that allow the progressive deployment of the multicast ser- cult to aggregate. Currently, there is no scalable solution vice by supporting unicast clouds. This paper proposes HBH to inter-domain multicast routing. The approach used is to (Hop-By-Hop multicast routing protocol). HBH adopts the connect different domains through MBGP (Multiprotocol source-specific channel abstraction to simplify address allo- Extensions to BGP)[2] and MSDP (Multicast Source Dis- cation and implements data distribution using recursive uni- covery Protocol)[18]. MBGP is used to announce differ- cast trees, which allow the transparent support of unicast- ent unicast and multicast-capable routes whereas MSDP is only routers. Additionally, HBH is original because its tree able to exchange active source information among the differ- construction algorithm takes into account the unicast rout- ent domains. The configuration complexity of this solution ing asymmetries. As most multicast routing protocols rely works against multicast deployment. On the other hand, on the unicast infrastructure, these asymmetries impact the backbone operators are currently overprovisioning their net- structure of the multicast trees. We show through simula- works so they have little interest in using multicast. tion that HBH outperforms other multicast routing proto- Nevertheless, ISPs (Internet Service Providers) could be cols in terms of the delay experienced by the receivers and interested in multicast to face the increasing demand for the bandwidth consumption of the multicast trees. network resources and content distribution. As a conse- quence, the Internet is likely to be organized with both uni- cast and multicast enabled networks. Therefore, it is of 1. INTRODUCTION utmost importance to design protocols that allow the pro- IP Multicast is facing a slow take-off although it is a hotly gressive deployment of the multicast service by supporting debated topic since more than a decade. Many reasons are unicast clouds. responsible for this status. The IP Multicast architecture Different solutions that simplify the multicast service by is composed of a service model that defines a group as an reducing the distribution model were proposed [8]. EX- open conversation from M sources to N receivers, an ad- PRESS [16] restricts the multicast conversation to 1toN dressing scheme based on IP class-D addresses, and routing (the channel abstraction), simplifying address allocation and protocols. In IP Multicast any host can send to a multicast data distribution, and still covering most of the current mul- group and any host can join it and receive data [5]. The IP ticast applications. The source-specific multicast service, Unicast service model is also completely open, but the po- currently being standardized at the IETF (Internet Engi- tential burden caused by unauthorized senders is amplified neering Task Force), can be implemented by Version 3 of by the group size in multicast. IGMP (Internet Group Management Protocol)[4] and by a modified version of PIM-SM (Protocol Independent Multi- ∗ This work was sponsored by FUJB, CNPq, CAPES, cast - Sparse Mode)[11], named PIM-SSM [3]. Neverthe- COFECUB, and IST Project GCAP N0 1999-10504. less, source-specific multicast does not allow the progressive deployment of the multicast service. Currently, the only alternative is to use tunnels to go through unicast-only net- works. There is some work in progress specific to multi- Permission to make digital or hard copies of all or part of this work for cast tunnelling. One such mechanism is the UDP Multi- personal or classroom use is granted without fee provided that copies are cast Tunneling Protocol (UMTP)[13]. UMTP encapsulates not made or distributed for pro£t or commercial advantage and that copies UDP multicast datagrams inside UDP unicast datagrams, bear this notice and the full citation on the £rst page. To copy otherwise, to so it can be implemented as a user-level process at end- republish, to post on servers or to redistribute to lists, requires prior speci£c hosts. The work in [14, 17] propose different mechanisms permission and/or a fee. SIGCOMM’01, August 27-31, 2001, San Diego, California, USA.. to automate the generation of UMTP tunnels. Automatic Copyright 2001 ACM 1-58113-411-8/01/0008 ...$5.00.
249
Multicast Tunnelling (AMT)[22] is an alternative scheme multicast trees, the majority of routers simply forward pack- that does not rely on UDP, it provides tunneling capabil- ets from one incoming interface to one outgoing interface, in ity through pseudo network interfaces that serve as default other words, the minority of routers are branching nodes. routes to multicast traffic. We do not propose a new au- Nevertheless, all multicast protocols keep per group infor- tomatic tunnelling scheme to connect the multicast-enabled mation in all routers of the multicast tree. Therefore the parts of the Internet, but instead proposes a new multicast idea is to separate multicast routing information in two ta- routing protocol that inherently supports unicast routers. bles: a Multicast Control Table (MCT) that is stored in Additionally, the protocol design takes into account the uni- the control plane and a Multicast Forwarding Table (MFT) cast routing asymmetries that may affect the structure of the installed in the data plane. Non-branching routers simply multicast distribution tree, especially if unicast-only routers keep group information in their MCT, as branching nodes are present. keep MFT entries which are used to recursively create packet The ability to transparently support unicast routers is the copies as to reach all group members. main motivation of the Hop-By-Hop multicast routing pro- REUNITE identifies a conversation by a .dst. RB cre- EXPRESS [16] provides a simple solution to the multicast ates one packet copy for each receiver in its MFT (the des- address allocation problem, introducing the channel abstrac- tination address of each packet copy is set to the receiver’s tion that reduces the multicast conversation from MtoNto unicast address). The original packet is also forwarded to 1toN. A channel is identified by the pair
250
(a) HBH tree. (b) REUNITE tree.
Figure 1: Data distribution in the recursive unicast approach.
2.3 The risks of asymmetric routing source to a receiver follow the unicast route used to go from Asymmetric routing means that the unicast path from A the receiver to the source. If these paths have different char- to B may differ from the path from B to A.IntheInternet, acteristics, e.g. different delays, the use of the reverse SPT it may be due to different reasons [20]. The simplest case may be problematic to QoS deployment. The ability to con- is that of asymmetric or unidirectional links (e.g., ADSL struct Shortest-Path Trees is therefore advantageous for a lines or satellite links). There are also less obvious sources multicast routing protocol. of asymmetric routes: routing misconfiguration and routes REUNITE differs from previous routing protocols because intentionally configured asymmetric. One such mechanism it potentially constructs SPTs. (MOSPF - Multicast Open is known as ”hot-potato routing” and is used because of Shortest Path First [19] is the only Internet protocol that economical reasons. For example, suppose two ISPs, A and constructs SPTs.) This is possible because the tree mes- B, that both provide connectivity through the US territory. sages that travel from the source to the destination nodes Traffic generated at the East Coast in A’s network, and install forwarding state and not the join messages that fol- destined to a customer in the West Coast connected to B low the inverse direction. Nevertheless, REUNITE may fail will be routed to B’s network as soon as possible, i.e., in a to construct shortest-path branches in the presence of uni- peering point located at the East Coast. This way, A avoids cast routing asymmetries. A second undesirable behavior using its own links to cross the country since these links are of REUNITE is that the route for one receiver may change a scarce resource. On the other direction, B uses the same after the departure of another receiver. This is undesirable strategy causing routes between A and B to be asymmetric. if some QoS mechanism is to be implemented. Real routing measurements have shown that the percent- Figure 2 illustrates the tree construction mechanism of age of asymmetric routes in the Internet is high. The anal- REUNITE with an example where it fails to construct a ysis in [20] evaluated about 10,000 pairs of sites. Only ma- SPT. Suppose the unicast routes: r1 → R2 → R1 → S ; jor routing asymmetries were considered, where the virtual S → R1 → R3 → r1 ; r2 → R3 → R1 → S ; S → R4 → r2. paths differ by one city or AS (Autonomous System). About Suppose the following events: r1 joins and
251
Figure 2: REUNITE’s tree construction mechanism.
sending tree(S, r1) messages to r1 (in unicast). These tree addressed to r1 will stop soon, so the tree portion based on messages install soft-state for .dst = r1 become stale as the their MCT. Now r2 joins the group. The join(S, r2) travels marked tree travels down the tree. At non-branching nodes, in the direction of S reaching the tree at R3. R3 drops the the reception of a stale tree(S, r1) causes the destruction of join(S, r2), creates a MFT with r1 as dst, adds r2 to any r1 MCT entries. Consequently, join(S, r2) messages are MFT,andremoves is stale) and a branching node and will consequently forward tree(S, r2) reach S. r2 now joins to the group (addressed to r1) are duplicated at R3 and ad- is destroyed (Figure 2(d)). Now, r2 receives data through dressed to r2. Subsequent join messages sent by r1 and r2 the shortest-path from S. refresh the MFT entries at S and R3 respectively. Asymmetric routing may also lead REUNITE to unneeded 2 In this configuration, r1 receives data from S through the packet duplications on certain links. Figure 3 gives an ex- shortest-path, but not r2. Because the unicast routes be- ample. The first receiver, r1, sends a join(S, r1) that follows tween S and r2 are asymmetric and because R3 intercepts the path r1 → R4 → R2 → R1 → S.Thetree(S, r1)mes- join(S, r2), data follows the path S → R1 → R3 → r2,the sages follow the route S → R1 → R6 → R4 → r1. Suppose same as tree messages from S down to r2 (Figure 2(a)). now that r2 joins and that join(S, r2) follows r2 → R5 → MCT and MFT states are soft. Receivers periodically R3 → R1 → S.Thetree(S, r1) (produced by S)andthe send join(S, ri) messages and the source periodically multi- tree(S, r2)(createdatR1) both traverse the link R1-R6.As casts a tree(S, ri) message. The receiver simply stops send- R6 does not receive join messages from these receivers, it is ing join messages to leave the channel. When the tree struc- not identified as a branching node. S creates data packets ture is stable, a tree(S, ri) message refreshes the ri MCT to r1 and R1 creates packets to r2.Sothereistwopacket entries and the MFT.dst = ri entries down the tree. The copies on the link R1-R6. join(S, rj ) messages refresh the rj entry in the MFT of the Consequently, the cost (the number of packet copies in the node where rj joined (in Figure 2, join(S, r1) refreshes network) of a REUNITE tree may be larger than that of a the r1 entry in S’s MFT and join(S, r2) refreshes the r2 en- source tree constructed by a classic protocol as PIM-SM try in R3’s MFT). (Protocol Independent Multicast - Sparse Mode)[9], since r1 join S, r1 Now leaves the group: it stops sending ( )mes- 2 sages. As the r1 entry in S’s MFT is not refreshed, after the In fact, this possibility also exists when the network has pure unicast routers or when the REUNITE router is over- expiration of timer t1 the r1 entry becomes stale. A second r loaded. In both cases, the branching node must migrate to timer, t2, is created and will eventually destroy the 1 en- another router and may cause packet duplications in some try. As r1 is stale, S now sends marked tree(S, r1) messages links. For a more detailed description, the reader is referred (Figure2(b)). The marked tree(S, r1) means that data flow to [21].
252
cause route changes to the remaining receivers, as for r2 in the example of Figure 2. This is avoided in HBH.
3.1 Tree management in HBH HBH has three message types: join, tree,andfusion. Join messages are periodically unicast by the receivers in the direction of the source and refresh the forwarding state (MFT entry) at the router where the receiver joined. A branching router “joins” the group itself at the next up- stream branching router. Thus the join messages may be intercepted by the branching nodes which sign themselves join messages. The source periodically multicasts a tree message that refreshes the rest of the tree structure. Fusion messages are sent by potential branching routers and con- struct the distribution tree together with the tree messages. Each HBH router in S’s distribution tree has either a MCT or a MFT. A non-branching node in S’s distribution tree has a MCT.MCT has one single Figure 3: Packet duplication due to asymmetric entry to which two timers are associated, t1 and t2.Atthe routes in REUNITE. expiration of t1 the MCT becomes stale and at the expira- tion of t2 the MCT is destroyed. A branching node in S’s distribution tree has a MFT. < the RPF (Reverse Path Forwarding) algorithm ensures one Two timers, t1 and t2, are associated to each entry in MFT S> unique packet copy over each network link. .Whent1 times out the MFT entry becomes stale and it The next section describes HBH protocol functioning and is destroyed when t2 expires. In HBH, a stale entry is used tree how its tree construction mechanism is able to cope with the for data forwarding but produces no downstream mes- problems due to asymmetric unicast routing. sage. A MFT entry in HBH can also be marked.Amarked entry is used to forward tree messages but not for data for- warding. The Appendix A gives a detailed description of the 3. HOP-BY-HOP MULTICAST PROTOCOL message processing rules of HBH. The basic ideas are: the HBH has a tree construction algorithm that is able to bet- first join issued by a receiver is never intercepted, reaching ter treat the pathological cases due to asymmetric unicast the source; the tree messages are periodically multicast by routes. HBH uses two tables, one MCT and one MFT that the source; these are combined with fusion messages sent by have nearly the same function as in REUNITE. The differ- potential branching nodes to construct and refine the tree ence is that one entry table in HBH stores the address of a structure. next branching node instead of the address of a receiver (ex- We come back to the first example of Section 2.3 to show cepted the branching router nearest the receiver). The MFT how the tree management of HBH works. Figure 5 repeats has no dst entry. Data received by a branching router, HB, the scenario of Figure 2. r1 joins the multicast channel at has unicast destination address set to HB (in REUNITE S which starts sending tree(S, r1) messages. These mes- data is addressed to MFT.dst). This choice turns the sages create a MCT containing r1 at H1 and H3 (Fig- tree structure more stable than in REUNITE. A multicast ure 2(a)). When r2 joins the group by sending the first channel in HBH is identified by state at H4 (Figure allocation problem while being compatible with IP Multi- 5(b)). Both receivers are connected to the source through cast. Therefore HBH can support IP Multicast clouds as the shortest-path. leaves of the distribution tree. Suppose now that r3 (unicast routes: S → H1 → H3 → r3 HBH’s tree structure has the advantage of an enhanced and r3 → H3 → H1 → S) joins the channel. It sends stability of the table entries when compared to REUNITE. a join(S, r3)toS, which starts sending tree(S, r3)mes- The tradeoff is that in HBH each data packet received by a sages. As H1 receives two different tree messages, it sends a branching node produces n + 1 modified packet copies while fusion(S, r1,r3) to the source. The reception of the fusion in REUNITE it produces n modified packets. The tree man- causes S to mark the r1 and r3 entries in its MFT and to agement scheme of HBH minimizes the impact of member add H1 to it. In the same way as H1, H3 receives tree(S, r1) departures in the tree structure. This is possible because the and tree(S, r3) messages and thus send a fusion(S, r1,r3)to MFT receiver entry is located at the branching node near- the source (Figure 5(c)). H3’s MFT now contains r1 and r3. est the receiver. For example, the departure of r1 in Figure Subsequent join(S, r1) messages are intercepted by H1 and 4 has a greater impact in the tree structure of REUNITE refresh the r1 marked entry in H1’s MFT. The join(S, r3) than in that of HBH. In the worst case, HBH may need one messages refresh the r3 MFT entry at H3. S sends data more change than REUNITE (it happens when a branching addressed to H1, that sends it addressed to H3. H3 sends node becomes a non-branching one, e.g. after the departure copies to r1 and r3. Subsequently, as S receives no more of r8). In this example routes are symmetric so there is no join(S, r1) neither join(S, r3) messages, its corresponding route changes for other members when a member leaves the MFT entries are destroyed. The final structure is shown group. Nevertheless, tree reconfiguration in REUNITE may in Figure 5(d). In this way, HBH is able to use the good
253
(a) Tree reconfiguration in REUNITE. (b) Tree reconfiguration in HBH.
Figure 4: Comparison of tree reconfiguration after member departure.
Figure 5: HBH’s tree construction mechanism.
254
branching point to the distribution tree. The problem of 4.2 Results Figure 3 is simply resolved through the transmission of a We compared HBH to REUNITE and two classical mul- fusion(S, r1,r2)fromH6 upstream to the source, similarly ticast approaches that are available in NS. NS has a multi- to the example just presented. cast routing protocol that is able to construct shared trees and source trees with the same structure as the trees con- structed by the PIM-SM protocol. The difference is that 4. PERFORMANCE ANALYSIS NS’s implementation is centralized and the change from the shared tree to the source tree is realized through an explicit We used NS (Network Simulator)[10] to simulate HBH. command, and not automatically as in the original PIM- Our objectives were to experiment HBH’s tree mechanisms SM [9]. Therefore, PIM-SM in our simulations refers to a as well as to compare HBH and REUNITE through the anal- protocol that constructs exclusively shared trees, whereas ysis of the constructed trees. We analyzed the average delay PIM-SS is a protocol that only constructs source trees. The experienced by all the receivers of the group and the number tree structure of PIM-SS is the same as that of PIM-SSM of copies of the same packet that are transmitted to reach [3], i.e., a reverse SPT. In addition to HBH, we implemented all receivers. REUNITE according to [21]. All routers implement the mul- ticast service in our experiments. 4.1 Simulation scenario The first topology used in our simulations is shown in Figure 6. This topology is typical of a large ISP’s network [1]. Without loss of generality, we suppose that only one Tree cost receiver is connected to each node in the topology. The 110 presence of one or many receivers attached to a border router 100 PIM−SM through IGMP [12] does not influence the cost of the tree, so PIM−SS 90 REUNITE we do not consider the aggregation provided by the multicast HBH service at the local network level. Nodes 0 to 17 in Figure 80 6 are routers whereas nodes 18 to 35 are potential receivers 70 of the multicast channel. We have also simulated a random- generated topology with 50 nodes and higher connectivity 60 (8.6 versus 3.3). 50
Number of packet copies 40
30
20 2 4 6 8 10 12 14 16 Number of receivers
(a) ISP topology.
Tree cost 350 PIM-SM PIM-SS 300 REUNITE HBH 250
200
150 Number of packet copies 100
Figure 6: The ISP topology. 50 5 10 15 20 25 30 35 40 45 Number of receivers
We associate two costs, c(n1,n2)andc(n2,n1), to link n1- (b) 50-node random topology. n2. Each cost is an integer randomly chosen in the interval [1, 10]. Simulations consider one multicast group from 1 to N where node 18 is fixed as source. A variable number Figure 7: Average number of packet copies. of randomly chosen receivers join the channel. For each group size we realized 500 simulation runs per protocol. The plotted results are the average of the 500 experiments.
255
4.2.1 Tree cost Figure 8(a) shows two unexpected results. First, PIM- We first evaluated the cost of the trees constructed by the SM performs better that PIM-SS in terms of delay for the different multicast routing protocols. We define the cost of ISP topology (in other words, the shared trees have a bet- a tree as the number of copies of the same packet that are ter delay performance than the source trees). This fact is transmitted in the network links. Therefore, the tree cost explained because PIM-SS tree is a reverse SPT and not a is different from the number of links in the tree since the SPT. So delay is not minimized. Delay is not minimized recursive unicast technique may send more than one copy either in the shared tree constructed by PIM-SM. But in of the same packet over a specific link. This may be due the shared tree, the paths from the source to the different to the network’s routing asymmetries (as shown is Section receivers all have one common portion, namely, the path 2.3) but also to unicast routers inside the network that are between the source and the RP. As data is encapsulated in not able to be branching nodes. In this case, the location unicast between the source and the RP, delay is minimized of a branching node may not be the ideal. Nevertheless, as between the source and the RP. Consequently, paths in the in our experiments all routers are multicast capable, extra PIM-SM tree have two parts: from the source to the RP packet copies are always due to routing asymmetries. where delay is minimized and from the RP to the receiver Figure 7 shows the average cost of the multicast trees where it is not minimized since it is a reverse shortest path. constructed by the different protocols as the number of re- This explains the advantage of PIM-SM over PIM-SS. The ceivers varies. For the ISP topology, PIM-SM constructs the same was not observed for the 50-node topology because this trees with the highest cost in most cases. This result was topology is larger and has a higher connectivity. Therefore expected since PIM-SM constructs shared trees. As we sim- going through the RP is likely to result in a longer path than ulated the distribution from one source to many receivers, going directly from the source to the receiver. The expected the utilization of a shared tree is disadvantageous since the result is observed, the shared tree having the worst delay tree is centered on a rendez-vous point (RP). With a high performance in this case. probability this tree has a higher cost than the equivalent The second important remark for the ISP topology is that source tree. HBH and PIM-SS construct the cheapest trees. the effect of the network asymmetries in the quality of RE- This result is expected since PIM-SS constructs source trees UNITE trees may be strong, as REUNITE performed worse based on the RPF algorithm, which guarantees that at the than PIM-SM when the receiver set is large. REUNITE per- maximum one copy of the same packet is transmitted at forms better than PIM-SM in the 50-node topology, as this each link, and that each receiver is connected to the source topology has a higher connectivity. trough the reverse shortest-path. HBH performs similar to The delay performance of HBH is better than that of RE- PIM-SS because in HBH each receiver is connected to the UNITE for all group sizes, in both topologies. The advan- source through the shortest path. Using this path or the tage becomes larger as the number of receivers grows, being reverse shortest path does not influence tree cost. of 14% in average for the ISP topology. The absolute values The REUNITE curves in Figure 7 demonstrate that the for the 50-node topology are smaller as this topology has a tree construction mechanism of REUNITE effectively suf- higher connectivity. On the other hand, the advantage ob- fers from the pathological cases produced by asymmetric tained by HBH over REUNITE for this topology is larger unicast routing, as we presented in Section 2.3. The phe- (30% in average). This is a consequence of its richer connec- nomenon is less frequent with a small number of receivers, tivity, as the routing protocol has more choices to construct since the probability that two receivers share the same link the distribution tree, and is consequently more vulnerable in the multicast tree is smaller. For the ISP topology, the to unicast routing asymmetries. problem is also less severe when the number of receivers is huge (receiver distribution is dense) since a big percent- 5. CONCLUSIONS age of network links is anyway used in the distribution tree. We presented HBH, a multicast routing protocol that im- Nevertheless, this is not the case for the 50-node topology. plements multicast distribution through recursive unicast This topology has a much higher connectivity, which means trees, idea originally proposed in REUNITE [21]. HBH al- that a smaller percentage of network links is used. In this lows the incremental deployment of the multicast service as topology HBH’s advantage increases with the group size. unicast routers inside the network are transparently sup- REUNITE also performs worse than PIM-SM shared trees ported. The observation of the strengths and weaknesses of as a consequence of badly placed branching nodes which lead REUNITE and EXPRESS directed the design of HBH. The to useless packet duplications. objectives of HBH are: The analysis of the HBH curve shows the enhanced effi- ciency of HBH’s tree construction mechanism. In terms of • to go through unicast clouds; tree cost, the advantage of HBH over REUNITE is as large as 5% for the ISP topology and 18% for the 50-node topol- • member departure should have minimum impact on ogy, in average over all group sizes. We conclude that HBH the tree structure; potentially provides a better bandwidth utilization than RE- • UNITE for asymmetric networks. to provide lower cost trees in the cases where RE- UNITE tree construction fails; 4.2.2 Delay • to guarantee that members receive data through the Figure 8 presents the average delay experienced by the shortest path from the source. receivers in the multicast channel for the same set of sim- ulations. The curves show that HBH is effectively able to HBH has an original tree management algorithm that is generate better quality routes than REUNITE in the pres- based on three messages. Join messages are periodically ence of asymmetric unicast routing. sent to the source by the receivers. The source periodically
256
produces tree messages that are multicast to the receivers. As the tree messages travels in the tree the intermediate nodes may generate fusion messages that are responsible of refining the tree structure. HBH is able to construct a Shortest-Path Tree even in the presence of asymmetric unicast routing. HBH also provides a better network utilization as it is able to construct recur- sive unicast trees minimizing packet duplication. This is an advantage if the network bandwidth is scarce. Addition- ally, HBH’s delay performance makes it a routing protocol adapted to applications that do not support large delays Receiver Average delay such as interactive ones. 18 The results obtained through simulation show that the PIM−SM PIM−SS unicast routing asymmetries affect the performance of the 17 REUNITE HBH multicast routing protocol. Additionally, HBH is a promis- 16 ing approach as its tree construction algorithm outperformed REUNITE in terms of the tree cost and the delay experi- 15 enced by the receivers. The advantage of HBH grows with 14 larger and more connected networks. Our future work in- cludes the formal definition of the interface between HBH 13
Delay (time units) and classical IP Multicast, and to study the possibility of 12 including QoS parameters inside HBH’s tree construction algorithm. 11
10 2 4 6 8 10 12 14 16 Number of receivers 6. ACKNOWLEDGMENTS We insist to express our sincere gratitude to Supratik (a) ISP topology. Bhattacharyya (Sprint Labs.), Mark Handley (ACIRI), Luigi Rizzo (Univ. of Pisa), and Lorenzo Vicisano (Cisco Systems) for their constructive comments on this work, as well as the SIGCOMM reviewers for their insightful remarks. Receiver average delay 16 7. REFERENCES 14 PIM-SM PIM-SS [1] G. Apostolopoulos, R. Guerin, S. Kamat, and S. K. 12 REUNITE Tripathi. Quality of service based routing: A HBH performance perspective. In ACM SIGCOMM’98, 10 pages 17–28, Sept. 1998. 8 [2] T. Bates, R. Chandra, D. Katz, and Y. Rekhter. 6 Multiprotocol Extensions for BGP-4. RFC 2283, Feb. Delay (time units) 1998. 4 [3] S. Bhattacharyya, C. Diot, L. Giuliano, R. Rockell, 2 J. Meylor, D. Meyer, G. Shepherd, and B. Haberman. An Overview of Source-Specific Multicast (SSM) 0 5 10 15 20 25 30 35 40 45 Deployment, May 2001. Work in progress: Number of receivers draft-ietf-ssm-overview-00.txt. [4] B. Cain, S. Deering, W. Fenner, I. Kouvelas, and (b) 50-node random topology. A. Thyagarajan. Internet Group Management Protocol, Version 3, Mar. 2001. Work in progress: draft-ietf-idmr-igmp-v3-07.txt. Figure 8: Average delay experienced by the re- [5] S. Deering. Host Extensions for IP Multicasting.RFC ceivers. 1112, Aug. 1989. [6] S. Deering, D. L. Estrin, D. Farinacci, V. Jacobson, C.-G. Liu, and L. Mei. The PIM architecture for wide-area multicast routing. IEEE/ACM Transactions on Networking, 4(2):153–162, Apr. 1996. [7] C. Diot, W. Dabbous, and J. Crowcroft. Multipoint communication: A survey of protocols, functions and mechanisms. IEEE Journal on Selected Areas in Communications, 15(3):277–290, Apr. 1997. [8] C. Diot, B. N. Levine, B. Liles, H. Kassem, and D. Balensiefen. Deployment issues for the IP multicast
257
service and architecture. IEEE Network, pages 78–88, Join message (Figure 9(a)) - When router B receives a Jan. 2000. join(S, R), it should forward this message unchanged if B [9]D.Estrin,D.Farinacci,A.Helmy,D.Thaler, has no MFT (1) or if R is not in B’s MFT (2). Only if B’s S. Deering, M. Handley, V. Jacobson, C. Liu, MFT has a R entry, B intercepts the join(S, R) and sends a P. Sharma, and L. Wei. Protocol Independent join(S, B) afterwards. It means that B is a branching node Multicast-Sparse Mode (PIM-SM): Protocol of the channel )(5). Accelerating the Deployment of Multicast Using If R was already present in B’s MCT, nothing has changed Automatic Tunneling , Feb. 2001. Work in progress: and B simply refreshes its MCT (6). If R is not present draft-finlayson-mboned-autotunneling-00.txt. in the MCT, then maybe the MCT is stale in which case [15] S. Hanks, T. Li, D. Farinacci, and P. Traina. Generic R replacesthepreviousMCTentry,ortheMCTisupto Routing Encapsulation (GRE). RFC 1701, Oct. 1994. date which means that there is a second receiver that will [16] H. W. Holbrook and D. R. Cheriton. IP multicast receive data through B,soB becomes a branching node. channels: EXPRESS support for large-scale This implies the creation of a MFT, the destruction of the single-source applications. In ACM SIGCOMM’99, MCT, and a fusion message to be sent upstream (8). The Sept. 1999. fusion messages produced by B contain all the nodes that [17] P. Liefooghe and M. Goossens. An architecture for B maintains in its MFT - the nodes for which B is branch- seamless access to multicast content. In IEEE ing node. Conference on Local Computer Networks, Nov. 2000. [18] D. Meyer (Editor) and B. Fenner (Editor). Multicast Fusion message (Figure 9(b)) - Suppose router B receives Source Discovery Protocol (MSDP), May 2001. Work a fusion(S, R, ...Rn)fromnodeBp. If the message is not in progress: draft-ietf-msdp-spec-10.txt. addressed to B,thenB simply forwards it upstream (1). If [19] J. Moy. Multicast Extensions to OSPF. RFC 1584, the message is addressed to B,thenB marks the receiver Mar. 1994. entries in its MFT that are listed in the fusion message [20] V. Paxson. End-to-end routing behavior in the (2). A marked entry in the MFT is used to tree message internet. IEEE/ACM Transactions on Networking, forwarding but not for data distribution. Bp is added to B’s 5(5):601–615, Oct. 1997. MFT if it was not previously present. In addition, Bp’s t1 [21] I. Stoica, T. S. E. Ng, and H. Zhang. REUNITE: A timer is expired - Bp becomes stale (3). Consequently, Bp recursive unicast approach to multicast. In IEEE will be used for data forwarding, but not for tree message INFOCOM’2000, Mar. 2000. forwarding. If Bp was already present in B’s MFT, then B [22] D. Thaler, M. Talwar, L. Vicisano, and D. Ooms. IPv4 p’s t2 timer is refreshed (it avoids the destruction of the B Automatic Multicast Without Explicit Tunnels,Feb. p entry), but its t1 timer is kept expired (4). B fusion 2001. Work in progress: If afterwards p (the node that produced the for R, ...R join draft-ietf-mboned-auto-multicast-00.txt. n) receives the messages produced by any of R, ...Rn, it intercepts them and send a join(S, Bp) upstream. [23] D. Waitzman, C. Partridge, and S. Deering. Distance In this case the R, ...Rn entries in B’s MFT will eventually Vector Multicast Routing Protocol. RFC 1075, Nov. timeout and be destroyed, while the Bp entry in B’s MFT 1988. is refreshed by the join(S, Bp). If Bp does not receive join messages from R, ...Rn, the emission of fusion messages APPENDIX continues since there is another node upper in the tree that A. MESSAGE PROCESSING IN HBH receives the join(S, R, ...Rn) and periodically produce the tree(S, R, ...Rn) messages to these receivers. Nevertheless, Figure 9 presents the processing rules of the three message this node will not forward data to these receivers, but to types used by HBH to construct the distribution tree. Each Bp instead since the receivers’ entries are marked. Bp is receiver r periodically sends a join(S, r) in unicast to the responsible for data duplication. It is in this way that HBH source. The source periodically multicasts a tree message is able to manage the second asymmetry problem presented for each
258
(a) Join message. (b) Fusion message.
(c) Tree message.
Figure 9: Message processing in HBH.
259