CURRENT_MEETING_REPORT_ February 6, 1990 Held at Tallahassee IETF meeting Chaired in Steve's absence by J. Moy/Proteon Minutes also written by J. Moy MINUTES This was the initial meeting of the MOSPF working group. John Moy presented a number of slides to introduce the subject of multicast routing . The slides also attempted to discuss the main areas where the OSPF protocol needs to be changed/extended in order to provide multicast support. The slide discussion was broken up into the following areas: o o There was a short introduction into IP multicasting, including the Internet Group Management Protocol (IGMP, RFC 1112). IGMP is responsible for maintaining host group membership. Multicast routers must support IGMP (although in multicast OSPF only the Designated router will be actively sending/receiving IGMP messages). Through using IGMP, a multicast router knows which multicast destinations are active on its attached LANs, but does not need to keep track of which particular hosts are requesting them (this is a considerable savings). o o A brief (and very incomplete) survey of multicast routing was attempted. This was done through examination of Steve Deering's "Multicast routing in Internetworks and Extended LANs" paper. This paper discusses a number of multicast routing methodologies: an extension to the learning bridges to better support multicast, four separate Bellman-Ford multicast routing algorithms (arranged in order of increasing functionality and complexity) and a link-state multicast algorithm. Finally, a mix of these approaches is explored for internet-wide multicast (and the wild-card multicast group is introduced). The most functional Bellman-Ford multicast algorithm in Steve's paper has been implemnted for BSD UNIX and is documented in RFC 1075. It is expected that the multicast OSPF extensions will closely follow the link-state multicast algorithm in Steve's paper. o o The basic mechanism behind link-state multicasting was explored. A shortest-path tree is built having as root the multicast datagram's source. Those branches not containing the specified multicast destination are then pruned. This tree then yields the multicast datagram's path. At each hop, the multicast datagram is sent as a link-level multicast (or broadcast). For this reason, multicast routers receive all multicast packets (i.e., must open up their multicast filters). The above trees are built on demand, and the results are cached (see below). 1 o o Cache entries are used to store the results of the above SPF calculation. For each tree built (there is potentially a different tree for each [source net, multicast destination] pair), a cache entry is formed. The cache entry specifies the interface expected to receive the datagram, and the set of interfaces that the datagram should be forwarded out. Note that this proposed cache structure is slightly different than the one in Steve's paper. First, it skips caching whole subtrees (implementation experience with OSPF shows that subtree caching is a lot of work), and it simplifies things by ignoring TTL. A separate tree (and a separate cache entry) will also possibly be calculated for each TOS value. The entire cache must be cleared on topology changes. When a group's membership changes, only cache entries pertaining to that destination need be flushed. o o The changes and additions to the OSPF protocol are expected to be slight. This is because OSPF already maintains a complete topological map of the routing domain, enabling the multicast tree calculation. The expected changes to OSPF include the following: 1) During the Dijkstra calculation, routing table entries (e.g., for net X) will be marked with their corresponding "transit node". This node will be the root for multicast tree calculations having net X as datagram source. o o Expected additions to OSPF include the following: 1) OSPF Designated Routers (DRs) will need to speak IGMP. 2) There will be a new link state advertisement (type 6) that routers will originate when there are multicast destinations on attached LANs. There will be separate advertisements for each multicast destination. These advertisements will be originated by DRs only. This additional link state information will enable tree pruning. 3) There will probably be a new bit in the router links advertisement indicating "multicast-capable". This allows some routers in the AS to decline multicast support. 4) The multicast tree calculation must be made deterministic; i.e., all routers must calculate the same tree in the presence of multiple equal-cost routes. o o Inter-area multicast will be a little more complicated. This is because when the datagram source is in another area, the local topology surrounding the source is hidden, inhibiting the multicast tree calculation. In this case, we propose forming a tree for each of the other areas. Each tree can be thought of as still being rooted at the datagram source; there will be a link from the datagram's source to each of the area's border routers. The cost of these links will be that advertised by the area border routers in their summary link advertisements (note reverse direction). The rest of the tree will (as in the intra-area case) deals only with the area's own topology. datagram source : ---------------- : : : : : : : : ABR ABR ABR ABR | | | 2 ------- | A multicast datagram enters the area through the border border routers. The above scheme works only if area border routers are "wild-card" multicast receivers (i.e., receive all muticast packets). The logic for when the source of the datagram is exterior to the AS should be similar to the inter-area case. The following questions were raised by the slides. Bob Hinden asked whether there were any estimates for the CPU usage consumed by the potentially large number of tree calculations. In a related question, Chuck Davin wondered about the expected distribution of host group memberships (e.g., number per LAN and lifetime). These questions were put off, hopefully for Steve Deering to answer. Scott Brim questioned the behavior of the above inter-area multicasting scheme in the presence of asymmetric paths. He thought that there might be the possibility of packet looping. This issue should be looked into further. Besides the above, the following issues were brought up: o Should the multicast specification be written as a separate document, or should it simply depend on RFC 1131 (the OSPF specification)? o If we do not require all of the routers to be multicast-capable, is the possibility of reduced functionality acceptable? o How much backward compatibility should there be with the present OSPF protocol? o Should we try to be more efficient in inter-area multicasting, and drop the requirement that border routers be wild-card multicast receivers? FUTURE MEETINGS We intend to begin writing the specification for OSPF multicast extensions. This will be done primarily through communications on the mospf mailing list (mospf@devvax.tn.cornell.edu). There will be a MOSPF WG meeting at the next IETF (Pittsburgh). Also, if enough progress is made between meeting, we will attempt to schedule the teleconferencing facilities. ATTENDEES John Cavanaugh johncavanaugh@stpaul.ncr.com 3 Rob Coltun rcoltun@umds.umd.edu Samir K. Chatterjee samir@nynexst.com George Clapp meritec!clapp@bellcore.bellcore.com Daniel Kellen kellen@odixie.enet.dec.com Stan Froyd sfroyd@salt.acc.com James R. Davin jrd@ptt.lcs.mit.edu Douglas Bagnall bagnall-d@apollo.hp.com Metin Feridun mferidun@bbn.com Tom Easterday tom@nisca.ircc.ohio-state.edu Ballard Bare bare%hprnd@hplabs.hp.com Cathy Aronson cja@merit.edu Bob Hinden hinden@bbn.com Frank Solensky solensky@interlna.com Dave Miller dtm@mitre.org Tim Seaver tas@mcnc.org Joel Replogle replogel@ncsa.uiuc.edu Tony Mason mason@transarc.com Farokh Deboo fjd@interlink.com Dino Farinacci dino@bridge2.3com.com Jeffrey Burgan jeff@nsipo.nasa.gov Dave O'Leary oleary@noc.sura.net 4