2.4.3 How a receiving host would join or leave an AMA
2.4.4 How a receiving application would understand an AMA
2.4.5 How a router would aggregate AMAs
2.4.6 How an application would expand or contract an AMA if required
2.5 Router Implementation
2.6 Derivation of recommended values for constants
3. Related Work
4. Limitations and Further Work
5. Security Considerations
9. Authors' addresses
1. Introduction & Requirements
The addressing scheme used for Internet multicast has been recognised as unscalable since its inception. Every multicast group has to have a separate entry in the forwarding tables of every router on its path. Because multicast groups, being logical entities, have no direct relationship with physical topology, they cannot directly be matched to the hierarchical design of the Internet. In this paper we present an approach for solving this problem indirectly, in the proven tradition of the Internet; end to end - by co-operation between end-systems and the network.
The primary problem is that multicast addresses are fixed by session initiators, but aggregation relies on a clustering pattern emerging from the demography of the receivers. Further, the initiator usually doesn't know who the receivers will be until after the addresses to be used have been fixed. Therefore, any clustering beyond small-scale aggregation within applications will have to be achieved on a longer time-scale by session initiators predicting the likely demography of their session (e.g. based on past experience of similar sessions). The job of these predictive systems will be much simpler if they have some degree of pre-existing aggregation to nucleate around, rather than having to crystallise aggregation from complete chaos without any bootstrap process.
A large class of applications utilises multiple multicast addresses internally. Further, many such applications consist of varying sets of multiple multicast groups that are all sub-sets of a bigger set (e.g. news, stock-feeds, network games, virtual worlds, distributed simulations, all applications using layered multicast ). Any solution should ensure that such "nucleating applications" use aggregations of addresses that can be identified as such.
Related work is described later. Most is in the area of straightforward multicast address allocation, which is, perhaps surprisingly, far from being sorted out. It is very difficult, indeed probably reckless, to comment on proposals that have only been hinted at in the odd mailing list posting, or conference presentation. However, it appears that most schemes are assuming that aggregation will be possible if addresses are allocated based on the topological position in the Internet of the root of the multicast tree. Although this may well be the case, it is only true if most multicast applications will tend to be used by groups of users that happen to use the same ISP (Internet Service Provider), or they use ISPs that have a common parent ISP. No evidence that this is the case has been presented. In some cases the tree root even seems to be (erroneously) assumed to be in the same place as the session initiator (the party requesting the address). Certainly, nowhere does it seem to be taken into account that the likely receiver topology is just as important in determining whether multicast trees can be aggregated. Some of the proposals that are available also seem to implicitly assume that routing state will be aggregated in the same way unicast routing is aggregated - by discarding the right-hand bits of addresses which have common left-hand bit fields, despite there being no greater significance to any bit in a multicast
2 of 22 27/11/97 10:16
End to End Aggregation of Multicast Addresses