CURRENT_MEETING_REPORT_ Reported by Tony Ballardie/University College London and Bill Fenner/Xerox PARC Minutes of the Inter-Domain Multicast Routing Working Group (IDMR) The IDMR Working Group met twice at the 32nd IETF in Danvers. The first session was held on Monday, 3 April, and the second on Wednesday, 5 April. These minutes were compiled by Tony Ballardie and Bill Fenner with excerpts provided by some of the presenters themselves. Session 1 Item 1 Steve Batsell (NRL) gave a presentation on Distributed Interactive Simulation, and the new requirements such applications impose on a multicast protocol. These included the ability to support many concurrent senders in a scalable fashion, and low join and leave times. This diverges from the multicast model we currently have in the Internet, where the sender population is by far the minority, and senders interact one at a time. However, it was pointed out that applications such as video-gaming may soon pervade the Internet, and therefore multicast protocols should additionally satisfy this new requirement. It was pointed out that a solution that is commercially viable and acceptable is highly desired. Item 2 Bibb Cain from Harris Corporation presented a comparison of CBT and PIM via a simulation. The summary of this comparison is as follows: o SPTs incur 5-20% less delay than CBTs. o PIM SM (shared tree) consistently shows much longer delays (greater than 50%) than CBT. o PIM SM (with S,G state to RP) is identical in delay to CBT. o Control packet overhead: - PIM SM with SPTs incurs about double the overhead of CBTs - PIM SM shared tree mode incurs about the same overhead as CBT. o PIM and CBT join times were shown to be low and about equal. o PIM SM with SPTs can involve up to a 50% increase in join latency. o Regarding the question: Is PIM a superset of CBT? The conclusion to this question is that PIM is a superset of CBT, but there appear to be distinct advantages to using CBT. o Conclusions: - The end-to-end delay was on average 10% lower with PIM SPTs than the CBT delay. - In shared-tree mode, there is no advantage to using PIM over CBT. - In terms of b/w utilization (overhead), both protocols were shown to be about equal. Reservations as to the applicability of these results to the Internet environment were raised by some. It is expected that a new set of simulations will be carried out using richer, more redundant topologies, and hopefully, the results of those simulations will be available by the Stockholm IETF. Item 3 Scott Corson (University of Chicago) proposed a combined multicast routing and resource reservation protocol, termed Reservation-Based Multicast (RBM), that borrows the ``Rendezvous Point'' or ``Core'' concept from multicast routing algorithms proposed for the Internet, but which is intended for mobile operation and routes hierarchically-encoded data streams based on user-specified fidelity requirements, real-time delivery thresholds and prevailing network bandwidth constraints. The protocol exhibits the fully distributed operation and receiver-initiated orientation of these proposed algorithms; but, unlike them, the protocol is tightly coupled through a combination of hard- and soft-state techniques to a class of underlying, distributed, unicast routing protocols thereby facilitating operation in a dynamic topology. The protocol emphasizes combined routing and reservation in the face of ``bandwidth constraints'' and searches multiple routes while building source-specific trees. The protocol sacrifices a measure of scaling by maintaining the extra state necessary to form source-specific trees (relative to shared trees). This action avoids concentrating a group's traffic on a shared tree and minimizes the probability that a link failure, a common occurrence in a mobile network, will knock out a large portion of a group's communication. The protocol utilizes a greedy heuristic algorithm for combined admission control and resource reservation to resolve user self-conflicts during route construction. This talk focuses on the initial route construction phase, assumed to occur during a static ``snapshot'' of the dynamic topology, and is therefore applicable to fixed networks as well, e.g., the Internet. Items 4 and 5 Short status reports were given on ``gated'' and ``dvmrp 3.5,'' by Tom Pusateri (NetEdge) and Bill Fenner (Xerox PARC), respectively. The goals of the ``gated multicast project'' are: o To bring all multicast routing ptcls together under one roof. o Allow for the interaction between different multicast regions. o Provide a base framework for research on ptcl interaction and effectiveness. Work currently in progress includes: o 3.[3,4,5] DVMRP o PIM DM/DVMRP interaction o M-OSPF Future work includes plans for integrating CBT and PIM SM into ``gated.'' Session 2 Item 1 Bud Graff from the US Army gave a short presentation on the Army's multicast requirements and demonstrated how the Army is currently utilizing multicast technology. He expressed the Army's desire to use the multicast technology that is emerging through the IETF process, but stressed that it needed to satisfy certain requirements in order to be of use, for example, reliable, sender-driven multicast with incorporated security. Mobility and ATM interoperability are other areas being investigated by the Army through the IETF (Mobile IP, IP over ATM etc.). Item 2 Brad Cain, a grad student working under Steve Deering, presented a short summary of IGMPv3. This new version, which builds on IGMPv2 (which primarily incorporated low leave latency into IGMPv1 [O(ms)]) provides for source-specific joins and source-specific leaves. Thus, a receiver will be able to select which sources it wishes to receive traffic from, or no longer receive traffic from, respectively. This functionality will be implemented by means of two new IGMP message types: inclusion-report, and exclusion report, respectively. Item 3 Deborah Estrin described an RP-location mechanism for PIM. When using this mechanism, the session initiator selects an ordered list of RPs and advertises them along with the multicast group information. Group members join towards the first RP in the list, unless it is unreachable, in which case they join towards the first reachable RP in the list. If a secondary RP is in use, it continuously polls the primary RP. When the primary RP becomes available again, it sets a flag in its messages telling downstream routers to leave it and rejoin the primary RP. Thus, except during transients, all group members are using the same RP and there are not multiple active RPs. The initial algorithm to determine the RP list is to use the initiator's DR as the primary RP, under the assumption that the session initiator will be a group member, so packets need to flow there anyway. Secondary RPs are selected, one or two from each scope level that the group covers, randomly from a list of routers that advertise themselves as willing to be RPs for that scope. This is only an initial heuristic for RP selection, and will evolve over time as the community develops better algorithms. Item 4 Bob Voigt (Naval Postgraduate School) presented a proposal for a center location protocol. Citing the lack of such a protocol in either of the proposed protocols for interdomain multicast, he explained the advantages of a CLP to efficiently choose center locations in a group-specific manner. The proposed protocol uses a scheme of participant registration to set up a tournament, executed in a distributed fashion using existing routing and address information. The outcome is a center that could then be used as a core(CBT) or an RP. By controlling the various aspects of the tournament and the registration process, this protocol makes it possible to inject policy into the decision. Some results were presented to demonstrate the benefit of a CLP over random center selection. An Internet-Draft describing the protocol in more detail is forthcoming. Item 5 A discussion on the need for shortest-path trees (SPT) followed a similar presentation by Steve Deering. This presentation focussed on the fact that many current multicast applications are delay-critical (voice, video) and therefore SPTs are most desirable. A simulation graph showed that shared trees typically incur 1.4 times greater delay. Some did not consider this overly significant. Shared tree traffic concentration was also raised as a concern. SPTs, in networks with many redundant paths, allow for much less traffic concentration than shared trees. In networks with more restricted topologies, the shared and SPTs provide essentially the same traffic concentration characteristics. SPTs use more state in routers, but SPT state is data-driven (only needs to exist for active sources), while shared tree state must exist even if the group has no senders. PIM was presented as a protocol that can support both shared and SPTs is that the same protocol mechanisms can be used to build either a shared or SPT, and it can use shared trees for low data rate sources, or sources insensitive to delay, and SPTs for delay-sensitive or high-data-rate sources. However, important questions include: is PIM's protocol complexity justified (i.e., is the win big enough)? Given many thousands of groups with many high data rate sources, can it scale as an inter-domain multicast routing protocol? These questions cannot be easily answered, and it is likely to take considerable implementation experience before hard evidence provides us with answers. The shared-tree/SPT debate could not be resolved. There have been several suggestions that this matter can only be resolved after further simulations and implementation testing, and ultimately the market should decide after we have sufficient experience of these protocols operating in the real world. The ability of a multicast protocol to achieve load balancing was also considered important. It remains unclear to what extent multicast algorithms can achieve load balancing.