This is only a rough draft - Megan 04/20/92 MOSPF WG meeting, Monday afternoon March 16, 1992 Steve Deering - Chair Keven Rowett - Notetaker Agenda IETF audio multicast experiment John Moy - implementation experiences of MOSPF Inter-domain multicast routing internet draft to proposed RFC? Deering described the efforts to provide audio of various IETF sessions to people unable to attend. The equipment used is a Sun workstation, taking advantage of the Sparc built-in 79C30 codec. IP multicasting is being used to relay audio via IP tunneling around routers which don't support IP multicast routing. Destinations include Hawaii, Australia, Sweden, and the U.K. Steve noted that the package provides for talk-back from the distant participants, but locally they have been unable to interconnect with audio PA system. (Subsequently demonstrated at the Thursday Plenary). John Moy's experiences with implementing MOSPF. Suggested changes as a result of implementing: 1) only one wildcard bit in router-LSA. 0 0 0 0 wildcard VL ASBR ABR Only one wildcard option was ever really needed. 2) Remove IGMP enable/disable switch: DL unicast -> IGMP off MC fwd off -> IGMP off Else IGMP on. IGMP switch doesn't provide any new information. 3) No more one directional links in OSPF (LSinfinity loses meaning in router-LSA). This is actually a subject of OSPF WG, but wants both groups in synch. Eliminates disparity between UNICAST and Multicast routing tables. Scott Brim questioned if OSPF can force IGMP off, especially if BGP is also present. Multicast forwarding models John proposed a mixture of the BSD and MOSPF models (see illustrations in accompanying viewgraphs). The proposed scheme could result in duplicate packets to multi-homed hosts. For packets originated in local machine, a check is required to see if local netowrk looped back the packet. i.e. a LAN (or LAN interface) that does forward originated packets. This forces MOSPF forwarding decision to check source address does not equal the local address. TTL value is one less after MOSPF hop (seems reasonable). John's plans for document re-organization: 1) more on initialization of DIJKSTRA SPF algorithm. 2) multicast portion of DIJKSTRA algorithm not optional; everyone must do identical DIJKSTRA for consistent tie-breaking. 3) add an appendix with tie-breaking examples, just to make sure everyone gets this part right. MOPSF implementation notes: John noted that the hardest part of his MOSPF implementation was keeping the unicast and multicast DIJKSTRA algorithm in synch. Multicast routing table starts with the unicast table. If the unicast table is not right, then multicast won't ever be. Must tie multicast forwarding cache maintenance to unicast routing tables changes. John asked if IGMP queries should be done over point-to-point links? Steve suggest that yes, they should be done on p-to-p links because, for example, the link might be to a host or to a non-MOSPF router. John also suggested that it might be possible to do multipath multicast routing by using more creative tie-breaking during tree construction. The idea is intriguing, but needs more thought. Could possibly use a hash of the source address, or the (source, destination) pair, to select among multiple route choices. John estimated that his implementation took him the equivalent of 30 full-time working days to complete; it added 20% to the size of the OSPF code. It was agreed that, after John makes his final pass through the MOSPF draft, we would submit for publication as an Proposed Standard RFC. The agenda topic on inter-domain multicasting was not addresses, due to time limitations and lack of enthusiasm. (We have gone over that territory at every previous meeting.)