CURRENT_MEETING_REPORT_ Reported by Tony Ballardie/University College London Minutes of the Inter-Domain Multicast Routing Working Group (IDMR) The IDMR Working Group met twice at the 29th IETF in Seattle, Washington. Both sessions were chaired by Tony Ballardie. The group has considered changing the name of IDMR to better reflect its purpose and scope. This will involve some additions to the charter, although the overall goals of the IDMR charter will remain the same. It is proposed that the new name of the IDMR group be: ``The Multicast Working Group.'' The mailing list name will also be changed to multicast@cs.ucl.ac.uk. However, this does not come into effect immediately and is subject to approval by the Routing Area Director. Notification will be sent to the list once the change has been approved. First Session An update of CBT was presented by Tony Ballardie. This included notification of state regarding implementation, as well as some new CBT protocol features. These include the implementation of ``fast pruning''---a new version of IGMP for CBT which provides lower leave latency (approximately 12 seconds) for CBT hosts. This involved adding a new IGMP LEAVE message to the IGMP protocol. Another new CBT feature involves the capability of a CBT user to send either CBT-style packets (which traverse a CBT shared tree) or traditional IP-style multicast packets (which traverse a shortest-path tree) by using a ``toggle'' the CBT user interface. In order to take advantage of this feature it is assumed that at least one DVMRP (or MOSPF or PIM) router exists on the same subnet as the CBT host. CBT hosts and routers can both send and receive traditional IP-style multicast packets. A ``CBT Architecture Overview and Specification'' document will be available shortly. This will include details on interaction with current IP multicast schemes, and a new scoping mechanism. The first session concentrated on the PIM sparse mode and dense mode specifications. Deborah Estrin went through various aspects of the PIM sparse mode specification. Firstly, the mechanisms by which looping is prevented/detected on multi-access subnetworks if reverse path (RP) and source trees overlap, were explained. There is both a prevention mechanism preventing the looping scenario from arising, and a detection-recovery mechanism should a looping situation nevertheless occur. The first case takes advantage of the fact that PIM JOIN/PRUNE messages are multicast onto a LAN, and other routers on a LAN receiving these messages can take appropriate action---usually by creating a negative cache entry, to prevent unnecessary forwarding onto the LAN. The detection approach involves explicit PIM ASSERT messages (multicast to the ``all-routers'' address) which are sent whenever a data packet is received on an outgoing interface for some (S, G) pair. Receiving routers may delete the arrival interface from their outgoing interface list for their (S, G) entry (if they have one) according to certain rules, or if none applies, a receiving router may itself send a PIM ASSERT, and the process repeats itself. The differences between PIM sparse and dense modes were also explained, and the conditions under which each would be appropriate. Dense mode is appropriate if the network (or scope of operation) is uniformly bandwidth rich (e.g., a campus network). In this case, the preferred mode of operation is data driven flooding and pruning in place of having an RP/shared tree. Sparse mode is used if the operational region in question has bandwidth limitations/costs/constraints. For example, for wide-area inter-domain multicasting, flood-prune mode is unacceptable and does not scale, particularly when groups are not uniformly dense. In such cases RPs/shared trees are used, with the option for receivers to switch to shortest-path trees (although it is not yet clear under which conditions/criteria a receiver's first-hop router makes the decision to make such a switch). An explanation was also given of hybrid dense mode/sparse mode behaviour. Each PIM router can have its interfaces independently configured to operate either in sparse mode or dense mode (some of a router's interfaces may be sparse, some may be dense). A down stream router knows the mode of its upstream neighbour by receiving PIM QUERY messages. JOIN messages are converted to PIM GRAFT messages if sent out of a dense mode (DM) interface. A GRAFT is converted to a PIM JOIN when sent out of a sparse mode (SM) interface. A question was raised regarding the negative effect of a large number of control messages (periodic SM messages) which would arise given a very large number of groups operating in SM. It was suggested that some form of message aggregate would be a good idea for such a case. A number of open issues were briefly mentioned, including how to aggregate source information, whether it is worth having implicit join mode vs. periodic join mode, how RP identities are communicated to new sources/receivers. Dino Farinacci presented an update on PIM DM for the latter part of the first session. He presented the most significant changes with regards to the latest DM specification, which mainly centered around explaining the PIM ASSERT message processing for eliminating duplicates on a multi-access subnet (see above). Various DM open issues include: how to interface pure DM clouds to other multicast clouds such as DVMRP and MOSPF; how to get internal group state to border routers (in particular how to fix entry points to a cloud -- problem of data packets not being received on shortest reverse path); interaction with DVMRP. The state of PIM implementation is as follows: a DM prototype is complete; SM implementation is about to begin; interaction with DVMRP is being worked on; CBONE (CiscoBONE) currently has 10 multicast routers on it, consists of real links and tunnels; simulation and a SunOS implementation of PIM DM is ongoing at USC. Second Session Steve Deering presented the details of a new version of the IGMP protocol (IGMPv2), which is currently under development. The motivation for a new IGMP version is the need for lower leave latency---the time between the last group member on a subnet relinquishing membership of a particular group, and not receiving further traffic on that subnet for the same group---it is deemed particularly important where high bandwidth traffic is concerned. Currently, leave latency is around 4.5 minutes. Briefly, IGMPv2 involves an explicit LEAVE message which is heard by ``new'' routers. On receipt of a LEAVE message, a new router sends a new query which is addressed to the group (as specified in the LEAVE message). This new query includes in it a randomization interval over which the group receivers on the subnet should randomize their response (report) -- as with the old version, a group report will suppress other reports for the same group. By specifying a randomization interval in the query, leave latency can be as low (or lower than) one second. The new version is backwards compatible with the existing version. Other changes proposed by Deering included the following: o Requiring changes to multicast service interface - source-specific leave - core/RP identification reports - shared tree vs. source-tree preference indicator in reports o Not requiring changes to multicast service interface - host reception of prunes - eliminate need for routers to be promiscuous to all IP multicasts Finally, there was some general discussion on administrative scoping of multicast addresses. The problem that this tackles is being able to effectively limit the scope of multicast packets (i.e., keep them within a domain). Limiting TTL value is not effective in this respect, and does not prevent traffic coming in to a domain, although carefully setting TTL can help prevent it from getting out. Van Jacobson proposes allocating a block (64,000 address block) from the upper portion of the IP multicast address space. The reason for not allocating more was that it is better to start small and grow, rather than wasting addresses. Sub-blocks would then be assigned to routing domains for use within those domains. Each domain would then have full control over its block of addresses and could use and re-use them as it sees fit. Border routers would need to know the boundary of a domain's multicast address space so as to know whether to forward packets or not. Overlapping boundaries are potentially a problem -- this is the motivation for assigning a larger block than 64K. Christian Huitema expressed concern with the problem of being able to clearly define boundaries and was sceptical about this approach. Attendees Susie Armstrong susie@mentat.com Tony Ballardie A.Ballardie@cs.ucl.ac.uk William Barns barns@gateway.mitre.org Stephen Batsell batsell@itd.nrl.navy.mil Jim Beers Jim.Beers@cornell.edu Ute Bormann ute@informatik.uni-bremen.de Joesph Burrescia burrescia@es.net Ken Carlberg Carlberg@tieo.saic.com Stephen Casner casner@isi.edu Luo-Jen Chiang ljc@lsnhbu1.lincroftnj.ncr.com Matt Crawford crawdad@fncent.fnal.gov David Crowe crowed@osshe.edu Deborah Estrin estrin@usc.edu Jan Eveleth eveleth@nwnet.net Dino Farinacci dino@cisco.com William Fenner fenner@cmf.nrl.navy.mil William Fink bill@wizard.gsfc.nasa.gov Paul Francis francis@cactus.slab.ntt.jp Steve Fulling fulling@cs.orst.edu Ramesh Govindan rxg@thumper.bellcore.com Susan Hares skh@merit.edu Eric Hoffman hoffman@cmf.nrl.navy.mil Ronald Jacoby rj@sgi.com Robert Kummerfeld bob@cs.su.oz.au Fong-Ching Liaw fong@eng.sun.com Cheryl Madson cmadson@wellfleet.com David Marlow dmarlow@relay.nswc.navy.mil David Meyer meyer@ns.uoregon.edu Gilles-Andre Morin gamorin@shl.com Peder Chr. Noergaard pcn@tbit.dk Erik Nordmark nordmark@eng.sun.com Rex Pugh pugh@hprnd.rose.hp.com Benny Rodrig brodrig@rnd-gate.rad.co.il Allyn Romanow allyn@eng.sun.com Katsuhiro Sebayashi sebayasi@tnlab.ntt.jp John Stewart jstewart@cnri.reston.va.us Peter Sylvester peter.sylvester@inria.fr Fumio Teraoka tera@csl.sony.co.jp Dan Wood dwood@bbn.com Mary Jo Zukoski maryjo@gateway.mitre.org