compared the cost with that of overlay multicast. Index TermsâMulticast, static .... DNS via the domain names statically assigned to multi- cast addresses. Simple ...
MUST: Multicast Using Static Trees Jiang Li Department of Systems and Computer Science Howard University Washington, DC 20059
Abstract—IP multicast has been known to have deployment difficulties. Among many contributing factors, the model per se is probably one of the most critical. Overlay multicast does not solve all the problems either. We therefore proposed a new multicast architecture named MUST, inspired by previous efforts. In essence, the architecture uses an overlay network to interconnect statically configured IP multicast trees to create the data paths for improvised multicast groups. While being incrementally deployed, it evolves towards higher efficiency. Although the model looks similar to some previous ones, it actually carries critical differences. In this paper, we described the model in detail, theoretically estimated its cost, and compared the cost with that of overlay multicast. Index Terms—Multicast, static tree.
I. I NTRODUCTION With its high efficiency for group communication, IP multicast is of great interest. The good news is, IP multicast is available on Internet2. The bad news is, Internet2 is still far from reaching the general public. In fact, as of today, most of the Internet2 members are academic institutions [2]. Given the significant differences between academic computer networks and commercial ones (like the discrepancies between NSFNET in early ages and the current Internet), even if IP multicast can become a successful story on Internet2, it is not clear how many commodity ISPs to what extent would like to adopt that. Such pessimism is not unreasonable. It has been almost two decades since the proposition of IP multicast [1]. Study [3], [4] has shown that the causes are manifold, such as the challenges of group management, the difficulty of routing scalability and so on. That the research on IP multicast has subsided in recent years reflects the frustration. As an alternative to IP multicast, overlay multicast (a.k.a. application layer multicast, end system multicast, or peer-to-peer multicast) has been proposed. Early examples are ESM [5] and Yoid [6]. Nowadays there are already quite a few applications, e.g. PPlive [7]. Since it is implemented on the application layer and does
not require any changes to the Internet core, it is a truly applaudable work-around. However, it has intrinsic limitations on performance (detailed in Section II). Knowing the drawbacks of both major multicast architectures, we are proposing another one. Its essence is to use statically configured multicast trees as build blocks for multicast groups. For a randomly formed multicast group, an overlay network will be used to send data to the roots of an ensemble of selected static multicast trees. From the root routers, data are forwarded downstream via IP multicast. As long as the leaves in the ensemble cover the recipient set, packets will be disseminated effectively. Figure 1 helps explain the idea. For clear reasons, we named the architecture Multicast Using Static Trees (MUST).
Y
C
Y
D
X
C
X
A
B
D Static tree 2
Static tree 2
A
B Source
Static tree 1
Static tree 1
(a)
(b)
Fig. 1. An example of Multicast Using Static Trees: (a) A network with two tatic trees. (b) Multicast traffic from the source to the group of A,B,C,D using both static trees.
The MUST architecture has many promising and interesting features including but not limited to 1) incremental deployability, 2) evolvability, 3) natural support of policy-based administration, 4) straightforward multicast address allocation, 5) multicast address reuse and 6) support of domain names. Nevertheless, there are also many challenges. However, we believe that the advantages are more significant, as to be presented shortly. In the rest of the paper, we will first establish the base for MUST by checking previous work. The detailed model description follows, together with the analytical study of the cost of MUST compared with overlay multicast.
II. R ELATED W ORK The original IP multicast model [1] is a straightforward framework. When a group of hosts need to communicate with each other, a tree of routers is constructed dynamically to connect the group. A rich set of routing protocols have been proposed for multicast tree construction. Examples are DVMRP [8], MOSPF [9], PIM-DM [10], PIM-SM [11], and CBT [12], [13] for intra-domain routing, and MBGP [14] and BGMP [15] for inter-domain. In spite of that, many problems hinder the deployment of IP multicast. To maintain the multicast tree for a group, each router involved has to continuously update its forwarding states according to member joins and leaves. That makes it hard for a router to handle many groups, which is known as the routing scalability problem. Group management is also difficult. Any node can arbitrarily join and leave any group as well as multicast data. There are hardly any effective mechanisms to regulate their behaviors. More problems have been discussed by Diot [4] and Almeroth [3]. Great efforts have been made to improve the situation. In early nineties, Rajagopalan [16] and Ammar [17] suggested sending data to a subset of group members to ease the scalability problem. More recently, Cui et al [18] studied aggregated multicast, where routers in a transit domain maintain the states for a limited number of multicast trees. For all groups that traverse the domain, the packet forwarding within the domain is based on these trees. For the former solution, it is imaginable that when a group becomes large enough, the problems reemerge. For the latter, the problems remain outside the transit domain. In short, the problems are alleviated, but have not been solved radically. The most successful multicast model so far is overlay multicast (e.g. [5], [6], [19], [20]). The basic idea behind is peer-to-peer networking, where hosts relay the received data partially or completely to other ones via end-to-end unicast. As it does not require infrastructure updates, the deployment is hassle-free. Nonetheless, several inherent problems may prevent it from replacing IP multicast completely. First of all, the end-to-end delay may be too large, especially in a complex overlay network where forwarding chains tend to be long. Secondly, the overall output of relaying hosts have to be the same as the overall input. Given asymmetric link speeds in many cases (e.g. in residential access networks using DSL or cable), the throughput rate is limited. Moreover, there is clearly bandwidth waste, as many links carry the same packets for multiple times.
A hybrid approach [21] uses an overlay network to interconnect multicast groups in subnets capable of IP multicast. It is an attempt to make multicast universal, but leaves the problems of IP multicast unsolved within those subnets. The differences between the hybrid approach and our model are delicate but crucial. While the former has multicast trees formed in subnets on demand for certain groups, the latter has multicast trees statically configured that are not dedicated to any multicast groups. Without such differences, MUST would not have the many wonderful features. There is also an interesting scheme called Xcast [22]. A source inserts the unicast addresses of all the multicast group members into each packet. These addresses direct routers on replication and forwarding, and thus free them from keeping multicast forwarding states. Unfortunately, not many addresses can fit into a packet. Yet another effort is REUNITE [23], where routers at multicast tree branching points replicate packets and forward them toward next branching point router by putting the router’s (unicast) address in the destination field, which therefore does not bother other routers. The problem is, the forwarding states are still dynamically maintained following the concept of IP multicast. Although load balancing is a feature of REUNITE, the total number of forwarding states in the whole network remains significant, limiting the overall scalability. Last but not least, there have been some schemes that look very similar to ours in some way. Static multicast [24], albeit with a close name, actually only talks about enabling the lookup of cores or rendezvous points using DNS via the domain names statically assigned to multicast addresses. Simple multicast [25] is close to MUST in nature. It uses the combination of the unicast address of a router and a multicast address to identify a multicast group. Data are also sent to this router first and then multicast to the group from there. Its difference from MUST, though, is that the tree for a group is dynamically created and maintained as in IP multicast. MARS-based ATM multicasting [26] uses a registrar server to keep the membership information for virtual circuit maintenance. The concept of registrar servers is the same as that in MUST, but the architecture does not have the notion of pre-configuring static multicast trees. In short, existing multicast models have drawbacks without clear solutions yet. It is time for another one. III. T HE MUST A RCHITECTURE Our architecture can find its root in most of the previous work. Its operations for a multicast group can
be briefed as follows: 1) Some static multicast trees are built in advance, each identified by the unicast address of its root and a multicast address. The address pairs may be mapped to domain names. (Section III-A,III-F,III-G) 2) A registrar server keeps track of the tree identities as reported by the member hosts and provides admission control. (Section III-B,III-K) 3) The data source selects certain static trees after consulting the registrar server, and sends data to them via an overlay network. Data are multicast within each tree. (Section III-C,III-D,III-E) A. Static Tree Construction A static tree is simply a IP multicast tree. However, the multicast forwarding states on the routers for the tree are fixed. Each static tree is assigned a multicast address. When packets destined to the address reach the root, they will be forwarded to all the end hosts in the tree using IP multicast. It is possible that there are multiple different static trees within a subnet. Setting up a static tree is independent of the rest of the Internet, as IP multicast is contained only in the tree. The configuration can be done manually by network administrators. The process can also be automated. Protocols can be designed for hosts to request the construction of a static tree within a subnet. On this note, existing multicast routing protocols can be leveraged. However, once a multicast tree has been built, it is expected to remain constant over a relatively long period. The unicast of the root router and the assigned multicast address comprise the identity of a static tree. Once a static tree is built, the identity should be made available to all of its leaf hosts. The leaf hosts can later reveal the information to other hosts for the latter to do multicast. Notice that as a special case, each end host is a singlenode static tree. The multicast address assigned to the tree happens to the same as the unicast address of the end host as the root, as no IP multicast is actually needed. B. Group Management For each multicast session among a multicast group, a registrar server is used to keep track of group membership and the static tree information of group members. Whenever a host enters or quits the session, it needs to contact the registrar server to sign on or off. It should also send the registrar server the identifies of the static trees it is in. Apparently, care must be given to leavings
without informing the register server. For resilience, a multicast session may use multiple registrar servers. The tree identities kept in the registrar server will be passed to multicast sources as needed. To stay updated when sending data, source hosts can periodically ping the registrar server, or have the server send update information to them upon changes. C. Data Dissemination Using Static Trees To send packets to a multicast group, a source host first selects a set of static trees, based on the information obtained from the registrar server. The overall leaves in these trees should cover the recipients. The source then unicast packets to the root routers via tunneling, where packets sent to a tree have the tree’s multicast address as their destination. As a simple example, in Figure 1, two routers X and Y are configured in advance. Using IP multicast, X can forward traffic to A and B, Y to C and D. When the group of A, B, C and D is to be reached, the two trees rooted at X and Y respectively are selected. Data will be tunneled to X and Y, which in turn forward traffic downstream. Although not shown in the example, a static tree may certainly have multiple routers. The source host may or may not be responsbile for tunneling packets to all the root routers. If not, protocols are needed for it to coordinate with some member hosts so that they can relay packets to the rest of the roots. In other words, an overlay network can be built to interconnect all the involved static trees. Recall that each host is a single-node static tree. When all static trees selected for a multicast group are such kind, MUST is depreciated to overlay multicast. Therefore, the research on overlay multicast can be leveraged to study the challenges of building overlay networks among static trees. D. Receiving at End Hosts A static tree may be used in different multicast sessions simultaneously. Since all packets going to the static tree have the same destination address, a receiver needs to distinguish those in different sessions. For that purpose, packets can carry a port number, similar to that in TCP or UDP. A problem to be solved though, is how to avoid using the same ports for those multicast sessions in the same static tree, given that those sessions may use different registrar servers. If a source selects a set of static trees that cover more than the receipients, some hosts will receive packets they don’t need and can simply discard them.
E. Static Tree Selection As stated above, when a source host wants to reach a multicast group, in which the source may or may not be a member, it needs to choose a set of static trees. Ideally, the set of leaves in all the trees should equal that of the group members. However, it may not always be possible. More likely, the group member set will be a subset of the leaf set. In this case, packets may unnecessarily reach some hosts. However, that does not always result in higher traffic overall. As an extreme example, consider a multicast group of n hosts. Assume there is a static tree that covers n + 1 hosts including these n. Besides, as explained before, each host is a single-node static tree. In this case, using the (n + 1)-node static tree probably incurs much less traffic than using n single-node static trees, because the latter leverages IP multicast less and generates more duplicate packets. Evidently, it is challenging how to select the optimal set of static trees for a multicast group while considering all the tradeoffs. Nonetheless, we can benefit from the research on aggregated multicast, where the situation of the destination set being smaller than the reached set is called “leaking” [18]. Although the study was for transit domains, it can be extended for general subnets. To know which group member is in which static trees in order for selection, a source gathers the information from the registrar server for the multicast session, as explained in Section III-B. It is also possible for all group members to send their static tree information to the source directly, if there are only a small number of fixed sources such as in a TV broadcast session. After selecting a set of static trees, the source needs to guarantee that the exact same set is used during a multicast session. If the source itself is responsible for sending packets to all selected root routers, there is no problem. Otherwise, the source needs to designate a subset of group members as its proxies. If so, a protocol is needed for the source to detect and recover from proxy failures. The fact that there are usually multiple sources in a multicast group further complicates the situation. Finding a perfect solution is challenging, but again, the previous study on overlay multicast may help. Lastly, the join and leave actions by multicast group members can cause re-selection of static trees. Changing the static tree set incur abrupt changes to traffic flows and thus to (at least) short-term performance. It is another hard problem to decide how a source can react to the dynamics while not causing too much oscillations.
F. Addressing and Address Allocation In MUST, a multicast address is not associated with a multicast group, but with a static tree instead.1 Since a multicast group consists of the leaves in one or more static trees, it is bound to a dynamic set of addresses. To be exact, a multicast group is represented as a tuple (u1 , m1 , u2 , m2 , ..., un , mn , port), where ui and mi (1 ≤ i ≤ n, n ≥ 1) are respectively the root unicast address and the multicast address of the i-th selected static tree, and port is a port number. Clearly, the amount of multicast groups that can be supported in the Internet simultaneously is no longer restricted by the multicast address space. In fact, as there are so many combinations of ui , mi and port, the number is virtually infinite. There is a even more interesting feature for assigning multicast addresses to static trees. Recall that within a static tree, the forwarding of a multicast packet depends solely on its destination address. Therefore, in two nonoverlapping static trees, even if we assign the same multicast address to them, packet forwarding within each of them would still be correct. As the result, multicast addresses can be reused except for trees that overlap. The process of assigning addresses to static trees can mimic the practice for unicast addresses. An organization can apply for a block of multicast addresses from the Internet Assigned Number Authority (IANA), and use the addresses for the static trees set up later. MUST is also independent of IP versions. Moreover, two static trees may use different IP protocols, as long as each of them is consistent inside, and the source and proxies have the right support. G. Domain Names In traditional IP multicast, a multicast address corresponds to a random group. It does not make much sense to bind domain names to it. However, in MUST, the semantics of a multicast address is static (Section III-F). Binding domain names to a multicast address is more easily understandable. Nonetheless, for identification purposes, a multicast address is always used with a unicast address (of a root router). Therefore, a multicast domain name should be bound to a tuple of one unicast address and one multicast address, i.e. a domain name is a more human-friendly identity of a static tree. Just like in unicast, a static tree may have multiple domain names. It is also possible to bind a domain name to a fixed set of static tree identities as an extension. 1 It is possible that two multicast addresses are bound to two different static trees respectively, while the two trees have the same set of leaf hosts.
Domain names in place of addresses can be given to registrar servers by multicast session participants. A source can look up the extended DNS to obtain address information.
static trees do not overlap. Since it may not be always possible to satisfy the requirements, the extent of address aggregation is limited.
H. Address Aggregation
There are two levels of routing in MUST, one (called intra-tree routing) for constructing static trees, the other (called inter-tree routing) for selecting static trees for multicast sessions. Either level of routing can be either intra-domain or inter-domain. In MUST, inter-domain routing is well supported. If an instance of intra-tree routing is inter-domain, because tree configurations are static, it is easy for the administrators of the Autonomous System (AS) to manipulate the settings according to their policies. As for inter-domain inter-tree routing, because static tree selection is done by end hosts like in overlay multicast, it does not involve the Internet core (and thus not network administrators). The rest issues have been discussed in tree construction (Section III-A) and tree selection (Section III-E) respectively, and are therefore omitted here.
In traditional IP multicast, a multicast group consists of a random set of hosts in the Internet. Consequently, the multicast addresses in a routing table disperse over the whole address space. Address aggregation has been a difficult problem. In MUST, a routing table may have a much smaller address space. In the address allocation scheme just discussed in Section III-F, an organization can only use the granted block of multicast addresses for its static trees. Therefore, the address space used in the routing table is just the block and much smaller. Intuitively, it is more likely to find common address suffixes. The fact that static trees can be configured manually can also help. However, there are still a couple of complications that require serious considerations. Firstly, the closer a router is to hosts, the more static trees it may be included in, thus the more forwarding states it may contain, and the harder the address aggregation. Secondly, more correlations between addresses need to be taken care of. Consider three multicast routing tables, where Tp is the table on the parent router, T1 and T2 are that of the two separate children routers respectively. Let ap , a1 and a2 (ap 6= a1 6= a2 ) be a multicast address in Tp , T1 and T2 respectively. According to the definition of static tress in MUST, if a multicast address is in the routing table of a router, it must also in that of all the children routers (if any). Therefore, ap is also in T1 and T2 . Further assume that neither a1 nor a2 is in Tp , i.e. a1 and a2 are for two smaller static trees. To aggregate the routing entries for ap and a1 (a2 ) in T1 (T2 ) (given other conditions are satisfied), ap and a1 (a2 ) must have some common significant bits, the set of which denoted as Bp1 (Bp2 ). (In a set of addresses, we call a bit significant if it is not the same for all the addresses.) If Bp1 ∩ Bp2 = φ, that means the sets of significant bits used by a1 and a2 are not equal. However, an address only has a limited number of bits (e.g. 32 bits in IPv4). There are not many choices for different bit sets. In accordance, it is more likely that Bp1 ∩ Bp2 6= φ. We can then derive that a1 and a2 share some significant bits and have the same value for them. After generalizing the example, it can be noticed that for the purpose of address aggregation, such a condition is likely required to be true for the addresses assigned to multiple static trees, even if the
I. Routing
J. Scalability Once static trees have been set up, building a multicast group (by selecting static trees) for a multicast session does not require any more states on routers. Therefore, the number of multicast group supported in the Internet is no longer constrained by router resources, as in overlay networks. Within static trees, as the forwarding states on routers are under tight control (due to the way of configuring static trees), routers will not be overloaded by over-sized routing tables or excessive processing. The number and topology of static trees may affect the performance of multicast sessions, but that is a performance issue, which can be tackled via other means (e.g. better algorithms for tree selection). In short, MUST is expected to be well scalable. K. Security Considerations One common security concern in multicast is how to control the access to multicast groups. That can be fairly easy in MUST. Recall that a registrar server keeps all the member information for a multicast session. When a source needs to send packets to a multicast group, it has to obtain the member information from the registrar server to select static trees. At this point, its authenticity can be verified if necessary. On the other hand, if a host wants to join a multicast group, its static tree information has to be registered with the registrar server. Admission control can be performed during registration. A registrar
server can even force traffic to reach a node by keeping the static tree information of the node for a particular multicast session, if ever needed. On another note, one might argue that it could be dangerous for MUST to expose network details to end hosts, because sources are required to know the information of static tress. That should not be a concern. A static tree is only published as a tuple of a root router address and a multicast address. The topology of the static tree is not revealed. As to router addresses, in the current Interet, a hacker would simply use traceroute to figure out all router addresses he needs to attack, if he wants. L. Incremental Deployment, Performance and Evolution MUST is easy to start. The first level static trees, i.e. individual end hosts (as single-node static trees) (Section III-A), are already universally available. They are being exploited by a preliminary form of MUST, overlay multicast. After having some enhancements (e.g. introducing registrar servers, multicast domain names), we will have a solid base. In MUST, any static tree can be exploited independent of all others. If an organization, no matter how big or small, would like some of its hosts to be in multicast sessions often, it can set up static trees within the organization network for these hosts without being concerned with how other organizations set up their static trees. These trees can be accessed by hosts anywhere, subject to the organization’s firewall policy. Given such freedom, the adoption of the model may be encouraged. As more and more static trees are available, they can be used by source hosts to replace inefficient ones (e.g. singlenode trees) in their tree sets for multicast sessions, and eliminate more duplicate traffic incurred by overlaying. If so, the overall performance will keep improving. Static trees can start as small, totally up to the needs and capabilities of individual organizations. As needs and/or capabilities grow, an organization can upgrade several higher-level routers, link them with existing static tree routers, and enable larger static trees. Since all those routers at lower levels have been upgraded to support static trees, it will probably not be a problem just to introduce a few more forwarding states to them. At the time when demands become so great that static trees need to be built across multiple organizations, we believe plitical agreements won’t be hard to reach. Configurations will be relatively easy, as gradually growing demands have incrementally make the infrastructure in each organization upgraded.
Summarily, MUST deployment can be a demanddriven bottom-up process. The level of capabilities required for deployment match the scale of demands. Whenever a group of users need multicast, the network administration they are under has enough facility and capability to meet the needs. As the deployment broadens, multicast performance improves. These features render MUST deployment very prospective. IV. T HE S AVINGS OF MUST In order to obtain an approximate idea of how much advantage MUST has over overlay multicast, a brief analysis is provided below. We adopt self-similar trees [27] as the topology for the analysis, as it has been shown to be able to explain the power law of multicast2 [28] observed in experiments on real and generated network topologies, and it was also used for the cost analysis of overlay networks [29]. Self-similar trees are an extended form of complete K -ary trees. Given a K -ary tree of L levels (i.e. there are L links on the path from the root to any leave), a self-similar tree is obtained by adding xK (L−i)θ − 1 (θ > 0) unary nodes (nodes that have only one child) onto each link at level i, so that there are now xK (L−i)θ consecutive links between a node at level i − 1 and its original child node in the K -ary tree. As in [27], without loss of generality, we set x = 1. A K -ary tree is a self-similar tree with θ = 0. An example of a binary self-similar tree with θ = 1 and L = 3 is shown in Figure 2. In the discussion, we assume 0 ≤ θ < 1. All nodes in a self-similar tree correspond to routers. A node corresponding to a non-leaf router at the level l in the original K-ary tree without added nodes is called a level l braching router. N hosts (except the source host) are considered to attach to the leaf routers uniformly randomly, whereas the source host is attached to the root router. All hosts are the members of the multicast group in question. We will use the metric of cost to measure the benefit of MUST. To reach a set of hosts from a source, the cost is calculated by summing the number of flows incurred by the session on each link. We ignore the cost between hosts and routers. A. The Expected Cost of Overlay Multicast Let h be an integer value satisfying the following condition (the same as ρ in [29]) 2 Let L(m) be the average number of links in the multicast tree needed to reach m randomly chosen routers from a given source, and U be average number of links in a unicast path. L(m)/U = Θ0.8 .
Level 0 node
Unary node
Level 1 node Level 2 node Leaf node
Fig. 2. θ = 1.
A 3-level Binary Self-Similar Tree with Similarity Factor
2
L X
K (L−i)θ ≤
L X
K (L−i)θ
i=1
i=h+1
and thus &
1 K Lθ + 1 h = L − logK θ 2
'
³
1 − 1 − K −h
´N ¶
Ã
h P
K (L−i)θ −
i=1
+2
L P
³
L P
¡
cost on the link is thus µ
³
1 − 1 − K −i
K (L−i)θ
¢N ´
i=h+1
´N ¶
1 +
i−1 Y
(1 − pL−j )
j=h
Consider a branching router that is on the path from the source to at least one host. If it is the root of a static tree but is not an intermediate node in any other static trees, we need to add the overlay cost of the static tree to the total cost. A level h branching router is such simply with probability q(h) = pL−h , while a level i (h < i < L) one is such with probability q(i) = pL−i
i−1 Q
(1 −
j=h
pL−j ). The expected cost incurred by a level i (h ≤ i < L) branching router is therefore µ
³
q(i) 1 − 1 − K
−i
L ´N ¶ X
K (L−i)θ
j=i+1
Since no data are transferred out of any subtree rooted at a level h branching router, we need to subtract the corresponding cost from the total. At the end, the average cost of MUST on a singular subtree is
The average cost of overlay multicast is simply obtained by multiplying the formula above by K h .
µ
³
1− 1−K
B. The Expected Cost of MUST We assume that if a level l (h ≤ l < L) branching router is on the path from the source to at least one host,
(1 − pL−j ). The expected
j=h
!
i=h+1
K (L−i)θ+i−h 1 − 1 − K −i
i−1 Q
it is in a static tree is 1 −
If the closet common ancestor node of two hosts is at a level above h, instead of having one host to forward data to the other, the cost is smaller if the source sends data to the latter directly. Therefore, the paths between overlay neighbors are all contained in subtrees rooted at level h branching routers. If there are multiple hosts within such a subtree, data will be directly sent to one of them by the source, and then be passed between the hosts within this subtree. No data will be forwarded out of the subtree (we will refer to such subtrees as singular subtrees later). In addition, as proved in [29], to minimize the cost of an overlay network, a host should always only forward data to the other host with which it has the closest common ancestor node. Hence, in a singular subtree, if a link has at least one host downstream (one or more hops away), the cost on this link is at most 2 (1 for downstream, 1 for upstream). Each singular subtree has the following excepted cost, µ
a static tree rooted at the router exists with probability pL−l , and the static tree covers all and only the hosts in the subtree rooted at the same branching router. (In the following discussion, all static trees refer to this kind.) We call p the base probability of static trees. We also assume that static trees are rooted at up to the level h (defined in Section IV-A). Since inter-domain static trees are harder to set up, it is not an unreasonable assumption. In a static tree, each link contributes a unit cost for data transfer to the hosts within the tree. In addition, the cost (referred to as overlay cost) equal to the tree height is incurred for relaying data to a host outside the static tree. The cost contributed by the links outside static trees are considered in the same manner as in overlay multicast. Consider a link between a level i − 1 branching router and a level i one (h < i ≤ L). If the link is on the path from the source to at least one host, the probability that
·
−h
´N ¶
h L X X K (L−i)θ − K (L−i)θ i=1
i=h+1
µ
³
q(i) 1 − 1 − K
−i
L ´N ¶ X
0.5
K
L h X
K (L−i)θ+i−h
i=h+1
µ
³
· 1 − 1 − K −i
´N ¶
1 +
i−1 Y
θ = 0.01 θ = 0.06 θ = 0.11
(L−j)θ+i−h
j=i+1
i=h
+
(1 − pL−j )
Cost Saved by MUST over Overlay Multicast
+
L−1 X
0.4
0.3
0.2
0.1
j=h 0
C. Cost Comparison To have a rough idea of the advantages of MUST, some cost comparisons are done numerically based on the formulas given above. We used three different values (0.01,0.06,0.11) for the similarity factor θ after checking some previous cost analysis papers [27] [29]. Moreover, K = 10, L = 15. To make comparisons, we calculate cost saving, i.e. the ratio of the cost difference to the overlay multicast cost. Note that the optimal case of MUST is IP multicast, which has half as much cost as overlay multicast. Therefore, the cost saving is bounded by 0.5 (or 50 percent). Figure 3 shows the impact of the base probability of static trees on cost saving when the number of hosts (N ) is 0.01 percent of the number of edge routers (i.e. leaves in the self-similar trees). In accordance with the intuition, the saving increases with the base probability. Additionally, we observe that the saving is rather small until the base probability reaches 0.6 (where the saving is about 0.1 or 10 percent). After that, the saving grows rapidly until the base probability reaches 0,9, where the saving is very close to the optimum. Such observations suggest the possibility that until a certain level of deployment, people won’t see significant bandwidth saving by MUST. However, that is under the assumption of multicast member hosts being evenly scattered across the whole network. If member hosts are clustered, as shown in the next result, the situation could be improved. Another observation on this figure is that the self-similarity factor (θ) values (in the given range) lead to marginal performance variance. Approximately, larger θ means more links between branching routers, and therefore provide for higher MUST efficiency as MUST involves fewer branching routers. Figure 4 shows how host density affects the efficiency of MUST, where the base probability is fixed as 0.5. With hosts being evenly scattered, different host densities are achieved by changing the ratio of the number of hosts
0
0.1
0.2
0.3 0.4 0.5 0.6 0.7 The Base Probability of Static Trees (p)
0.8
0.9
1
Fig. 3. The Efficiency of MUST Grows with The Base Probability of Static Trees.
to the number of edge routers (from 10−11 to 1). As observed, the more concentrated the hosts are, the better MUST can perform. That is understandable because we assume that hosts close to each other have better chances of being covered by a static tree (which will probably also be the case in reality). 0.35
θ = 0.01 θ = 0.06 θ = 0.11
0.3 Cost Saved by MUST over Overlay Multicast
Again, the average cost of MUST is simply obtained by multiplying the formula above by K h .
0.25
0.2
0.15
0.1
0.05
0 1e-12
1e-10
1e-08
1e-06
0.0001
0.01
1
The Ratio of The Number of Hosts (N) to The Number of Edge Routers (KL)
Fig. 4. The Efficiency of MUST Grows with The Density of Hosts.
It could be a little bit disappointing to see that the maximum bandwidth saving by MUST is only 50%. However, remember that we used the least cost overlay trees for comparison. The saving could be more in practice. In addition, end-to-end delay is also expected to benefit from MUST significantly, which is another topic worth of study. Overall, the results above give us the first peek at MUST analytically. Nonetheless, to thoroughly understand its performance, much more and deeper research is definitely needed. V. C ONCLUSION We have described a new evolvable multicast architecture that already has a base in the current Internet to start on. Many interesting and promising features as well as challenges of this architecture have been shown,
although the disccusion is very brief and preliminary due to the space limit. We believe that the benefits outweigh the challenges, and the architecture is worth further exploration. R EFERENCES [1] S. Deering, “Multicast Routing in Internetworks and Extended LANs”, ACM Computer Communications Review, 1988, 18(4). [2] “Internet2 member list”, http://www.internet2.edu/resources /Internet2MembersList.PDF [3] K. Almeroth, “The Evolution of Multicast: From the MBone to Inter-Domain Multicast to Internet2 Deployment”, IEEE Network, 2000, 14: p. 10-20. 11. [4] C. Diot, et al., “Deployment Issues for the IP Multicast Service and Architecture”, IEEE Network, 2000, 14(1): p. 78-88. [5] Y.-h. Chu, S. G. Rao, and H. Zhang, “A Case for End System Multicast”, ACM SIGMETRICS, Santa Clara, CA, June 2000. [6] P. Francis, “Yoid: Extending the Internet Multicast Architecture”, ICIR, Berkeley, 2000. Available from: http://www.icir.org/yoid/ [7] PPLive. Available from: http://www.pplive.com [8] D. Waitzman, C. Partridge, and S. Deering, “RFC 1075: Distance Vector Multicast Routing Protocol”, Internet Engineering Task Force (IETF), November 1988. [9] J. Moy, “RFC 1584: Multicast Extensions to OSPF”, Internet Engineering Task Force (IETF), March 1994. [10] A. Adams, J. Nicholas, and W. Siadak, “RFC 3973: Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)”, Internet Engineering Task Force (IETF), Januray 2005. [11] D. Estrin, et al., “RFC 2362: Protocol Independent MulticastSparse Mode (PIM-SM): Protocol Specification”, Internet Engineering Task Force (IETF), June 1998. [12] A. Ballardie, J. Crowcroft, and P. Francis, “Core based Trees (CBT) – An architecture for scalable inter-domain multicast routing”, Computer Communications Review, 1993, 23(4): p. 85-95. [13] A. Ballardie, “RFC 2189: Core Based Trees (CBT version 2) Multicast Routing”, Internet Engineering Task Force (IETF), September 1997. [14] T. Bates, et al., “RFC 2283: Multiprotocol Extensions for BGP4”, Internet Engineering Task Force (IETF), February 1998. [15] S. Kumar and P. Radoslavov, “The MASC/BGMP Architecture for Inter-domain Multicast Routing”, ACM SIGCOMM, Vancouver, Canada, September 1998. [16] B. Rajagopalan, “Reliability and Scaling Issues in Multicast Communication”, Proceedings of ACM SIGCOMM 92, Baltimore, Maryland, USA, August 1992, pp188-198. [17] M. H. Ammar, “Probabilistic Multicast: Generalizing the Multicast Paradigm to Improve Scalability”, Proceedings of IEEE INFOCOM 94, Toronto, Canada, June 1994, pp848-855. [18] J.-H. Cui, et al., “Aggregated Multicast — A Comparative Study”, Kluwer Journal of Cluster Computing, Special Issue on Networking Technologies, Services and Protocols, 2005, 8(1): p. 15-26. [19] L. Lao, J.-H. Cui, and M. Gerla, “TOMA: A Viable Solution for Large-Scale Multicast Service Support”, IFIP Networking, Waterloo, Ontario, Canada, May 2005. [20] S. Banerjee, et al., “OMNI: An Efficient Overlay Multicast Infrastructure for Real-time Applications”, Computer Networks, Special Issue on Overlay Distribution Structures and their Applications, 2006, 50(6).
[21] B. Zhang, et al., “Universal IP Multicast Delivery”, Computer Networks, Special Issue on Overlay Distribution Structures and their Applications, 2006, 50(6). [22] R. Boivie, et al., “Explicit Multicast (Xcast) Basic Specification”, Internet Draft (draft-ooms-xcast-basic-spec-*.txt), Internet Engineering Task Force (IETF), 2006. [23] I. Stoica, T. S. Eugene Ng, H. Zhang, “REUNITE: A Recursive Unicast Approach to Multicast”, INFOCOM’00, Tel-Aviv, Israel, March 2000. [24] M. Ohta and J. Crowcroft, “Static Multicast”, Internet Draft, draft-ohta-static-multicast-02.txt, June 1999. [25] R. Perlman, et al., “Simple Multicast: A Design for Simple, Low-Overhead Multicast”, Internet Draft, draft-perlmansimple-multicast-03.txt, October 1999. [26] G. Armitage, “RFC 2022: Support for Multicast over UNI 3.0/3.1 based ATM Networks”, Internet Engineering Task Force (IETF), November 1996. [27] C. Adjih, L. Georgiadis, P. Jacquet, W. Szpankowski, “Multicast Tree Structure and the Power Law”, IEEE Transactions on Information Theory, Volume 52, Issue 4, p 1508-1521, April 2006. [28] J. Chuang and M. Sirbu, “Pricing Multicast Communications: A Cost-based Approach”, Telecommunication Systems, 17(3):281297, July 2001. [29] S. Fahmy and M. Kwon, “Characterizing overlay multicast networks and their costs”, IEEE/ACM Transactions on Networking, volume 15, issue 2, pp. 373-386, April 2007.
